Функциональные Требования.
На основе ФТ разрабатывается ТЗ, в котором добавляются технические и нефункциональные требования.

ФТ описывает, что делать. ТЗ - что и как .

cyxЯ понимаю. что устоявшегося термина нет...
Структура ТЗ, порядок его согласования и утверждения фиксируется заказчиком в ФТ?

Ну да, каждый крупный заказчик называет по-своему. :) Например: "Спецификация"

На мой взгляд, суть в том, что заказчик должен рассказать свои хотелки, не затрагивая вопросы реализации. Экранные формы, use cases, интерфейсы legacy-систем - это и есть ФТ/спецификация.
Этот документ делается либо самим заказчиком, либо внешними консультантами.

Он подписывается и передается исполнителю, который пишет главный документ - ТЗ.
В него входят ФТ, технические требования, архитектура и процедура передачи системы в эксплуатацию.

PS. В реальности обычно все намного сложнее... :)

cyxДиез

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

Для исполнителя - точно ни к чему хорошему не приведет :)

Если есть четкие ФТ, разобраться в предметной области намного легче. А разбираться придется так или иначе, сами понимаете.
cyx
Какими ролевыми функциями следует в идеале ограничить айтишников заказчика в проекте в интересах конечного результата?

Приемка, тестирование, администрирование, поддержка 1 уровня.

Если айтишники не могут разработать ИС (или могут, но им не дают), то лучше им не позволять вмешиваться в разработку.

cyxБудут палки в колеса вставлять? ))

Может палки в колеса вставлять, а может помогать начнут. Еще неизвестно, что хуже ;)

MrPavel ДиезФункциональные Требования.
На основе ФТ разрабатывается ТЗ, в котором добавляются технические и нефункциональные требования.

ФТ описывает, что делать. ТЗ - что и как .
как описывает ОПЗ, а не ТЗ :)

Согласен, неправильно построил фразу. Имел в виду вот это:

ФТ описывает, что должна делать ИС . ТЗ - что и как .

AlexTheRaven cyxAlexTheRaven

А можно пример подобных "чрезмерных" требований?
Ну например:
- Система должна состоять из базы данных, модулей логистики, бухгалтерии, документооборота и планирования, и веб-интерфейса. Должна быть возможность развернуть каждый из этих модулей на отдельном сервере.

Вроде адекватно все. Тем более, что требования по ПО и железу входят в ТЗ, как и требования по масштабируемости.
AlexTheRaven
- Система должна быть разработана на платформе JSP + JSF + Hibernate .

Тут согласен - заказчику такие вещи в большинстве случаев вообще знать не надо.
AlexTheRaven
- Модули системы должны взаимодействовать при помощи SOAP.

Тоже нормальное требование - спецификация на интерфейсы распределенной системы.
AlexTheRaven
- Система должна позволять переключиться на вкладку "Просмотр" и просмотреть счёт перед печатью.

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

На мой взгляд, из четырех примеров - только один "чрезмерный". Можете пояснить свою точку зрения?

cyxЕще вопрос в тему.
Хорошо, заказчик подготовил фуннкц. требования и назначил руководителя проекта (РП со стороны заказчика, естественно). ИТ-директор провел тендер или что-то в этом роде и привел исполнителя, руководитель готов подписать договор.
Что требуется от РП с точки зрения дела ? (Берем идеальный случай, когда он заинтереосован в конечном успехе проекта и не вхож в откаты и прочее.)
Сидеть сложа руки и стараться никому не мешать, умные дяди все сделают сами? )

Если есть руководитель проекта, значит есть и сам проект.
То есть: этапы, вехи, дедлайны, собрания. Кому-то надо вести диаграммы Ганта, Action-листы, протоколы совещаний.
Имхо, РП должен выполнять функции секретаря, имея право решающего голоса :)

И не спрашивать, "Почему вы выбрали WinForms, хотя WPF круче?" А спрашивать: "Когда мы увидим готовый интерфейс?"

AlexTheRaven Диез<про разделение на модули>
Модули - технологическая вещь, а не "бизнес". Обычно достаточно предъявить требования к масштабируемости системы и аппаратные требования, в т.ч. к каналам связи. А как разработчики разделят систему на компоненты, слои и уровни - их дело.

Разумеется, просто я говорил про ваш конкретный пример:

"логистики, бухгалтерии, документооборота и планирования" - функциональные требования
"базы данных, модулей ..., и веб-интерфейса " - требования к архитектуре


AlexTheRaven
Диез<про SOAP>Нужно предъявить требования к API, к интеграции с внешними системами. Без них SOAP - модная прихоть. А если Java RMI позволит сократить разработку на десяток человеко-месяцев? Или фреймворк "заточен" на собственный протокол? Или нужен эффективный протокол для передачи бинарных данных?


Не согласен.
SOAP - не модная прихоть, а стандарт обмена. Java RMI жестко ограничивает заказчика одной платформой при необходимости доработки. (А что доработки понадобятся - 95 %)

Иными словами:
Java RMI - конкретная реализация, и не должна входить в ТЗ
SOAP - требования к реализации (а вот на чем писать вебсервисы - забота разработчика)
AlexTheRaven

Диез<про вкладку "Просмотр">А если будет удобнее сделать систему с веб-интерфейсом, и вкладка "Просмотр", да и печать - за рамками нашей системы, которая просто формирует и отдаёт файл клиенту? А если удобнее сделать не вкладку, а специальное окно "Предварительный просмотр", как в большинстве программ?

"Удобнее", "специальное окно", "за рамками системы"....

Вы говорите про функциональные требования, в чистом виде. :)

AlexTheRaven Диез<...>"базы данных, модулей ..., и веб-интерфейса " - требования к архитектуре
Архитектуру лучше разрабатывать после того, как описаны требования. "Требования к архитектуре" дальше "система должна обладать клиент-серверной архитектурой" - IMHO нонсенс. Это имеет смысл, только если компания-разработчик отдаёт на сторону какой-то компонент.

Не надо мешать в кучу требования и архитектуру.


Если архитектура клиент-серверная, как вы сказали, то больше действительно ничего не надо, кроме двух прямоугольников со стрелкой.

Если это распределенная система, открытая для дальнейших расширений, с удаленными подразделениями, с интеграцией legacy-систем - то указание конкретных требований к архитектуре необходимы. Иначе разработчики такого наваяют...

AlexTheRaven
Не надо мешать в кучу требования и реализацию.

А я об этом и говорю.
Если заказчик хочет, чтобы модули связывались по SOAP, он имеет полное право включить это в требования. Это нормально.
А на чем реализовать (на JAX-WS, али на AXIS, к примеру) - решать исполнителю.

AlexTheRaven
Функциональные требования - это "система должна позволять просмотреть документ перед печатью".

Не надо мешать в кучу требования и дизайн интерфейса.
А юзкейсы куда девать?

Petro123 Диез
Если заказчик хочет, чтобы модули связывались по SOAP, он имеет полное право включить это в требования. Это нормально.

=== можно и требования к длинне процедур включить. Только это не будет ТЗ на Систему

Все-таки, это разные вещи.

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

А протокол взаимодействия - может влиять! (а может и не влиять - тогда в требованиях он нафиг не нужен).
Вас же не удивляет, когда в ТЗ указывается, например, что связь клиента с СУБД должна осуществляться по TCP/IP ?

Petro123
А юзкейсы куда девать?

==== они после ТЗ


А можно поконкретнее? В каких документах, в каких разделах?

Petro123 Диез


______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

Интересная ссылка, спасибо.

Думаю, эта схема будет отлично работать в рамках одного предприятия. Но как только появляются отношения заказчик/разработчик, появляются горизонтальные связи, и четкая иерархия уровней развалится, как раз на границе Черного и Белого ящиков.

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

ЗЫ. Про юзкейсы (в этой схеме - прецеденты) я так и не понял, почему "они после ТЗ" :)

AlexTheRaven Диез
<...>Если это распределенная система, открытая для дальнейших расширений, с удаленными подразделениями, с интеграцией legacy-систем - то указание конкретных требований к архитектуре необходимы. Иначе разработчики такого наваяют...

Системный аналитик всегда менее компетентен в архитектуре, чем разработчик. Хотя бы потому, что сам не пишет код по этой архитектуре.
Поверьте, если описать требования к распределённости, масштабируемости, каналам - разработчики сумеют создать архитектуру значительно лучше, чем системные аналитики.

Кроме системных аналитиков, представителями заказчика часто являются безопасники и админы.
Они знают эти вопросы гораздо лучше разработчиков (во всяком случае, должны знать, как специалисты).

AlexTheRaven
Диез
<...>Если заказчик хочет, чтобы модули связывались по SOAP, он имеет полное право включить это в требования. Это нормально.<...>
Да. Но ему надо чётко объяснить, сколько это будет стоить по деньгам и времени, и как отразится на рисках.

Согласен.
AlexTheRaven
Диез
А юзкейсы куда девать?
А правильно написанные юзкейсы не имееют отношения к GUI.
Приведите, если не сложно, пример таких юзкейсов (ну, с акторами - людьми, конечно).

Petro123 Диез.
Соответственно, нужен документ, "связывающий" эти уровни, и заключающий в себе как требования пользователя, так и требования к системе. Только в таком случае будут строго определены обязанности обеих сторон, и проект имеет шанс закончиться.

уровни связываются переговорным процессом. Есть "рамочное" ТЗ, которое можно корректировать частным ТЗ по согласованию сторон. Если заказчик вменяемый, то скорректировать ТЗ непроблема.
Так же как в думе есть первое чтение, второе и т.д.

Нельзя и вредно объять необъятное.


Вменяемость заказчика - величина непостоянная, которая начинает резко уменьшаться при перерасходе бюджета или при "неожиданном" приближении срока сдачи проекта.

Переговорный процесс должен заканчиваться в момент подписания договора. Все хотелки заказчика, возникшие после подписания договора, офомляются как RFC (Request For Changes), и оцениваются они отдельно.

Иначе будет первое чтение, второе,.. пятое,.. пятнадцатое... Это хорошая схема для дележа денег, но не для проекта.

Petro123
ЗЫ

авторвариант использования не годится для описания интерфейсов. Лучше потратить время и силы на то, чтобы обучиться писать в нейтрально-технологическом стиле: "Система предоставляет выбор таких-то возможностей. Пользователь выбирает определенное действие". Результаты оправдают эти усилия - вы получите более краткие и стабильные варианты использования, которые можно будет легко прочесть и понять.

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

Ну что ж вы ссылки не даете. . Все приходится самому искать :) Кстати, интересно написано, буду почитать...

AlexTheRaven Диез<...>
Кроме системных аналитиков, представителями заказчика часто являются безопасники и админы.
Они знают эти вопросы гораздо лучше разработчиков (во всяком случае, должны знать, как специалисты).
Наверное, мы говорим о разной архитектуре: вы - только сетевой и аппаратной.
Покажите мне админа, который сможет рассказать отличие tier от layer, или что такое MVC. Или, тем более, безопасника - человека с ФСБ- или "военный-секретчик" - background'ом.


Похоже, что да :)

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

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

AlexTheRaven
Диез<про варианты использования, не привязанные к GUI>
Приведите, если не сложно, пример таких юзкейсов (ну, с акторами - людьми, конечно).

Система позволяет создать счёт.

Основная последовательность:
1) Менеджер по продажам может инициировать создание нового счёта.
2) Менеджер по продажам может использовать существующий заказ.
3) Менеджер по продажам может выбрать существующего заказчика.
4) Менеджер по продажам может создать, изменить, удалить элементы списка заказанных товаров.
5) Менеджер по продажам может предоставить скидку.
6) Менеджер по продажам может просмотреть счёт.
7) Менеджер по продажам может распечатать счёт.
8) Менеджер по продажам может отправить счёт контактному лицу заказчика по электронной почте.

Альтернативная последовательность №1:
4а) Система может показать менеджеру по продажам, что товаров, входящих в счёт, нет на складе, а также срок их планируемых поставок.
5а) Менеджер по продажам может поставить заказ на ожидание в течение заданного времени.
6а) Менеджер по продажам может уведомить сотрудника, как только товары появятся на складе.
5а.а) Менеджер по продажам может отменить счёт
6а.а) Менеджер по продажам может уведомить сотрудника о том, что время ожидания заказа истекло.
------------
IMHO функциональность и последовательность работы понятны, при этом - ни слова об интерфейсе. Компетентность системного аналитика в проектировании GUI и эргономике также весьма ограничена.

Нее, я такой документ в жизни бы не подписал! :) Представляете, какой простор для трактовок?

Я, как исполнитель, потребовал бы точного указания списка полей счета, с указанием типа и поведения каждого поля.
Это по сути описание UI в абстрактных терминах: текст, список, таблица etc.
Иначе за месяц до сдачи проекта заказчик скажет, мол, мы добавили 20 новых полей в определение счета, а в договоре сказано: "инициировать создание нового счёта..." Делайте!

С другой стороны, я, как заказчик, имею полное право желать, чтобы "по нажатию клавиши 'Tab' происходил последовательный переход по полям формы сверху вниз". Вполне понятное функциональное требование (думаю, с кривыми табордерами сталкивались все.)

А вы говорите, не привязано к UI...