Категория:Требования

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

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

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

Требования к продукту

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

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

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

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

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

Требование к требованиям стейкхолдеров: их понятность самим стейкхолдерам. Стейкхолдеры нуждаются в требованиях, которые сфокусированы их нуждами.

Требования к системе

Требования к системе (system requirements) — требования, достаточные для разработки системы, которые формулируются архитекторами, проектировщиками и аналитиками на основе анализа требований к продукту и описывают:

• основные роли в системе,
• сценарии использования системы,
• информационные модели,
• модели классов, поведения, развертывания,
• прочие алгоритмы.

Их разрабатывает инженер по требованиям в ходе так называемой “аналитической” работы (хотя в этой работе кроме анализа требований стейкхолдеров и присутствует синтез системных требований).

К требованиям к системе предъявляют множество самых разных требований:

• непротиворечивость,
• полнота,
• проверяемость
• и т.д.

Требования по ГОСТ 34

ГОСТ 34.602 устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы». Техническое задание определяет требования и порядок создания системы, в соответствии с которым проводится её разработка и приемка при вводе в действие. Техническое задание содержит следующие разделы:

1. общие сведения;
2. назначение и цели создания (развития) системы;
3. характеристика объектов автоматизации;
4. требования к системе;
5. состав и содержание работ по созданию системы;
6. порядок контроля и приемки системы;
7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8. требования к документированию;
9. источники разработки.

Модальность

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

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

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

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

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

1. Требования назначения (operational requirements) - относятся к назначению и целям создания системы. Совокупность этих требований должна описывать конечное состояние мира после того, как система будет развернута и начнет использоваться. Иногда их называют "требования к возможностям системы", "необходимые возможности".

   - требования, выведенные из портебностей стейкхолдеров после анализа потребностей.

2. Функциональные требования (functional requirements) - требования, определяющие функцию, которую должна быть способна выполнить система или элемент системы (ISO 24765)

   - требования, выведенные из сценариев использования. Самые распространённые практики инженерии требований — это выявление функций (поведения) системы из каких-то сценариев взаимодействия (user stories, use cases).

3. Требования к показателям функционирования (performance requirements) - описывают насколько хорошо система должна выполнять предъявленные к ней требования (минимальные числовые пороговые значения).
4. Требования к реализации (requirements) - требуемые характеристики и атрибуты физического воплощения системы и ограничения на ее конструкцию, внешний вид, общие свойства, вес, мощность, материал, ограничения на внешние интерфейсы.
5. Нефункциональные, “требования качества” (например, требованиям надёжности, ремонтопригодности, доступности, безопасности и т.д., так называемые “-ости”, по- английски это будут “ilities” — reliability, repairability, availability, safety, etc.).

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

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

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

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

Стандарты представления требований

(см. подробнее)

• SysML
• AP 233
• RIF
• ISO 29148
• ITU Z.151 (URN=GRL+UCM)
• другие языки из подхода GORE: выражение оппозиции цели-средства (ends – means)
  • i*
  • RFLP
  • ArchiMate
  • MBRD
  • OMG BMM
  • Planguage
• ISO 15926

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

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

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 определяет следующие состояния для альфы "Требования" и контрольные вопросы для проверки каждого состояния:

№	Состояние	State	Описание состояния	Контрольные вопросы
1	Замыслены	Conceived	Согласована потребность в новой системе.	❑ Начальное множество стейкхолдеров согласно, что система должна быть произведена. ❑ Стейкхолдеры, которые будут использовать новую систему, определены. ❑ Стейкхолдеры, которые профинансируют начальную работу по созданию новой системы, определены. ❑ Есть ясная возможность, которую будет адресовывать новая система.
2	Ограничены	Bounded	Назначение и тема новой системы ясны.	❑ Стейкхолдеры, вовлечённые в разработку новой системы определены. ❑ Стейкхолдеры согласны с назначениемновой системы. ❑ Ясно, что будет считаться успехом для новой системы. ❑ Стейкхолдеры имеют одинаковое понимание пределов предлагаемого решения. ❑ Технология описания требований согласована. ❑ Механизмы управления требованиями наличествуют. ❑ Приоретизационная схема ясна. ❑ Ограничения определены и приняты во внимание.Допущения ясно сформулированы.
3	Непротиворечивы	Coherent	Требования обеспечивают непротиворечивое описание существенных характеристик новой системы.	❑ Требования документированы и доступны команде и стейкхолдерам. ❑ Происхождение требований ясно. ❑ Обоснование требований ясно. ❑ Противоречивые требования идентифицированы и ими занимаются. ❑ Требования сообщают существенные характеристики поставляемой системы. ❑ Наиболее важные сценарии использования системы могут быть объяснены. ❑ Приоритетность требований ясна. ❑ Влияние реализации требований понимается. ❑ Команда понимает, что должно быть обеспечено и соглашается обеспечить это.
4	Приемлемы	Acceptable	Требования описывают систему, которая будет приемлема для стейкхолдеров.	❑ Стейкхолдеры принимают, что требования описывают приемлемое решение. ❑ Скорость изменений к согласованным требованиям относительно низка и под контролем. ❑ Польза, обеспечиваемая реализацией требований, ясна. ❑ Части возможности, удовлетворяемые требованиями, ясны. ❑ Требования тестируемы.
	Адресованы	Addressed	Достаточное количество требований было адресовано, чтобы удовлетворить потребность в новой системе способом, приемлемым для стейкхолдеров.	❑ Достаточное количество требований адресовано, чтобы результирующая система была приемлема для стейкхолдеров. ❑ Стейкхолдеры принимают, что требования аккуратно отражают, что система должна и не должна делать. ❑ Набор реализованных единиц требований обеспечивает ясную пользу для стейкхолдеров. ❑ Система, реализующая требования, принимается стейкхолдерами, как заслуживающая эксплуатации.
5	Удовлетворены	Fulfilled	Требования, которые были адресованы, полностью удовлетворяют потребность в новой системе.	❑ Стейкхолдеры принимают требования, как аккуратно документирующие, что стейкхолдеры требуют для полного удовлетворения потребности в новой системе. ❑ Нет никаких невыполненных единиц требований, которые не дают принять систему как полностью удовлетворяющую требованиям. ❑ Система, принята стейкхолдерами как полностью удовлетворяющая требованиям.