Требования к системе в проектировании¶

Требования к системе — это совокупность формализованных условий, ограничений и характеристик, которым должна удовлетворять проектируемая или эксплуатируемая система для признания её пригодной к использованию по назначению. Под системой в данном контексте понимается любой искусственный объект, обладающий целостностью и функциональностью: программное обеспечение, техническое устройство, информационная система, организационно-технический комплекс или автоматизированная линия. Требования служат исходной точкой жизненного цикла системы и одновременно критерием приёмки результата.

¶Место требований в жизненном цикле

Работа с требованиями образует начальную фазу жизненного цикла, предшествующую проектированию, разработке и испытаниям. В классических моделях (каскадной, V-модели) требования фиксируются до начала конструирования, а их изменение после утверждения считается управляемым событием, влияющим на сроки и стоимость. В итеративных методологиях требования уточняются по мере разработки, однако базовый набор всё равно формулируется заранее.

Ошибка или пропуск требования на ранней стадии обходится существенно дороже, чем на поздней: исправление дефекта, выявленного на этапе эксплуатации, требует переработки проектной документации, кода, аппаратной части и повторных испытаний.

¶Классификация требований

Требования принято разделять по нескольким основаниям.

¶По содержанию

• Функциональные — описывают, что система должна делать: перечень функций, входные и выходные данные, реакции на события, правила обработки.
• Нефункциональные — описывают, как система должна это делать: производительность, надёжность, безопасность, удобство использования, совместимость, сопровождаемость.

¶По уровню детализации

• Требования к системе в целом (назначение, границы, внешние интерфейсы).
• Требования к подсистемам и компонентам.
• Требования к отдельным функциям и операциям.

¶По источнику

• Требования заказчика (бизнес-требования), отражающие потребности и цели организации.
• Требования пользователей, описывающие задачи конкретных категорий персонала.
• Требования разработчика, вытекающие из технологических и конструктивных ограничений.
• Требования регулирующих органов — законодательные, санитарные, метрологические, отраслевые нормы.

¶Основные группы характеристик

Нефункциональные требования обычно группируют следующим образом:

¶Свойства корректного требования

Качественно сформулированное требование обладает набором признаков:

• Полнота — содержит всю информацию, необходимую для реализации и проверки.
• Непротиворечивость — не конфликтует с другими требованиями.
• Однозначность — допускает единственную трактовку.
• Проверяемость — допускает объективную проверку методами испытаний, измерений или анализа.
• Атомарность — описывает одно свойство или функцию.
• Трассируемость — может быть связано с источником и с результатами проверки.
• Актуальность — отражает текущие потребности и ограничения.

Формулировки с расплывчатыми словами («удобный», «быстрый», «по возможности») переводят в измеримые величины: «время отклика не более 2 секунд при 500 одновременных запросах».

¶Методы выявления и документирования

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

• техническое задание — основной отечественный документ, регламентированный государственными стандартами;
• спецификация требований к программному обеспечению;
• варианты использования и пользовательские истории;
• реестр требований с атрибутами (идентификатор, приоритет, статус, версия).

Приоритизация выполняется методами ранжирования, например по шкале «обязательно — желательно — опционально» или по критериям важности и трудоёмкости.

¶Управление изменениями

В ходе проекта требования неизменно подвергаются правкам. Управление изменениями включает регистрацию запроса, оценку влияния на сроки, стоимость и архитектуру, решение уполномоченного органа (совета по изменениям), обновление документации и уведомление исполнителей. Без контролируемой процедуры возникает «расползание» объёма работ, ведущее к срыву сроков и превышению бюджета.

¶Верификация и валидация

Различают два процесса проверки. Верификация отвечает на вопрос, правильно ли построена система относительно записанных требований. Валидация отвечает на вопрос, те ли требования были записаны, то есть соответствует ли система реальным потребностям. Инструментами служат экспертиза документов, прототипирование, моделирование, приёмочные испытания и трассировочные матрицы.

¶Особенности в отраслях

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

¶Значение

Требования определяют облик будущей системы, служат основой договоров, технических заданий и испытаний, позволяют оценить трудозатраты и риски. Их качество прямо влияет на стоимость владения системой на протяжении всего жизненного цикла. В российской практике документирование требований опирается на государственные стандарты серии ГОСТ, а также на отраслевые нормативные документы.

Источники: ГОСТ 34.602, ГОСТ 19.201, ISO/IEC/IEEE 29148, материалы по системной и программной инженерии.