Лингвистическая модель технического задания

При разработке, часто сталкиваюсь с ситуацией, когда заказчик, не является техническим специалистом и это нормально, тем не менее , для того чтобы работа была выполнена качественно, требуется создание технического задания (ТЗ), которое подразумевает перевод пожеланий в более формальный вид.

Наиболее просто описать требования к системе с помощью частей речи, таким образом объекты - это существительные, свойства объектов - это прилагательные, глаголы - действия над существительными (объектами). Так как это некоторая модель, а любая модель склонна у упрощению - следует понимать все не слишком буквально.
Разберем пример:

Пользователь сайта (существительное) - это явно выраженный объект, у него есть как минимум прилагательные (свойства) логин и пароль. Это просто. Теперь представим, что нам нужно знать номер телефона пользователя - таким образом, у нас появляется новое прилагательное. Однако в некоторых случаях, у пользователя может быть несколько телефонов - в этом случае номер телефона пользователя превращается в самостоятельный объект, у которого два прилагательных: это сам номер и принадлежность определенному пользователю. Причем это, последнее прилагательное, является неявным и возникает в результате проектирования системы.

Именно из за таких неявных моментов, так важно четко и досконально сформировать описание предметной области, чтобы мы проектировщики и разработчики смогли грамотно перевести требования заказчика на язык, понятный компьютеру.

Чтобы не получалось неприятностей, как на этой известной картинке:

В некоторых случаях все еще больше усложняется, продолжая пример с телефонами и пользователями: Согласитесь, ведь в определенных случаях нам необходимо знать тип телефона (домашний, рабочий, мобильный), к примеру, мы хотим слать нашему пользователю СМСки. Таким образом у существительного телефон появляется еще одно прилагательное, тип телефона и оно возникает неявно как, обращение к введенному нами существительному - тип телефона.

А теперь самая удивительное, ведь пользователь то, может быть клиентом какой-нибудь социальной сети и не одной, и регистрироваться у нас под новым логином, паролем он может не захотеть... Так начинается другая занимательная история. ;)

Дорогие заказчики пожалуйста описывайте все необходимые вам существительные, прилагательные, что вы хотите с ними делать (глаголы) и как все это будет взаимодействовать между собой.

Общая модель разработки сайта

  1. Пишется ТЗ
  2. Рисуется дизайн
  3. Верстается сайт
  4. Программируется backend (функционал на стороне сервера)
  5. Программируется frontend (функционал на стороне клиента)

По каждому блоку (типу страницы) этапы выполняются последовательно, но сами блоки можно паралелить.

Посмотреть мое портфолио.