Какие бывают требования?
В статье я буду использовать классификацию Вигерса, как одну из самых распространенных и достаточно подробных. На самом деле классификации требований (как и определения требований) существует довольно много, но они плюс-минус все похожи.
По ходу статьи я буду давать свои комментарии под такими сносками.
И так, по Вигерсу все требования делятся на два лагеря: функциональные и нефункциональные.
Функциональные требования в свою очередь подразделяются на:
- Бизнес-требования;
- Пользовательские требования;
- Непосредственно, сами функциональные требования;
- Системные требования;
Нефункциональные требования подразделяются на:
- Бизнес-правила;
- Ограничения;
- Атрибуты качества;
- Требования к визуализации (если есть UI).
Вот вам для наглядности классическая картинка из Вигерса:
Остановимся на каждом типе требований подробнее.
Функциональные требования
Как понятно из названия это требования непосредственно к функциональности системы (сервиса, приложения), которую от нее ожидают.
Бизнес-требования — описывают цель создания системы с точки зрения организации, т.е. какие задачи с помощью создаваемой системы планирует решить организация и какую пользу этот ей принесет.
Бизнес-требования, как правило, фиксируются в концепте (concept) или уставе проекта (project charter), иногда еще в так называемом в документе рыночных требований (market requirements document). В общем, в любом верхнеуровневом документе, который описывает образ и границы системы.
Если требования собираются для модуля существующей системы или небольшого приложения, т.е. без выделения отдельного проекта, то бизнес-требования фиксируются в отдельном разделе документа с функциональными требованиями. Обычно достаточно указать бизнес-цель создания системы, и то, каким образом планируется достичь эту цель.
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. Простым языком я бы называл это “хотелки” пользователей. В отдельный документ такие требования конечно не выносятся, а просто фиксируются в виде “Пользовательских Историй” (User Story) в тасктрекерах.
В мире гибких методологий (Agile, Scrum) беклог вашего проекта как раз наполняется подобными User Stories, при этом я всегда рекомендую аналитика подниматься от этих требований вверх, чтобы точно понимать какую цель преследует та или иная хотелка.
Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, что-бы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда их именуют “требованиями поведения” (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования фиксируются в отдельном документе который и будет основным документом используемым командой в процессе разработки и тестирования, обычно его называют SRS (Software Requirement Specification).
Термином системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы. Так пишет Вигерс, и лично мне это кажется непонятным, потому раскрою тут подробнее. Многие ошибочно полагают что системные требования это верхний уровень требований к системе, или требования к железу на котором система будет работать. На самом деле все проще — системные требования, это тоже самое что и пользовательские требования, но от других систем, т.е. говоря русским языком — это требования по интеграции вашей системы в корпоративный ландшафт.
Системные требования — это требования которые предъявляют вашей системе системы с которыми запланирована интеграция.
Обычно системные требования фиксируются: в контрактах заключаемых между системами, или в заголовочных файлах (хэдерах).
Я не рекомендую описывать системные требования в SRS, т.к. SRS это все же внутренний документ, которым будут пользоваться только ваши разработчики, в то время как контракт или хэдер — общие документы, и им пользуются обе стороны взаимодействия, потому в SRS вставляем только ссылку на контракт/хэдер, а все описание взаимодействия оставляем там.
Фух, разобрались с функциональными, перейдем к НФТ.
Нефункциональные требования (НФТ)
Про эти требования все постоянно забывают, ввиду нехватки времени и кажущейся неважности этих самых НФТ. Но тем не менее, знать и помнить про них надо обязательно.
Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес правила обычно фиксируются в SRS, в разделе ограничений.
Иногда к бизнес-правилам относят и различные негласные внутрикорпоративные договоренности, если вы новенький в компании не забудьте уточнить их наличие.
Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Атрибуты качества обычно фиксируются в соответствующем разделе SRS.
Иногда атрибуты качества называют “критерии успеха” — имея ввиду что по этим критериям пользователи будут оценивать будут оценивать качество вашей системы. Желательно выявить их на этапе сбора требований, и зафиксировать в user story и SRS. Т.о. вы не забудете предусмотреть реализацию мониторинга за этими показателями.
Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта, а так же описывают внешние взаимодействия между системой и внешним миром.
Спасибо что дочитали до конца, надеюсь, статья оказалась для вас полезной!
Все для аналитиков
Относительно состава групп функциональных и нефункциональных требований до сих пор нет согласия. Разные авторы и эксперты могут как добавлять, так и исключать подгруппы требований. Например, часто ограничения объединяют с бизнес-правилами, а бизнес-требования объединяют с ключевыми потребностями.
Существует прекрасная методика FURPS+, позволяющая создать качественную документацию при разработке ПО сколь угодно большой сложности.
Все вышесказанное относится только к дисциплине «Управление требованиями» в рамках методологии RUP. В рамках ГОСТ и определения требований другие и сами требования разбиваются на совершенно другие группы.
Какими бывают требования:
/>Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!
Спасибо! Я стал чуточку лучше понимать мир эмоций.
Вопрос: квадривиум — это что-то нейтральное, положительное или отрицательное?
Ассоциации к слову «требования»
Синонимы к слову «требования»
Предложения со словом «требование»
- Заёмщик обязан предоставлять банку по первому требованию необходимые документы, а также сведения, касающиеся его финансового состояния, на момент заключения договора, а также в течение всего периода пользования кредитом.
Цитаты из русской классики со словом «требования»
- Заметив в себе недовольство, они стараются прогнать его; но, видя, что оно не проходит, кончают тем, что дают полную свободу высказаться новым требованиям , возникающим в душе, и затем уже не успокоятся, пока не достигнут их удовлетворения.
Значение слова «требование»
ТРЕ́БОВАНИЕ , -я, ср. 1. Действие по глаг. требовать (в 1 и 4 знач.). (Малый академический словарь, МАС)
Афоризмы русских писателей со словом «требование»
-
в особенности серьезны и строги в отношении честности в самых близких отношениях, например, в отношении к семье, к деревне, к миру. В отношении к посторонним — с публикой, с государством, в особенности с иностранцем, с казною, для них смутно представляется приложимость общих правил честности.
Отправить комментарий
Дополнительно
Значение слова «требование»
ТРЕ́БОВАНИЕ , -я, ср. 1. Действие по глаг. требовать (в 1 и 4 знач.).
Предложения со словом «требование»
Заёмщик обязан предоставлять банку по первому требованию необходимые документы, а также сведения, касающиеся его финансового состояния, на момент заключения договора, а также в течение всего периода пользования кредитом.
В-четвёртых, в культурном отношении наши офицерские кадры недостаточно соответствовали требованиям современной войны.
Лицо, на которое возложена обязанность страхования, должно выполнить требование закона.
Функциональные и нефункциональные требования. Что это?
В какой-то момент меня попросили описать нефункциональные требования, и это вызвало ступор, поскольку данное словосочетание на тот момент мне ничего не говорило. Чтобы у вас такого не происходило, разберем оба вида требований.
Функциональные требования.
С ними всё, вроде бы, просто. Как может быть ясно из самого названия, они нужны, чтобы описать, какие функции должны быть реализованы в рамках задания. Т.е. это то, что нужно пользователю, чтобы делала система. Здесь описываются все действия, которые должны быть выполнены, субъекты, которыми должны быть они выполнены, и результаты, которые должны быть получены. Т.е. нужно описать, кто, когда и что делает, и что получает.
Пример функциональных требований – сценарии использования (Use cases), в которых описывается всё, что должна выполнять система.
Нефункциональные требования
С ними немного сложнее, поскольку в здесь нужно описать те дополнительные пожелания, требования, правила и ограничения, которые предъявляются к системе внешней средой, но не являются функциональными.
Согласно К. Вигерсу, можно выделить 3 группы нефункциональных требований:
- Внешние интерфейсы
- Атрибуты качества
- Ограничения
Это могут быть требования к производительности, используемой операционной системе, надежности, квалификации персонала, энергоэффективности и прочим параметрам, не связанным напрямую с функциональностью системы.
Могут быть требования к качеству кода, к использованию тех или иных компонентов, программных средств, библиотек, лицензий.
Могут быть требования к тому, что должен пользователь видеть на экране, какие кнопки может нажимать, а какие нет, и так далее.