Требования
August 10, 2023
Требования. Часть 4. Уровни и виды требований
- Условие или возможность, требуемая пользователем для решения задач или достижения целей.
- Условие или возможность, которыми система/компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующими документами.
- Описание условий или возможностей, перечисленных в предыдущих пунктах.
Требования — это спецификация того, что должно быть реализовано. В них должно быть описано:
Они могут быть ограничены процессом разработки системы.
Уровни требований
- Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы.
Как правило, их высказывают те, кто финансируют проект, заказчики или покупатели системы, менеджер реальных пользователей, отдел маркетинга.
Бизнес-требования формулируют в документе об образе и границах проекта — уставе проекта (project charter), или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами расползания границ. - Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система.
К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы. - Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда именуемые требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
- Термином системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть система (IEEE, 1998с). Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.
- Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные варианты использования, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.
- Нефункциональные требования содержат цели и атрибуты качества.
- Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограничения дизайна и реализации.
- Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.
Спецификация требований не содержит деталей дизайна или реализации (кроме известных ограничений), данных о планировании проекта или сведений о тестировании.
Требования можно разделить на две большие группы:
Существует прекрасная методика FURPS+, позволяющая создать качественную документацию при разработке ПО сколь угодно большой сложности.