3.1.3. Инженерия требований
Инженерная дисциплина анализа и документирования требований заключается в преобразовании предложенных заказчиком требований к системе в описание требований к ПО, их спецификацию и валидацию. Она базируется на моделях процессов разработки требований, действиях актеров и управлении постепенным преобразованием требований к проектным решениям и спецификациям компонентов с обеспечением их качества.
Модель процесса определения требований - это схема процессов ЖЦ, которые выполняются от начала проекта и до тех пор, пока не будут определены и согласованы требования.
Управление требованиями к ПО заключается в планировании и контроле формирования требований, задании на их основе проектных решений, в преобразовании их в спецификации компонентов системы на других процессах.
Качество и процесс улучшения требований - это процесс проверки характеристик и атрибутов качества (надежность, реактивность и др.), которыми должна обладать система и ПО, методы их достижения на процессах ЖЦ.
Управление требованиями к системе - это руководство процессами формирования требований на всех этапах ЖЦ, которое включает управление изменениями требований, отражающих свойства программного продукта, а также восстановление источника требований. Неотъемлемой составляющей процесса управления является трассирование требований, состоящее в отслеживании правильности задания и реализации требований к системе и ПО на этапах ЖЦ и обратный процесс сверки ПС с заданными требованиями.
Основные задачи управления требованиями это:
разработка атрибутов требований,
управление вариантами требований,
управление рисками, возникающими при неточном определении требований,
контроль статуса требований, измерение усилий при формировании требований;
реализация требований на этапах ЖЦ.
Разработка и управление требованиями связана с другими областями знаний (рис. 3.2.): проектирование, интеграция, управление качеством, версиями, рисками и др. Кроме того, приведены основные задачи разработки требований: спецификация и утверждение, формирование проектных решений.
Рис. 3.2. Разработка, управление требованиями и связь с задачами SWEBOK
Планирование работ на проекте касается вопросов организации интеграции компонентов, управления рисками, версиями системы, на которые влияют заданные требования и их изменения.
Управление рисками состоит в контроле появления и обнаружения неадекватных ситуаций при реализации требований, оценке их влияния на другие процессы и в предупреждении рисковых ситуаций. Управления версиями системы включает формирование конфигурации системы в принятых для системы терминах и обозначениях.
3.1.4. Фиксация требований
Сбор требований является начальным этапом процесса разработки ПС, завершается формированием списка требований к системе, именуемого в отечественной практике техническим заданием. Фиксация требований (Requirement Capturing) в техническом задании определяется желаниями заказчика получить при реализации заданные им свойства системы. При этом предусмативается спецификация, верификация и валидация требований на правильность, соответствие и полноту.
Спецификация требований к ПО - это формализованное описание функциональных, нефункциональных и системных требований, требований к характеристикам качества, а также к структуре ПО, принципам взаимодействия с другими компонентами, алгоритмам и структуре данных системы.
Валидация требований - это проверка требований, для того чтобы убедиться, что они определяют именно данную систему. Заказчик и разработчик ПО проводят экспертизу сформированного варианта требований с тем, чтобы разработчик мог далее проводить его проектирование. Одним из методов валидации является прототипирование, т.е. быстрая отработка отдельных требований на конкретном инструменте, анализ масштаба изменения требований, измерение функциональности и стоимости системы, а также определение зрелости процессов определения требований.
Верификация требований - это процесс проверки правильности спецификации требований на их соответствие, непротиворечивость, полноту и выполнимость, а также на соответствие стандартам. В результате проверки требований создается согласованный выходной документ, устанавливающий полноту и корректность требований к ПО, а также возможность продолжить проектирование ПО.