Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
180 |
“возможности” — именно “возможности” фокусируют требования).
Какие бывают виды требований
Самые распространённые практики инженерии требований — это выявление функций (поведения) системы из каких-то сценариев взаимодействия (user stories, use cases: там множество вариантов). Иногда про такие требования, выведенные из сценариев использования, говорят “функциональные требования”, противопоставляя их “нефункциональным” (например, требованиям надёжности, ремонтопригодности, доступности, безопасности и т.д., так называемые “-ости”, по-
английски это будут “ilities” — reliability, repairability, availability, safety, etc.). Но есть замечание Donald Firesmith, что “не бывает нефункциональных требований” — ибо все эти “требования качества” (как их иногда тоже называют) это абсолютно функциональные требования, характеризующие функции системы с точки зрения каких-то стейкхолдеров, обычно не рассматривающихся в сценариях “пользования”.
Видов требований существуют десятки, но принадлежность к этим видам не так уж важна: если вы встретили в пустыне льва, вам же не нужно знать, что он из семейства кошачьих? Много важнее заметить, что этот лев рядом с вами! Главный источник ошибок в проекте — это неведение относительно наличия каких-то требований. Впрочем, классификация может помочь, если вы зададите себе вопрос: какие виды требований вы ещё не рассматривали для вашего проекта? Вот пример классификации требований качества — знаете ли вы их для вашего проекта?
Подробнее про требования защитоспособности (выделенные на рисунке выше) можно посмотреть в презентации Дональда Файерсмита — http://vniiaes.ru/HTML/RU/Docs/RuSEC%202010.rar (и там же можно посмотреть на презентацию по целеориентированной инженерии требований Яна Александера).
Кто должен делать требования
Иногда между командой инженеров и заказчиком можно услышать следующий разговор со стороны инженеров: “вы предоставьте нам подробные требования,
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
181 |
иначе мы и пальцем не пошевелим”. Должен разочаровать: это неверная позиция. Заказчик может представить только свои нужды, а не требования к системе. Если у заказчика есть инженеры (или заказ на разработку системы делает инженерная фирма), то есть шанс получить “требования стейкхолдера”. Но это ещё не требования к системе. Разрабатывает требования обычно команда проекта, они не приходят извне проекта. Другое дело, что без активного участия стейкхолдеров (в том числе представителей организации заказчика) требования не подготовишь. Но в любом случае, ответственность за требования лежит на команде проекта, а не на заказчике.
Заказчик же может, например, завизировать разработанные командой проекта требования — но и в этом случае, изготовленная система, которая не удовлетворит его нуждам (needs) по причине того, что требования были сформулированы командой проекта неправильно, может встретить серьёзные проблемы при приёмке/validation (хотя блестяще пройдёт проверку/verification — инженеры подтвердят сами себе, что изготовили ровно то, что планировали, хотя это не то, в чём нуждался клиент).
Почему за требования ответственен инженер? Потому что он должен сделать реверс-инжиниринг использующей системы: часто клиент на это не способен, хотя он обычно и весьма знающ об особенностях используемой системы, но эти знания могут быть совсем не такими, на которые мог бы расчитывать инженер.
Целеориентированная инженерия требований
Целеориентированная системная инженерия (goal-oriented requirements engineering, GORE) подразумевает более или менее формальное описание дополнительных по отношению к требованиям сущностей (таких как стейкхолдеры, цели, влияния, аргументы в защиту, альтернативы и т.д.). Это даёт возможноть более точно документировать происхождение требований, обосновывать выбор требований, связывать выбор проектных решений (архитектурных решений) с требованиями. Получаемые сложные структуры всех этих стейкхолдеров-целей-влияний- альтернатив-требований-аргументов-и_т.д. называют моделями требований, а использующую такие модели инженерию требований – моделеориентированной инженерией требований. В инженерии предприятий (enterprise engineering) модели требований [к предприятию/к архитектуре предприятия] часто называют мотивационными моделями (motivation не только «движущая сила, побуждение»,
но и обоснование – reason, justification).
Примерами языков для таких моделей требований могут быть GRL (http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/WebHome), подходе i* (этот подход родоночальник и классика GORE — istar.rwth-aachen.de), Motivational Extension в ArchiMate 2.0 (http://pubs.opengroup.org/architecture/archimate2doc/chap10.html#_Toc371945252), Model-based requirement discovery от Яна Александера (http://www.scenarioplus.org.uk/papers/mbrd/Modelbased_Requirements_Discovery.PDF).
Моделеориентированность (как шаг к формальным требованиям) хороша для проведения проверок самих требований (хотя она не поможет найти пропущенное требование) – смотри вопросы Яна Александера по валидации требований на основе модели требований (слайд 26 по предыдущей ссылке).
Требования должны документироваться и затем использоваться для проведения испытаний (проверок и приёмок) как чеклисты. Проверки – это насколько