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

Уровни требований по Вигерсу

Карл Вигерс определяет три уровня требований: бизнес-требования, требования пользователей, функциональные требования. Отдельной строкой выделяются нефункциональные требования системы. Бизнес-требования содержат высокоуровневые цели организации или заказчиков системы. Требования пользователей описывают цели и задачи, которые система позволит пользователям решить. Функциональные требования определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Нефункциональные требования описывают цели и атрибуты качества.

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

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

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

Структура требований по Вигерсу. Оригинальная и дополненная схемы.

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

Классификация требований по Леффингуэллу

Разделение требований по уровням описывает и Дин Леффингуэлл. Его подход к управлению требованиями основывается на необходимости понимания всеми членами команды разработки “карты территории” и текущего положения проекта на ней. Иными словами, все должны понимать на какой стадии находится проект, с какими людьми необходимо общаться, на каком языке говорят эти люди и какая информация необходима для продолжения работ. Сама по себе карта - это не что иное, как разделение требований по уровням, в соответствии с назначением требований.

Иерархия требований Леффингуэлла.

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

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

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

RUP – это процесс, направленный на поддержку коллективной разработки программных средств. Все участники проекта используют единую базу знаний, единый процесс, единый взгляд на разработку, единый язык моделирования. Понятие “Требование” в RUP определяется как состояние или возможность, которой должна обладать (соответствовать) система. Важным примечанием является то, что само по себе требование может быть получено непосредственно из потребностей пользователя, либо указано в контракте, стандарте, спецификации или другом официально установленном документе. Требования могут быть классифицированы по модели FURPS+, автором которой является Роберт Грэйди (Robert Grady) из Hewlett-Packard. Сокращение FURPS расшифровывается так:

• Functionality, функциональность
• Usability, удобство использования
• Reliability, надежность
• Performance, производительность
• Supportability, поддерживаемость

Приставка + указывает на возможность дополнительного описания ограничений проектирования, разработки, ограничений на интерфейсы, физических ограничений.

Основным отличием от классификации по Вигерсу является выделение наряду с функциональностью, требований к удобству и части атрибутов качества (надежности, производительности и поддерживаемости). Причем бизнес-требования вынесены за рамки классификации и явным образом не определяются как отдельный вид. Стоит отметить, что и требования к удобству - это не совсем то же самое, что пользовательские требования.

Требования в Software Requirements Specification

Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) — структурированный набор требований к программному обеспечению и его внешним интерфейсам. В стандарте ISO/IEC/IEEE 29148:2011, который пришел на смену устаревшему IEEE 830, содержится рекомендации к структуре и методам описания программных требований.

• Функциональность системы
  • Функциональный блок X (таких блоков может быть несколько)
    • Описание и приоритет
    • Причинно-следственные связи, алгоритмы (движение процессов, workflows)
    • Функциональные требования
• Требования к внешним интерфейсам
  • Интерфейсы пользователя (UX)
  • Программные интерфейсы
  • Интерфейсы оборудования
  • Интерфейсы связи и коммуникации
• Нефункциональные требования
  • Требования к производительности
  • Требования к сохранности (данных)
  • Требования к качеству программного обеспечения
  • Требования к безопасности системы
  • Требования на интеллектуальную собственность

В данной классификации функциональность системы или ее блока определяется совокупностью описания процесса (workflow) и непосредственно функциональных требований к этому процессу или его частям. Нечто похожее встречалось у Леффингуэлла в части описания прецедентов. Однако, прецедентная модель содержит в себе взаимодействия человек-система, workflow же является представлением потока задач (или работ) в процессе и связанных с ним подпроцессах, включая специфические работы, информационные зависимости и последовательность решений. То есть workflow охватывает и внесистемные взаимодействия, которые могут прямо или косвенно влиять на проектирование архитектуры системы.

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

SWEBOK (Software Engineering Body of Knowledge) — международный стандарт ISO/IEC TR 19759 от 2015 г., в котором описана общепринятая сумма знаний по программной инженерии. Требованиям к ПО отведен отдельный раздел. В актуальной 3 версии структура требований представлена следующим образом:

• Требования к продукту и процессу
• Функциональные и нефункциональные требования
• Количественные требования
• Системные требования и требования к программному обеспечению
• Эмерджентные свойства

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

Виды требований по ГОСТ 34-серии

В ГОСТ 34.602-89 “Техническое задание на создание автоматизированной системы” приводится содержание раздела «Требования к системе», состоящего из подразделов “Требования к системе в целом”, “Требования к функциям (задачам), выполняемым системой”, “Требования к видам обеспечения”. При этом дается разъяснение, что состав требований к системе, включаемых в данный раздел документа, устанавливают в зависимости от вида, назначения, специфических особенностей и условий функционирования конкретной системы. В каждом подразделе приводят ссылки на действующие нормативные или технические документы, определяющие требования к системам соответствующего вида.

Данное описание раздела ТЗ по ГОСТ во многом похоже на Спецификацию требований на ПО по Вигерсу, однако отличия все же имеются. Убедиться в этом можно, изучив более подробно пункт 2.6. ГОСТ 34.602-89.

В подразделе «Требования к системе в целом» указывают:

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

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

В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы.

Не сложно заметить, что на первый план вынесены атрибуты качества системы (нефункциональные требования согласно многим описанным классификациям), подраздел «Требование к функциям (задачам)» можно охарактеризовать как совокупность функциональных, пользовательских и бизнес-требований, так как информация в нем должна отвечать на вопросы “Что нужно реализовать?” и “Как реализовать?” в системе. Последний подраздел содержит в себе требования к процессу выпуска и эксплуатации продукта.

Выводы

Описав основные тезисы наиболее популярных подходов к классификации требований, я по сути перечислил все основные виды требований. Как мне кажется, однозначного понимания иерархии видов требований и взаимозависимости их друг от друга ни один из подходов не дает по той простой причине, что многие подходы фокусируют свое внимание на каком-то одном аспекте процесса работы с требованиями, либо оставляют отдельные виды требований за рамками классификации. Например, Вигерс показывает уровни требований от более общих к более частным, опираясь на процесс сбора и формирования требований, в котором важно повышать уровень детализации приближаясь к началу разработки. Леффингуэлл говорит о процессе управления требованиями, где важно уметь отслеживать состав и содержание тезисов (требований к системе). ГОСТ делает акцент на отражении требований в документации, отсюда такое большое количество видов требований (в основном нефункциональных) к системе и процессу ее разработки, пользовательские и бизнес-требования в этой части отходят на второй план, исключая любое упоминание об уровнях требований. RUP, имея в своем арсенале такой мощный инструмент как UML, оперирует сущностями, которые могут быть смоделированы в нем. SRS и SWEBOK очень близки к уровневой иерархии требований, хоть и не упоминают некоторые виды, оставляя их описание на усмотрение аналитикам.

1. Вигерс, К. Разработка требований к программному обеспечению / К. Вигерс; пер. с англ. — М.: Издательско-торговый дом «Русская Редакция», 2004. — 576с.: ил.

2. Леффингуэлл, Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. / Д. Леффингуэлл, Д. Уидриг; пер. с англ. Н.А. Орехова — М.: Издательский дом «Вильямс», 2002. — 576с.: ил.

3. Крачтен Ф. Введение в Rational Unified Process / Ф. Крачтен; пер. с англ. А.В. Назаренко — М.: Издательский дом «Вильямс», 2002. — 239с.: ил.