Концептуальная модель типов требований
Коротко Готовая структура для инструмента управления требованиями: шестнадцать типов требований с короткими кодами, отдельная подсхема для нефункциональных типов и четыре атрибута, которые есть у каждого элемента. Классификация превращается в поля, теги и фильтры, которые можно настроить в первый же день.
По материалам: А. Перерва, В. Иванова, «Путь аналитика», разд. 4.2.4 «Концептуальная модель типов требований».
На этой странице
Главные идеи#
Рабочая схема, а не теория#
Академические классификации, например уровни Вигерса и Битти, объясняют, как соотносятся виды требований. Перерва и Иванова предлагают типы и атрибуты из проектной практики: их можно перенести в трекер как есть, и они же определяют, что к чему трассируется.
Шестнадцать типов по группам#
Группы введены для удобства чтения; коды — авторские.
| Группа | Код | Что содержит |
|---|---|---|
| Исходные данные | ANSW | Ответы и сведения, собранные у заинтересованных сторон, в исходном виде — чтобы показать, как учтён каждый ответ, и обосновать решения |
| Исходные данные | STKR | Запросы заинтересованных сторон: непротиворечивый и полный перечень; для проверки трассируется на BR и BRULE |
| Бизнес | BR | Бизнес-требования: зачем организации нужна система |
| Бизнес | BRULE | Бизнес-правила, которые защищают структуру бизнеса или контролируют его операции и влияют на них |
| Бизнес | BVISION | Видение продукта со стороны бизнеса: ожидания заинтересованных сторон, стандартизация |
| Ограничения | ASSUM | Внешние ограничения и допущения, которые исходят от заинтересованных сторон, бизнес-требований или бизнес-правил |
| Ограничения | TECH | Внутренние ограничения, которые следуют из выбранных технологий и платформ; их задаёт архитектор |
| Ограничения | SERT | Требования органов сертификации и регуляторов |
| Ограничения | STSTD | Стандарты (например, ГОСТы), выявленные в ходе бизнес-анализа; архитектурные стандарты рассматривают отдельно |
| Ограничения | CHAR | Полезные характеристики аналогичных или унаследованных систем, которые новая система должна сохранить |
| Решение | TVISION | Концепция системы: как BVISION будет реализовано на выбранных технологиях |
| Решение | UREQ | Пользовательские требования, сформулированные непосредственно будущими пользователями |
| Решение | UC | Варианты использования: наборы действий, которые дают действующему лицу значимый результат |
| Решение | FR | Функциональные требования: проверяемые утверждения о том, что умеет делать система |
| Решение | NFR | Нефункциональные требования: проверяемые утверждения, часто с числовыми целевыми значениями |
| Общее | TERM | Термины и понятия глоссария |
Как связаны типы#
Авторы описывают цепочку: BVISION и ANSW ведут к UREQ, UREQ — к UC, а UC — к FR. TVISION учитывает FR и формирует или ограничивает NFR. Элементы STKR трассируются на BR и BRULE, и так видно, подкреплён ли каждый запрос заинтересованной стороны бизнес-причиной.
Подтипы нефункциональных требований#
Для NFR есть собственная подсхема из семнадцати подтипов: пользовательский интерфейс (GUI), взаимодействие с внешними системами (ICE, Interface Control Element — «элемент управления интерфейсом»), документация (DOC), данные (DATA), сертификация (CERT), а также окружение, аппаратные средства, программные средства, развёртывание, производительность, надёжность, масштабируемость, безопасность, эргономика, лицензирование, совместимость и поддержка.
Четыре атрибута у каждого элемента#
- Приоритет (Priority) — Hot, High, Medium (по умолчанию) или Low. Hot — управленческое решение вне очереди: элемент идёт раньше всех остальных, даже раньше High. Приоритет обычно согласуют с заказчиком.
- Сложность (Complexity) реализации без учёта трудоёмкости тестирования — Challenge (архитектурно значимо, серьёзный технологический риск; задаёт менеджер проекта после решения совета по управлению изменениями), Solution (архитектурно значимо и относится к сути решения; задаёт менеджер проекта вместе с архитектором), Normal (по умолчанию) или Easy (уровень быстрых изменений; можно не включать в проверки трассировки).
- Стоимость (Cost) — общая оценка трудоёмкости в человеко-часах, не меньше одного часа; её задаёт менеджер проекта и пересчитывает при анализе влияния изменения.
- Исполнитель (Assigned To) — кто будет реализовывать элемент; его назначает менеджер проекта.
Как применять#
- Начните с малого. Сначала настройте STKR, BR, BRULE, UC (или UREQ), FR, NFR и TERM. Типы ограничений добавьте, когда заинтересованные стороны и архитекторы начнут о них говорить.
- Определите правила связей. Разрешайте только связи из цепочки выше, например от FR к UC и от STKR к BR.
- Добавьте четыре атрибута со значениями по умолчанию: приоритет Medium, сложность Normal.
- Запишите, кто что может задавать. Например, стоимость и исполнителя задаёт только менеджер проекта, а для Hot нужен конкретный утверждающий.
- Постройте три постоянных отчёта: элементы STKR без связи с BR или BRULE (запросы без бизнес-причины), FR без UC («сироты») и список элементов Hot (он должен оставаться коротким).
- Пересчитывайте стоимость, когда запрос на изменение затрагивает элемент.
Шаблон#
| ID | Тип | Формулировка | Трассируется на | Приоритет | Сложность | Стоимость (ч) | Исполнитель |
|----|-----|--------------|-----------------|-----------|-----------|---------------|-------------|
| | | | | Medium | Normal | | |
Пример#
Элементы «Мастерской», вымышленной сети веломастерских:
| ID | Тип | Формулировка | Трассируется на |
|---|---|---|---|
ANSW-012 |
ANSW | Старший сотрудник стойки приёма: «Чаще всего нам звонят клиенты, которые спрашивают, готов ли их велосипед». | — |
STKR-004 |
STKR | Клиенты хотят знать статус ремонта, не звоня в мастерскую. | BR-002 |
BR-002 |
BR | Сократить число звонков о статусе на стойки приёма. | — |
BRULE-007 |
BRULE | Заказ готов только после того, как механик подписал итоговую проверку безопасности. | — |
UC-05 |
UC | Проверить статус ремонта. | STKR-004 |
FR-031 |
FR | Система должна показывать текущий статус каждого ремонтного заказа клиента. | UC-05, BRULE-007 |
TECH-02 |
TECH | Выбранная платформа поддерживает только уведомления по электронной почте и SMS. | — |
FR-031 получает приоритет High, сложность Normal и стоимость 16 ч. Когда позже приходит запрос добавить push-уведомления в приложении, он сталкивается с TECH-02 и сразу виден как вопрос об ограничении для архитектора, а не как простая функция.
Подводные камни#
- «Hot» для всего. Если элементов Hot больше нескольких, метка теряет смысл. Требуйте утверждающего.
- Устаревшая стоимость. Если стоимость не обновляют после изменений, анализ влияния бесполезен.
- Типы без правил связей. Типы остаются просто метками, пока вы не решите, что к чему должно трассироваться, и не начнёте строить отчёты о пробелах.
Источники и что почитать#
- А. Перерва, В. Иванова. Путь аналитика. Практическое руководство. Разд. 4.2.4.
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Академическая классификация, которую дополняет эта схема.