Инженерия требований — различия между версиями

Версия 21:52, 25 ноября 2015

Инженерия требований — это поддисциплина системной инженерии, занимается разработкой требований.

Главная часть инженерии требований — это реверс-инжиниринг использующей (над)системы (using system) для того, чтобы получить описания “чёрного ящика”.

Проблема: все требования проходят по ЖЦ асинхронно, и даже критерии одной стадии выполняются не одновременно. Concurrent requirements engineering – параллельная инженерия требований.

Инженерия требований как практика делится на две части:

• Разработка требований
• Управление требованиями

Управление требованиями

Инженерия требований должна начинаться с управления требованиями. Если в суматохе самое распрекрасное требование будет открыто, но потом потеряно в обычной суматохе и текучке, толку от этого распрекрасного требования - ноль. Не задокументировано, не учтено - значит нету. К инженерии требований это всё тоже относится.

Требование - это приписанное к части системы утверждение (assertion).

Контрольная точка - это достижение этого требования к какому-то моменту.

Если нет учёта частей системы, то и приписывания к ним утверждений нельзя сделать. Если нет контрольных точек, то выполнение требований гарантировать нельзя. Остальное всё потом: никакое моделирование бардака или переговоры по поводу бардака не помогут.

Что включает инженерия требований:

• Учет требований
• Проверка непротиворичивости требований

Инженер по требованиям

Кто должен делать требования?

1. Иногда между командой инженеров и заказчиком можно услышать следующий разговор со стороны инженеров: “вы предоставьте нам подробные требования, иначе мы и пальцем не пошевелим”. Должен разочаровать: это неверная позиция. Заказчик может представить только свои нужды, а не требования к системе. Если у заказчика есть инженеры (или заказ на разработку системы делает инженерная фирма), то есть шанс получить “требования стейкхолдера”. Но это ещё не требования к системе.

1. Разрабатывает требования обычно команда проекта, они не приходят извне проекта. Другое дело, что без активного участия стейкхолдеров (в том числе представителей организации заказчика) требования не подготовишь. Но в любом случае, ответственность за требования лежит на команде проекта, а не на заказчике. Заказчик же может, например, завизировать разработанные командой проекта требования — но и в этом случае, изготовленная система, которая не удовлетворит его нуждам (needs) по причине того, что требования были сформулированы командой проекта неправильно, может встретить серьёзные проблемы при приёмке/validation (хотя блестяще пройдёт проверку/verification — инженеры подтвердят сами себе, что изготовили ровно то, что планировали, хотя это не то, в чём нуждался клиент). За требования ответственен инженер потому что он должен сделать реверс-инжиниринг использующей системы: часто клиент на это не способен, хотя он обычно и весьма знающ об особенностях используемой системы, но эти знания могут быть совсем не такими, на которые мог бы расчитывать инженер.

Обязанности инженера по требованиям

Инженер по требованиям (вид системного инженера) занимается тем, что:

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

Качества инженера по требованиям

Инженер по требованиям должен быть:

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

Практики ЖЦ требований по ISO 15288:2015

6.4.2 Stakeholder needs and requirements definition process

• Подготовиться (идентифицировать стейкхолдеров, определить стратегию определения потребностей стейкхолдеров и требований, получить или купить обеспечивающую систему и сервисы)
• Определить потребности стейкхолдеров (определить контекст использования, идентифицировать потребности стейкхолдеров, приоритизировать и отобрать потребности, определить потребности стейкхолдеров и их обоснование)
• Разработать Концепцию функционирования (operational concept) и другие концепции жизненного цикла (определить набор сценариев, определить взаимодействия пользователей и системы)
• Преобразовать потребности стейхколдеров в требования стейкхолдеров (идентифицировать ограничения на инженерные решения, идентифицировать требования стейкхолдеров и все функции для требований качества, гармонизировать требования стейкхолдеров)
• Анализировать требования стейкхолдеров (анализировать полное множество требований стейкхолдеров, определить критические показатели результативности, которые позволят оценить технические достижения, получить обратную связь от стейкхолдеров – валидировать, устранить все проблемы и противоречия со стейкхолдерами)
• Управлять определением потребностей стейкхолдеров и требованиями (получить явное согласие на требования стейкхолдеров, поддерживать трассировку потребностей и требований, обеспечивать сведения по базисам)

6.4.3. System requirement definition process

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

Международные общества

• IREB (International Requirements Engineering Board)
• ReSG (Requirements Engineering Specialist Group, в British Computer Society)

Профессиональная сертификация

• CPRE

Журналы

• http://re-magazine.ireb.org

Стандарты

• IEC/IEEE/ISO 15288:2015 – задаёт инженерию требований в других дисциплинах (инженерии системной архитектуры, управления конфигурацией и т.д.)
• IEC/IEEE/ISO 29148:2011 – специализированный по требованиям, на базе ISO 15288
• SEBoK – стандарт, используемый в сертификации системных инженеров
• Стандарты машинного представления требований
  • SysML
  • AP233
  • RIF
  • ISO 29148
  • ITU Z.151 (URN=GRL+UCM) и другие из GORE (i*, BMM, ArchiMate, MBRD, Planguage): выражение оппозиции цели-средства (ends – means)
  • ISO 15926

Моделеориентированная инженерия требований

В инженерии предприятий (enterprise engineering) модели требований (к предприятию/к архитектуре предприятия) часто называют мотивационными моделями (motivation не только «движущая сила, побуждение», но и обоснование – reason, justification).

Моделеориентированность (как шаг к формальным требованиям) хороша для проведения проверок самих требований (хотя она не поможет найти пропущенное требование). Требования должны документироваться и затем использоваться для проведения испытаний (проверок и приёмок) как чеклисты.

Примеры языков для таких моделей требований

• GRL,
• подход i* (этот подход родоночальник и классика GORE),
• Motivational Extension в ArchiMate 2.0,
• Model-based requirement discovery от Яна Александера.

Программное обеспечение

• Modelica
• Julia

Другие практики с использованием моделеориентированных требований

• Test driven development – это когда разработка системы начинается с того, что требования разрабатываются сразу в виде тестов (исполняемых!). Увы, качество разработки по TDD получается примерно такое же, как и при любых других видах разработки – что не снижает популярности этого подхода. Требования как правило разрабатываются с помощью сценариев (use cases), в которых рассказывается, что делает система в ответ на последовательности действий (сценарии) с участием разных стейкхолдеров.
• Использование user story в формулировках по шаблону (Mike Cohn, 2008, Advantages of the “As a user, I want” user story template, blog post): Я как [стейкхолдер] хочу, чтобы система [формулировка требования], для того чтобы [хотелка-для-using-system].