cyxAlexTheRaven

А можно пример подобных "чрезмерных" требований?
Ну например:
- Система должна состоять из базы данных, модулей логистики, бухгалтерии, документооборота и планирования, и веб-интерфейса. Должна быть возможность развернуть каждый из этих модулей на отдельном сервере.
- Система должна быть разработана на платформе JSP + JSF + Hibernate .
- Модули системы должны взаимодействовать при помощи SOAP.
- Система должна позволять переключиться на вкладку "Просмотр" и просмотреть счёт перед печатью.

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

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

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

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

ДиезНа мой взгляд, из четырех примеров - только один "чрезмерный". Можете пояснить свою точку зрения?На Западе требования иногда называют "контрактами". Под ними подписываются, их соблюдают неукоснительно. За несоответствие программы требованиям платят неустойку.
В России же несовершенство требований будет скомпенсировано их невыполнением. И ведь всякие глупости выполнят...
Поэтому требования должны в минимальной степени связывать руки разработчикам.

ЮВ Диез AlexTheRaven
- Система должна быть разработана на платформе JSP + JSF + Hibernate .

Тут согласен - заказчику такие вещи в большинстве случаев вообще знать не надо.


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

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

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

AlexTheRaven<...> SOAP - не модная прихоть, а стандарт обмена. Java RMI жестко ограничивает заказчика одной платформой при необходимости доработки. (А что доработки понадобятся - 95 %) <...> Обмену подлежит не всё. Повсеместное применение раскрученного продавцами интеграционных платформ SOAPа само по себе ничего не даёт: чётко описанный API с бинарным протоколом использовать значительно проще, чем непонятного предназначения сервис, доступный через SOAP.

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

AlexTheRaven<...>
"Удобнее", "специальное окно", "за рамками системы"....
Вы говорите про функциональные требования, в чистом виде. :)
Функциональные требования - это "система должна позволять просмотреть документ перед печатью".

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

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

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

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

Диез
А юзкейсы куда девать?
А правильно написанные юзкейсы не имееют отношения к GUI.

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

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

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

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

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