Comments 11
Вообще-то функциональные требования, это «ЦЕЛЬ. т.е ЧТО нужно получить в итоге » с точки зрения бизнеса и сформулированы они должны быть в «атомарной» и «объективно измеримой форме».
Пути достижения «КАК можно достичь ЦЕЛИ » — это не требования (если это не ограничения дизайна/бизнеса), это Процессы. И то, что вы расписали — это бизнес анализ и источник требований
Это, скорее, критерий приемки причем к продукту/решению, а не команде разработки ибо как это сделают — это еще вопрос (решение может быть чисто административным).
Пути достижения «КАК можно достичь ЦЕЛИ » — это не требования (если это не ограничения дизайна/бизнеса), это Процессы. И то, что вы расписали — это бизнес анализ и источник требований
User story — показывает, чего вы ожидаете от команды разработки
Это, скорее, критерий приемки причем к продукту/решению, а не команде разработки ибо как это сделают — это еще вопрос (решение может быть чисто административным).
А если изучить уже существущий глоссарий ?
Бизнес-требования (business requirements) описывают, почему организации нужна такая система, то есть цели, которые организация намерена достичь с ее помощью. Основное их содержание — бизнес-цели организации или клиента, заказывающих систему.
Пользовательские требования (user requirements) описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта. Пользовательские требования описывают, что пользователь должен иметь возможность делать с системой.
Функциональные требования (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях. Описываются в форме традиционных утверждений со словами «должен» или «должна». «Если в профиле пассажира не указаны предпочтения по выбору места, система резервирования должна сама назначить ему место»
Системные требования (system requirements) описывают требования к продукту, который содержит многие компоненты или подсистемы (ISO/IEC/IEEE 2011)
Пользовательские требования (user requirements) описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта. Пользовательские требования описывают, что пользователь должен иметь возможность делать с системой.
Функциональные требования (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях. Описываются в форме традиционных утверждений со словами «должен» или «должна». «Если в профиле пассажира не указаны предпочтения по выбору места, система резервирования должна сама назначить ему место»
Системные требования (system requirements) описывают требования к продукту, который содержит многие компоненты или подсистемы (ISO/IEC/IEEE 2011)
Ну это, помоему специфика разработки software — одной user story описывать кучу требований, которые при формальном описании вылезли бы на несколько страниц функциональных требований.
В принципе я считаю этот подход подходом "для ленивых" — запишем, как можем, а разработчик остальное сам додумает. Проблема в том, что замена одного слова в user story может привести к огромным изменениям в требованиях — что при формальном подходе является огромным плюсом — изменения в требования вносятся очень редко, ни и огромным минусом по той же причине.
Для начала давайте разберемся, что такое функциональные требования.
Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате.
Вигерса не читали, видимо
А как вы подходите к постановке задач разработчикам?
Со своей точки зрения, как разработчика, скажу, что бывает чертовски приятно поработать с аналитиком, который учился в техническом ВУЗ-е и сумел закончить хотя бы курс второй. Значит он\она наверняка слышал про такого чувака, как Фаулер М., с книгой — «UML. Основы», где есть глава 9 — Прецеденты. И про чувака Коберн А. с его «Современными методами описания функциональных требований к системам». Это, как бы, несколько букв из азбуки, которую должен знать бизнесс-аналитик. Ну, а если программеру приходится работать и тем, и другим, потом еще все это тестить в одно рыло, а за одно чинить поломанные спинки офисных стульев, раз уж пришел на работу, то непонятно зачем вообще придумали разделение труда. Тут вы правы — такая контора будет отставать от конкурентов. Но вы, судя по статье, уже на правильном пути. Книги могу подкинуть, если надо.
Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.
Интересно стало, известно ли вашей команде про Agile, где коммуникации ценятся выше заранее фиксированных договорённостей.
В каких интересно командах ценятся "долгие и бессмысленные коммуникации"?
На мой взгляд это совершенно правильное стремление развивать культуру инженерных коммуникаций на базе формальных описаний, а не пустопорожних рассуждений. Особенно если посмотреть на все это со стороны, которая платит за разработку. Меньше всего хочется оплачивать бесконечные и бесполезные совещания и планерки.
Разумеется, никто не хочет платить за «бесполезно» потраченное время. Однако в большинстве случаев заказчик оплачивает результат, и ему всё равно, каким образом он достигнут, если сроки и бюджет не превышены. В любом случае, никто не отменяет требования к формированию эффективных процессов внутри команды — и тут уже неважно, будет это достигаться, в частности, формальными документами или периодическими обсуждениями.
Интересно стало, известно ли вашей команде про Agile, где коммуникации ценятся выше заранее фиксированных договорённостей.
Как коммуникации запрещают формализовать требования?
Как сбор и формализация требований противоречит и связаны с «фиксированием договоренностей»?
и что значит «коммуникации ценятся»? метрики назовите.
было бы хорошо хоть раз в жизни услыхать это какими метриками оцениваются «коммуникации» и «требования»? Табличку сравнительную с методологией расчета представите?
P.S.
Пока единственная «практическая ценность» этого посыла — трактовка что-бы оправдать собственное раздолбайство.
RetailRocket спасибо за опыт! Очень было интересно читать и узнавать, как это работает у вас.
Sign up to leave a comment.
Как писать функциональные требования