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

Версия 23:32, 25 ноября 2015

Термин “требования” имеет два разных смысла:

• Определение системы как “чёрного ящика” — что требуется от целевой системы с точки зрения её стейкхолдеров (stakeholder requirements) и использующей надсистемы (system requirements). Обычно это спецификация (т.е. точное формулирование) способности (capability) или условия (condition), которое должно или может быть удовлетворено (функция, которую нужно будет выполнить, или характеристика, которую нужно достигнуть и т.д.).
• Любые определения системы (”чёрного ящика”, “прозрачного ящика”, на любых стадиях жизненного цикла), в которых присутствует деонтическая модальность (модальность долженствования).

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

Модальность

Чтобы понять природу требований, нужно разобраться с логическими модальностями высказываний о системе (модальная логика):

• нейтральные высказывания о мире, суть которых непонятна без указания модальности. Например, "длина дана как 16".
• алетическая (alethic) модальность, относящаяся к возможности существования: пока воплощения системы ещё нет, возможны варианты определений системы для разных возможных вариантов будущего воплощения системы.
• деонтическая (deontic) модальность, относящаяся к обязыванию и дозволению. Например, "длина должна быть 16". Собственно, это и есть главная модальность “требований”, требования — это то, что должно быть, рекомендуется быть, разрешается быть, обязательно или необязательно и т.д.
• темпоральная (temporal) модальность, связанная со временем. Например, "длина была 16 три года назад".

доксическая (doxastic) модальность, связанная с верой. "Я верю, что длина дана как 16". Доксическая модальность важна для квалификации (удостоверения того, что требования выполнены — вера в то, что система соответствует её определению).

Требования довольно трудно формализовать именно потому, что нужно разбираться с их модальностями.

Требования связаны с инженерными обоснованиями: они переформулируются как "декларации" (claim) разработчиков о соответствии — т.е. "я верю, что длина равна 16", а затем это высказывание доказывается по логическим правилам рациональной аргументации (помним, что логика — это дисциплина, занимающаяся правильностью рассуждений). Эти доказательства проводятся “как в суде” — и для этого даже заводится “дело” (assurance case, как раз от “судебного дела” — с вариантами dependability case, safety case, security case, requirement case, architectural quality case). Обзор по инженерным обоснованиям приведён тут.

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

1. Функциональные - требования, выведенные из сценариев использования. Самые распространённые практики инженерии требований — это выявление функций (поведения) системы из каких-то сценариев взаимодействия (user stories, use cases: там множество вариантов). ,
2. Нефункциональные, “требования качества” (например, требованиям надёжности, ремонтопригодности, доступности, безопасности и т.д., так называемые “-ости”, по- английски это будут “ilities” — reliability, repairability, availability, safety, etc.).

Но есть замечание Donald Firesmith, что “не бывает нефункциональных требований” — ибо все эти "требования качества" это абсолютно функциональные требования, характеризующие функции системы с точки зрения каких-то стейкхолдеров, обычно не рассматривающихся в сценариях “пользования”.

Главный источник ошибок в проекте — это неведение относительно наличия каких-то требований. Впрочем, классификация может помочь, если вы зададите себе вопрос: какие виды требований вы ещё не рассматривали для вашего проекта?

Свойства качества (внешние)

Подробнее про требования защитоспособности (выделенные на рисунке выше) можно посмотреть в презентации Дональда Файерсмита — и там же можно посмотреть на презентацию по целеориентированной инженерии требований Яна Александера.

Требования стейкхолдеров и требования к системе

Требования стейкхолдеров — это описания “черного ящика”, которые создаются для отдельных стейкхолдеров. Конечно, требования разных стейкхолдеров будут противоречить друг другу. Обычно от инженера по требованиям требуется документировать (в тексте или какой-то модели) требования стейкхолдеров, а затем завизировать эти требования у них — чтобы подтвердить правильность понимания. К требованиям стейкхолдерам главное — их понятность самим стейкхолдерам. Стейкхолдеры нуждаются в требованиях, которые сфокусированы их нуждами.

Каждый клиент мнит себя инженером (а иногда не мнит, а является ещё и инженером, более знающим, чем инженеры команды проекта). Такой клиент не только будет формулировать требования стейкхолдера, а также требования к системе, но обязательно попытается сформулировать конкретные инженерные решения “прозрачного ящика” (например, из каких частей должна составлять система, какое в ней должно быть использовано оборудование). Формально высказывания о “прозрачном ящике” не называются требованиями, поэтому некоторые авторы предлагают называть их “ограничениями” (свободы творчества инженерной команды). Неплохо бы понимать в каждом проекте, что является требованиями, а что является ограничениями. Прежде всего вы должны удовлетворить требования. И если придуманное вами инженерное решение лучше того, которое требует клиент в своих ограничениях, попытаться убедить клиента снять эти ограничения. Но нужно понимать, что иногда эти ограничения отражают какой-то опыт клиента, неизвестный команде, или они появляются из неинженерных (политических, финансовых, логистических и т.д.) соображений. Поэтому по поводу ограничений нужно каждый раз понимать, почему они были прописаны, почему клиент без них не может обойтись (см. GORE).

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

Требования к системе (system requirements) — требования, достаточные для разработки системы. Их разрабатывает инженер по требованиям в ходе так называемой “аналитической” работы (хотя в этой работе кроме анализа требований стейкхолдер и присутствует синтез системных требований). К требованиям к системе предъявляют множество самых разных требований: непротиворечивости, полноты, проверяемости и т.д. Разработать хорошие требования к системе очень и очень непросто.

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

Жизненный цикл требований стейкхолдеров

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

Жизненный цикл требований к системе

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

Рабочие продукты требований

Рабочие продукты требований могут быть самые разные — и чаще всего они не называются “требования”. Так, требования можно обнаружить в:

• разделе “технические требования” технических заданий (хотя “техническое задание” чаще всего подробно перечисляет работы — “задание на работы”, а не требования, но всё-таки какое-то описание целевой системы как “чёрного ящика” это описание содержит);
• документе “Опросный лист” (который посылается, чтобы опросить потенциальных поставщиков инженерных решений и содержит как раз основные требования к поставляемой системе);
• посылаемом в ответ на “Опросный лист” документе “Технико-коммерческие предложения”;
• Различных стандартах, некоторые из которых называются “технические условия” (т.е. даже в названиях они не содержат слова “стандарт” или “требования”).

Важно понимать, что:

1. требования системной инженерии — определения “чёрного ящика”, которые могут даже не содержать слово “требования” в своих рабочих продуктах и не содержать слов, обозначающих деонтическую модальность — быть без слов “должно”, “возможно”, “обязательно” и т.д.
2. требования совсем необязательно являются бумажными документами-текстами. Они вполне могут храниться в какой-то БД (в рамках какой-то “информационной системы управления требованиями” — DOORS, IRqA и т.д.) в виде отдельных пронумерованных текстовых описаний или в виде компьютерной модели, численной или логической.

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

Нужно различать:

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

Требования к требованиям по ISO 29148

Требования к группе требований:

1. Полнота (complete)
2. Согласованность с другими (consistent)
3. Выполнимость (affordable, проходимы по бюджетам и срокам)
4. Ограниченность (bounded)

Требования к одному требованию:

1. Необходимость (necessary)
2. Абстрактность (abstract)
3. Недвусмысленность (unambiguous)
4. Согласованность с другими (consistent)
5. Полнота (complete)
6. Лаконичность (concise)
7. Достижимость (feasible)
8. Трассируемость (traceable)
9. Проверяемость (verifiable)

Состояния требований по OMG Essence

1. Начаты (concieve) – согласована потребность в системе.
2. Ограничены (bounded) – назначение и тема новой системы ясны.
3. Непротиворечивы (coherent) – требования обесечивают непротиворечивое описание существенных характеристик новой системы.
4. Приемлемы (acceptable) – требования описывают систему, которая будет принята стейкхолдерами.
5. Отвечены (addressed) – достаточное количество требований было отвечено, чтобы удовлетворить потребность в новой системе способом, приемлемым для стейкхолдеров.
6. Удовлетворены (fulfilled) – требования, которые были адресованы, полностью удовлетворяют потребность в новой системе. Проблема: все требования проходят по ЖЦ асинхронно, и даже критерии одной стадии выполняются не одновременно. Concurrent requirements engineering – параллельная инженерия требований.