Какая у меня складывается картина по результатам обсуждения документов, тезисно:
1. Почти у всех есть разделение на бизнес-документы и постановки задач для разработчиков.
2. Когда речь идёт о бизнес-требованиях, скорее имеются в виду "требования от бизнеса [к системе]", а не "требования к бизнесу". (Поэтому возникают такие гибриды, как "Бизнес-функциональные требования".)
3. Поэтому в документах бизнес-требований зачастую появляется уже и система, и описание процессов, т.к. уровень требований склонен "съезжать" в сторону автоматизации. При этом крайне редко используется анализ потребностей бизнеса, уточнение целеполагания (а правильную ли мы выбрали цель?), мотивации различных стейкхолдеров и анализ экономической эффективности решения. В общем, вся эта часть с анализом воздействий на бизнес и эффекта для бизнеса замыливается или вовсе не производится. Требования бизнеса фиксируются "как есть", некритически.
4. Очень редко упоминаются отдельно требования пользователей, стейкхолдеров, рынка или требования к продукту. Кажется, почти никто их отдельно не фиксирует и не анализирует. То есть, от верхнеуровневых требований бизнеса сразу же "проскакивают" к функциональным требованиям, без анализа процессов использования, целей и ожиданий пользователей. В лучшем случае этот анализ "прилипает" к документам функциональных требований.
5. Самый понятный документ — спецификация функциональных требований, причем уже в виде детальной постановки задачи. Непонятно, куда здесь девается процесс предложения и выбора альтернативных решений, видимо, он осуществляется в фоновом режиме и не фиксируется, это та самая скрытая работа по проектированию. Собственно, часто бывает, что функциональные требования фиксируются-то уже постфактум, после разработки.
В целом, кажется, что практика идёт по пути упрощения, и всё стремится к двум документам: БФТ/BRD и постановке (ТЗ/FSD). За бортом остаётся целеполагание и анализ бизнес-кейса, принятие решения о том, что цель в принципе достигается созданием какой-либо ИТ-системы; анализ и проектирование процессов использования, целей и ожиданий пользователей; выбор технических решений.
В этом смысле интересно, что системная инженерия делает акцент как раз на обратном: ConOps — это анализ бизнес-кейса, или миссии, выше уже стратегия компании; StRS — Stakeholders Requirements Specification (включая ожидания пользователей), OpsCon — операционная концепция, или концепция эксплуатации — а что с системой может происходить, штатно и нештатно, кто за это отвечает и как вообще с системой работать — извлекать пользу, сопровождать, обеспечивать ресурсами, ремонтировать, утилизировать и т.п. А уже потом — SysRS и SRS — системные требования и требования к ПО.
1. Почти у всех есть разделение на бизнес-документы и постановки задач для разработчиков.
2. Когда речь идёт о бизнес-требованиях, скорее имеются в виду "требования от бизнеса [к системе]", а не "требования к бизнесу". (Поэтому возникают такие гибриды, как "Бизнес-функциональные требования".)
3. Поэтому в документах бизнес-требований зачастую появляется уже и система, и описание процессов, т.к. уровень требований склонен "съезжать" в сторону автоматизации. При этом крайне редко используется анализ потребностей бизнеса, уточнение целеполагания (а правильную ли мы выбрали цель?), мотивации различных стейкхолдеров и анализ экономической эффективности решения. В общем, вся эта часть с анализом воздействий на бизнес и эффекта для бизнеса замыливается или вовсе не производится. Требования бизнеса фиксируются "как есть", некритически.
4. Очень редко упоминаются отдельно требования пользователей, стейкхолдеров, рынка или требования к продукту. Кажется, почти никто их отдельно не фиксирует и не анализирует. То есть, от верхнеуровневых требований бизнеса сразу же "проскакивают" к функциональным требованиям, без анализа процессов использования, целей и ожиданий пользователей. В лучшем случае этот анализ "прилипает" к документам функциональных требований.
5. Самый понятный документ — спецификация функциональных требований, причем уже в виде детальной постановки задачи. Непонятно, куда здесь девается процесс предложения и выбора альтернативных решений, видимо, он осуществляется в фоновом режиме и не фиксируется, это та самая скрытая работа по проектированию. Собственно, часто бывает, что функциональные требования фиксируются-то уже постфактум, после разработки.
В целом, кажется, что практика идёт по пути упрощения, и всё стремится к двум документам: БФТ/BRD и постановке (ТЗ/FSD). За бортом остаётся целеполагание и анализ бизнес-кейса, принятие решения о том, что цель в принципе достигается созданием какой-либо ИТ-системы; анализ и проектирование процессов использования, целей и ожиданий пользователей; выбор технических решений.
В этом смысле интересно, что системная инженерия делает акцент как раз на обратном: ConOps — это анализ бизнес-кейса, или миссии, выше уже стратегия компании; StRS — Stakeholders Requirements Specification (включая ожидания пользователей), OpsCon — операционная концепция, или концепция эксплуатации — а что с системой может происходить, штатно и нештатно, кто за это отвечает и как вообще с системой работать — извлекать пользу, сопровождать, обеспечивать ресурсами, ремонтировать, утилизировать и т.п. А уже потом — SysRS и SRS — системные требования и требования к ПО.