Виды требований

Продолжаем разговор о требованиях. Часть 1

Повторим, что такое требование:

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

Кратко: требование это зафиксированное желание пользователя, которое должна выполнять система.

Это определение неидеально. Потому что есть требования, которые пользователь явно не высказывает, например, работа системы в режиме 24/7, или пользователь высказал какое-нибудь пожелание, но оно не было реализовано. Особый случай: требование высказано в устной форме. На мой взгляд, если требование не зафиксировано в письменном виде, то оно не существует. 

Требования можно разделить на две большие группы: 

• функциональные требования
• нефункциональные требования

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

Функциональные требования - что система должна делать. 

К функциональным требованиям относят:

• Бизнес-требования. Что система система должна делать с точки зрения бизнеса. Слово "бизнес" в данном контексте ближе к слову "заказчик".  Пример бизнес-требования: промо-сайт, привлекающий внимание определенной аудитории к определенной продукции компании. 
• Пользовательские требования  – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases). Иначе говоря, пользовательские требования - это что может сделать пользователь: зарегистрироваться, посмотреть определенную информацию, пересчитать данные по определенному алгоритму и прочее.
• Функциональные требования  – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.  Другими словами, что будут делать разработчики, чтобы выполнить пользовательские требования. 

В группу функциональных требований относят и системные требования. Эти характеристики могут описывать требования как к аппаратному обеспечению (тип и частота процессора, объём оперативной памяти, объём жесткого диска), так и к программному окружению (операционная система, наличие установленных системных компонентов и сервисов и т. п.). Обычно такие требования составляются производителем или автором ПО. Например, для игры это могут быть требования такого типа: видеокарта - объём памяти от 64 Мб, совместимость сDirectX 9.0b и новейшие драйвера.  Для сайта: ОС - Windows не ниже XP, браузеры IE не ниже 7.0 и так далее.

Почему важно указывать системные требования и утверждать их у заказчика? Если не указать,  например, что важно обеспечить просмотр сайта  в IE 6, то разработчики вполне могут выбрать такое архитектурное решение, которое не позволит корректно отображать сайт. Системные требования напрямую зависят от целевой аудитории проекта. 

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

• Бизнес-правила.  Они определяют почему система работать должна именно так, как написано. Это могут быть ссылки на законодательство, внутренние правила заказчика и прочие причины. Часто упускают этот раздел и получается, что некоторые системные решения выглядят нетипичным и совсем неочевидными. Например, многие табачные компании и компании, производящие алкоголь требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста)  возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability. 
• Внешние интерфейсы. Это не только интерфейсы пользователя, но и протоколы взаимодействия с другими системами. Например, часто сайты связаны с CRM системами. Особенности протокола взаимодействия "сайт-CRM"  также относятся к нефункциональным требованиям. 
• Атрибуты качества. Атрибуты касаются вопросов прозрачности взаимодействия с другими системами, целостности, устойчивости и т.п. К таким характеристикам относятся:
• легкость и простота использования (usability)
• производительность (performance)
• удобство эксплуатации и технического обслуживания (maintainability)
• надежность и устойчивость к сбоям (reliability)
• взаимодействия системы с внешним миром (interfaces)
• расширяемость (scalability)
• требования к пользовательским и программным интерфейсам (user and software interface).

Более подробно про атрибуты качества

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

Относительно состава групп функциональных и нефункциональных требований до сих пор нет согласия. Разные авторы и эксперты могут как добавлять, так и исключать подгруппы требований. Например, часто ограничения объединяют с бизнес-правилами, а бизнес-требования объединяют с ключевыми потребностями.

Существует прекрасная методика FURPS+, позволяющая создать качественную документацию при разработке ПО сколь угодно большой сложности. 

Все вышесказанное относится только к дисциплине "Управление требованиями" в рамках методологии RUP. В рамках  ГОСТ и определения требований другие и сами требования разбиваются на совершенно другие группы.

Читать про характеристики требований