Виды и качество требований¶
Требование — это документально зафиксированное утверждение о том, каким свойством должен обладать объект, какую функцию он должен выполнять или каким условиям соответствовать. Требования выступают исходным пунктом проектирования, разработки, закупки и приёмки продукции, программного обеспечения, строительных объектов и организационных процессов. Совокупность требований к объекту называется базой требований, а управление ими — отдельной дисциплиной инженерии требований.
¶Место требований в жизненном цикле
Требования формируются на ранних стадиях работы над объектом и развиваются вместе с ним. В классической каскадной модели их фиксируют до начала проектирования, в гибких методологиях (Agile) они существуют в виде постоянно пополняемого журнала задач. Ошибка в требовании, обнаруженная на этапе эксплуатации, обходится на порядки дороже, чем выявленная на этапе анализа, поэтому качеству требований уделяется особое внимание.
¶Виды требований
¶По уровню детализации
- Бизнес-требования — описывают, зачем создаётся объект: цели организации, ожидаемую выгоду, критерии успеха.
- Требования пользователей — формулируют потребности конкретных групп пользователей, часто в виде сценариев использования.
- Системные и функциональные требования — определяют, что именно должна делать система: перечень функций, входные и выходные данные, правила обработки.
- Нефункциональные требования — задают, как система должна работать: производительность, надёжность, безопасность, удобство, совместимость.
¶По содержанию
- Функциональные — описывают поведение объекта при определённых условиях.
- Нефункциональные — делятся на атрибуты качества (скорость отклика, доступность), ограничения (используемые технологии, стандарты, законодательные нормы) и внешние интерфейсы.
- Обратные требования — указывают, что система делать не должна.
¶По источнику и обязательности
Различают требования заказчика, нормативные (заданные законами, ГОСТами, техническими регламентами) и внутренние (стандарты организации). По степени обязательности выделяют обязательные, желательные и опциональные требования; такая градация помогает расставлять приоритеты при ограниченных ресурсах.
¶По форме представления
Требования могут быть текстовыми, табличными, в виде моделей (диаграммы, схемы), прототипов или формальных спецификаций. В инженерии ПО распространены пользовательские истории, варианты использования и спецификации в нотации шаблонов.
¶Качество требований
Качество отдельного требования и качество их совокупности оценивают по ряду признаков.
¶Свойства отдельного требования
- Полнота — требование содержит всю информацию, необходимую для его реализации, без отсылок к неописанным деталям.
- Непротиворечивость — оно не конфликтует с другими требованиями.
- Однозначность — допускает единственное толкование.
- Проверяемость (верифицируемость) — существует способ объективно подтвердить выполнение, например измерением или тестом.
- Атомарность — описывает одно свойство или функцию, а не несколько сразу.
- Корректность — отражает реальную потребность, а не домысел автора.
- Необходимость — без него объект теряет требуемые свойства.
- Осуществимость — реализуемо в рамках имеющихся технологий, бюджета и сроков.
- Трассируемость — можно проследить связь с источником (целью, нормой, запросом пользователя) и с элементами реализации.
¶Свойства набора требований
- Полнота набора — охвачены все потребности и сценарии.
- Согласованность — отсутствуют взаимные противоречия.
- Непротиворечивость приоритетов — расстановка важности не создаёт конфликтов.
- Стабильность — частота изменений после согласования невелика.
- Понятность — документ доступен для чтения всем заинтересованным сторонам.
¶Критерии и методы оценки
Для проверки качества применяют наборы критериев, среди которых наиболее известны модели, требующие от требования конкретности, измеримости, достижимости, актуальности и ограниченности по времени. Распространены и «инвестиционные» критерии: независимость, договороспособность, ценность, оцениваемость, компактность, тестируемость.
Практические методы оценки включают:
- Инспекции и рецензирование — ручной разбор документов группой специалистов.
- Проверку по чек-листам — формализованный перечень типовых дефектов.
- Прототипирование — уточнение требований через макеты.
- Тестовое проектирование — попытка заранее написать проверки; если тест невозможен, требование неверифицируемо.
- Трассировку — построение матриц связей между требованиями, целями и реализацией.
¶Типичные дефекты требований
Среди наиболее частых недостатков выделяют неполноту, двусмысленность формулировок, противоречия, смешение уровней абстракции, избыточность, отсутствие критериев приёмки, «плавающие» требования, меняющиеся без процедуры согласования, а также требования, описывающие решение вместо потребности. Отдельная проблема — требования, которые невозможно проверить, например «система должна быть удобной» без указания измеримых показателей.
¶Управление изменениями
Требования меняются под влиянием новых задач, законодательства и обратной связи. Для контроля используют базовые версии (baseline), процедуры согласования изменений, журналы запросов и оценку влияния на сроки и стоимость. В российских проектах требования нередко закрепляются в техническом задании по ГОСТ, а также в договорной документации, что придаёт им юридический статус.
¶Значение
Качественно сформулированные требования снижают риски переделок, служат основой для оценки трудозатрат, договоров и приёмки, обеспечивают взаимопонимание между заказчиком и исполнителем. В инженерии требований сложилась практика: сначала выявить потребности, затем выразить их в проверяемой форме, согласовать и только после этого переходить к проектированию.
Источники: ГОСТ 34.602, ГОСТ 19.201, международные стандарты по системной и программной инженерии, учебные курсы по инженерии требований, публикации по управлению проектами.