Как писать требования естественным языком. Три подхода

Я — Юрий Избенко, консультант в компании GlobalLogic, работаю в медицинском домене более 10 лет (Quality Assurance). В данной статье хочу рассказать о трёх подходах к написанию требований с использованием естественного языка и отвечающих стандартизированным критериям качества, — подходах, предложенных в IREB, IEEE 29148 и EARS. Статья может быть полезной тем, кто работает с написанием, имплементацией и верификацией формализованных функциональных требований — архитекторам, бизнес-аналитикам, менеджерам проектов, разработчикам, тестировщикам.

Почему написана эта статья

При разработке ПО все команды в той или иной мере сталкиваются с инжинирингом требований (Requirements Engineering, RE) — выявлением (elicitation), написанием (documentation), валидацией/согласованием (validation & negotiation) и менеджментом (management) требований. В разных источниках перечисленные активности могут иметь немного другие названия или последовательности, но суть RE не меняется.

Мы с коллегами работаем на медицинских проектах, которые предполагают формальную верификацию, и работа с требованиями занимает значимую часть наших активностей. Каждое недостаточно хорошо сформулированное требование влечет за собой временные затраты на выяснение с клиентом того, о чем же именно говорится в требовании; неправильно понятое/реализованное/протестирование требование приведет к необходимости повторить все связанные с ним активности, возможно — к задержке выпуска продукта или к потерям для бизнеса, если ошибка не выявляется вовремя. В какой-то момент у меня назрела необходимость докопаться до первоисточников (а не апеллировать к гуглу) и систематизировать свои знания в этой области. Когда на одном из проектов мне пришлось писать SRS (Software Requirements Specification), оказалось, что просто знать критерии качества требований для написания такого документа недостаточно, поэтому знание подходов к написанию требований тоже стало актуальной задачей.

Целью статьи является сокращение времени коллег на поиск/чтение букварей по написанию требований и систематизация известных решений (не всем они могут показаться бесспорными). Постараюсь дать материал сжато и тезисно, но иногда теоретическая подводка будет необходима. Самые нетерпеливые могут сразу начинать с раздела 1. В статье будет много англоязычных терминов и примеров — английский является фактическим стандартом для компаний, работающих в аутсорсе; возможно, кому-то таким образом будет легче ориентироваться в терминологии (русскоязычные термины vs англоязычные, например).

Роль и место Requirements Engineering в System и Software Engineering

Международные стандарты ISO/IEC/IEEE 12207 Systems and software engineering — Software life cycle processes [1] и ISO/IEC/IEEE 15288 Systems and software engineering — System life cycle processes [2] определяют конечное множество процессов для управления жизненным циклом ПО и относят Requirements Engineering процессы к группе из 14 технических процессов, одной из четырех групп процессов жизненного цикла ПО (Technical Processes). В свою очередь, международный стандарт ISO/IEC TR 19759 Software Engineering Body of Knowledge (SWEBOK) [3] относит Requirements Engineering (Software requirements в стандарте) к одной из 15 областей знаний разработки ПО (далее для простоты наименования стандартов будем просто указывать название последнего института и номер стандарта).

Источники информации

В качестве отправной точки были выбраны следующие источники:

1. IREB, Certified Professional for Requirements Engineering, Foundation Level (сертифицировался, [4]);
2. IEEE 29148 Requirements Engineering [5];
3. EARS, Easy Approach to Requirements Syntax [6, 7];
4. (полностью осилить BABOK [8], как и пройти какие-либо IIBA сертификации для бизнес-аналитиков, руки не дошли — беглый просмотр ВАВОКа показал, что он описывает критерии качества требований, но не отвечает на вопрос каким образом написать требования, удовлетворяющие этим критериям).

Почему IREB, IEEE 29148, EARS

IREB (International Requirements Engineering Board) основан в Германии с целью поддержки единой, общепризнанной, международной схемы квалификации, направленной на разработку требований для профессионалов. Члены IREB — это международные эксперты в области разработки требований из университетов, экономики и образования. Прибыльная организация, проводит сертификацию как самостоятельно, так и под крылом iSQI (International Software Quality Institute). Материалы IREB часто имеют отсылки к IEEE 29148 как базовым знаниям. Основное отличие IREB от IEEE 29148 c точки зрения подаваемого материала, на мой взгляд, состоит в том, что если IEEE 29148 подает сухую выжимку знаний и отвечает на вопрос «Как?», то в IREB материал более развернут и помимо ответа на вопрос «Как?» отвечает на вопрос «Почему?».

ISO, IEC, IEEE (International Organization for Standardization, International Electrotechnical Commission, Institute of Electrical and Electronics Engineers) — неприбыльные организации, целью которых является стандартизация в области электротехники, электроники, связи, вычислительной техники, информатики и информационных технологий. Их совместные гармонизированные стандарты де-факто являются мировыми стандартами. Стандарт IEEE 29148 Requirements Engineering гармонизирован с IEEE 12207, IEEE 15288 и определяет, в частности, перечень процессов Requirements Engineering-а (Раздел 6), подход для написания хороших требований (5.2.4), характеристики индивидуальных требований (5.2.5) и множества требований (5.2.6), представляет итеративное и рекурсивное применение Requirements Engineering процессов на протяжении всего жизненного цикла (5.3), структуру SRS. С практической точки зрения IEEE 29148 вполне самодостаточный и полный источник в области инжиниринга требований; если не хотите изобретать велосипед в области Systems and Software Engineering — это ваш кейс.

EARS (Easy Approach to Requirements Syntax). Данный подход написания требований был разработан инженерами компании Rolls-Royce (Великобритания). Среди прочего, компания разрабатывает системы управления газотурбинных авиационных двигателей, которые характеризуются повышенной сложностью, надежностью, улучшенной отказоустойчивостью (т.н. safety critical, или mission critical системы). Очевидно, существующие подходы не удовлетворяли команду разработчиков и они решили разработать свой подход к написанию требований, который бы повысил точность описания требований и минимизировал такие проблемы естественного языка как неоднозначность, неясность, упущения.

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

В целом, написание требований осуществляется двумя основными способами — с использованием естественного языка, ЕЯ (user stories, требования) и с использованием концептуальных моделей (model based — Use Case Diagrams, Class Diagrams, Activity Diagrams, State Diagrams). Наиболее широкое распространение получил первый подход как наиболее гибкий — с помощью языка мы можем свободно выразить любую мысль, для этого не требуется специальная подготовка всех участников процесса; второй подход носит вспомогательный характер. Вместе с тем, использование неструктурированного ЕЯ при написании требований привносит следующие проблемы:

• Неоднозначность (ambiguity) — слово или фраза имеет два или более различных значений.
• Неясность (vagueness) — отсутствие точности, структуры и/или деталей.
• Сложность (complexity) — составные требования, содержащие сложные подпункты и/или несколько взаимосвязанных утверждений.
• Упущение (omission) — отсутствие требований, особенно требований по обработке нежелательного поведения.
• Дублирование (duplication) — повторение требований, определяющих одну и ту же потребность.
• Многословность (wordiness) — использование ненужного и излишнего количества слов.
• Неадекватная реализация (inappropriate implementation) — утверждения о том, как должна быть построена система, а не что она должна делать.
• Нетестопригодность (untestability) — требования, истинность или ложность которых невозможно доказать при реализации системы.

Соответственно, основными критериями качества требований являются (наш чек-лист):

• однозначность (unambiguous);
• непротиворечивость (consistency);
• полнота (сomplete);
• атомарность (singular);
• выполнимость (feasible);
• тестопригодность (verifiable).

В качестве тривиального примера проблем с написанием требований можно рассмотреть постановку задачи менеджером: Коллеги, напоминаю — сделайте плз то, о чем мы с вами говорили.

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

Для минимизации проблем, вносимых ЕЯ при документировании требований, и были разработаны нижеприведенные подходы.

1. IREB (International Requirements Engineering Board).

1.1. Эффекты естественного языка. В IREB говорят, что помимо субъективного восприятия информации, естественный язык (не важно какой — английский, немецкий, ...) обладает следующими трансформационными эффектами, способствующими потенциальной потере информации:

• Номинализация.
• Существительные без референтного индекса.
• Универсальные квантификаторы.
• Неполностью определенные условия.
• Неполностью определенные глаголы процесса.

Номинализация. Суть номинализации состоит в том, что какой-то процесс (даже длительный) может быть описан всего одним существительным, например input, booking. Эти существительные говорят нам о том, что такие процессы есть, но номинализация скрывает от нас как эти процессы происходят. Эти глаголы/процессы должны быть выявлены.

Пример: The system shall provide support of a water level sensor.

Возникающий вопрос — какие процессы мы подразумеваем под существительным support?

Существительные без референтного индекса. Как и глаголы процесса, существительные также могут иметь неполное описание, например the user, the data.

Пример: The data shall be displayed to the user.

Возникающие вопросы — какие именно данные, какой именно тип пользователя?

Универсальные квантификаторы. Определяют количество или частоту, группируют набор объектов и делают утверждение о поведении всего этого набора. Существует риск, что указанное поведение или свойство не применимо ко всем объектам, входящим в указанное множество. Идентифицируются такими триггерными словами, как never, always, every, all, some, nothing.

Пример: The system shall show all data sets in every submenu.

Возникающие вопросы — точно все датасеты? Точно в каждом подменю?

Неполностью определенные условия. Требования, содержащие условия, определяют поведение, которое должно произойти при выполнении условия. Часть, которая часто отсутствует — какое поведение должно произойти, если условие не выполняется. В сложных условных структурах таблицы решений являются хорошим инструментом для поиска неопределенных вариантов условий или действий. Триггерными словами являются if . . . then, in case, whether, depending on.

Пример: The restaurant system shall offer all beverages to a registered guest over the age of 20 years.

Возникающие вопросы — гостям младше 20 лет напитки не отпускаются? Напитки — алкогольные/безалкогольные для разных категорий гостей?

Неполностью определенные глаголы процесса. Некоторые глаголы процесса требуют более одного существительного, чтобы считаться полностью определенным. Например, глагол transmit требует как минимум трех дополнений, чтобы считаться полным: что передается, откуда передается и куда передается. Использование неполностью определенных глаголов процесса можно избежать или свести к минимуму, если формулировать требования в активном, а не в пассивном залоге

Пример (passive voice): To log a user in, the login data is entered.

Пример (active voice): The system shall allow the user to enter his username and password using the keyboard of the terminal.

1.2. Подход к написанию требований. Для снижения трансформационных эффектов, IREB предлагает использовать следующие 5 шагов при разработке требований, выделяя 3 типа требований:

• Шаг 1. Определить юридическое обязательство

Обязательное shall, рекомендуемое should, будущее требование will и желаемое may.

• Шаг 2. Ядро требования

Ядро каждого требования — это функциональность, которую оно определяет (например, print, save, calculate). Эта функциональность описывает процесс, который описывается исключительно с помощью глаголов.

• Шаг 3. Охарактеризовать деятельность системы

Для функциональных требований, деятельность системы может быть классифицирована как один из трех соответствующих типов требований:

• Автономная деятельность системы. Данный тип используется при построении требований, которые описывают действия системы, выполняющиеся без участия пользователя. Шаблон выглядит как:

The system shall/should/will/may <process verb>.

• Взаимодействие с пользователем. Данный тип используется для описания случаев, когда система предоставляет функциональность пользователю (например, с помощью интерфейса ввода), или система непосредственно взаимодействует с пользователем:

The system shall/should/will/may provide <whom?> with the ability to <process verb>.

• Требование интерфейса. Используется для описания выполнения системой процессов, зависящих от третьей стороны (например, другой системы); система пассивна и ожидает внешнего события:

The system shall/should/will/may be able to <process verb>..

• Шаг 4. Добавить объекты (завершить глаголы процесса)

Определяются потенциально отсутствующие объекты и дополнения объектов (наречия). Например, шаблон требований для глагола процесса print дополняется информацией о том, что печатается и где печатается.

• Шаг 5. Определить логические и временные ограничения (добавить условия)

Логическое if или временное ограничение as soon as. Следует избегать when (непонятно, это логическое или временное ограничение).

Структурно подход выглядит следующим образом:

2. IEEE 29148 Requirements Engineering.

2.1. Руководство по написанию хорошо сформулированных требований. При написании требований стандарт рекомендует использовать заранее согласованные термины и правила при написании требований для минимизации негативных эффектов ЕЯ:

• Использование shall для обязательных требований, will для заявлений о чем-то в будущем или декларации намерений (рекомендуется избегать), should для желательных необязательных требований, may для предположений, избегание must.
• Использование позитивных утверждений и избегание негативных shall not.
• Использование активного залога, избегание пассивного вроде shall be able to select.
• В требовании должно быть указано, что необходимо сделать, а не как.
• Избежание использования неограниченных или неоднозначных типов терминов.
  
  • превосходных степеней (таких как best, most);
  • субъективной лексики (user friendly, easy to use, cost effective);
  • неопределенных местоимений (таких как it, this, that);
  • неоднозначных наречий и прилагательных (таких как almost always, significant, minimal);
  • неограниченных, непроверяемых терминов (такие как provide support, but not limited to, as a minimum);
  • сравнительных фраз (такие как better than, higher quality);
  • лазеек (таких как if possible, as appropriate, as applicable);
  • негативных утверждений (таких как утверждений о том, чего система не будет предоставлять);
  • неполных ссылок (отсутствии ссылки с датой и номером версии).

2.2. Подход к документированию требований. Выделяется три типа требований:

Таблица 1. IEEE 29148 шаблоны написания требований

Пример для первого типа требований: The Invoice System <Subject> shall display pending customer invoices <Action> in ascending order <Value> in which invoices are to be paid.

Пример для второго типа требований: When signal x is received <Condition>, the system <Subject> shall set <Action>the signal x received bit <Object>within 2 seconds <Constraint>.

Пример для третьего типа требований: At sea state 1 <Condition>, the Radar System shall detect targets at ranges out to <Action or Constraint> 100 nautical miles <Value>.

Не могу сказать, что согласен с приведенными типами 1 и 3 — в обоих шаблонах тег <Object> отсутствует (поглощен тегами <Action> и <Action or Constraint> соответственно), в типе 3 пропущен тег <Subject>.

3. EARS (Easy Approach to Requirements Syntax).

3.1. Подход. Для устранения или минимизации основных проблем, привносимых в требования естественным языком, авторы подхода предлагают использовать следующий обобщенный подход (порядок следования элементов важен):

<optional preconditions> <optional trigger> the <system name> shall <system response>

Данный подход при написании требования стимулирует учитывать:

• preconditions — условия, при которых требование возникает (опционально);
• trigger — событие, делающее требование актуальным, при сбывшемся условии (опционально);
• system response — требуемая реакция системы тогда и только тогда, когда предварительные условия и триггер истинны.

Авторы выделяют 5 типов требований, с помощью которых можно описать их систему: Ubiquitous, Event-driven, Unwanted behaviors, State-driven, Optional features, под каждый из которых адаптируется обобщенный подход.

Ubiquitous (повсеместные) требования. Не имеют предварительных условий или триггера. Не вызывается каким-либо событием и не является реакцией на определенное состояние системы, они являются активными всегда. Шаблон для такого типа требований выглядит следующим образом:

The <system name> shall <system response>

Пример: The control system shall prevent engine overspeed.

Это поведение системы, которое должно быть активным в любое время; следовательно, это повсеместное требование.

Event-driven требования. Такой вид требований используется только тогда, когда наступает событие, являющееся триггером для дальнейшей реакции системы на этот триггер. Для этого типа требований используется ключевое слово When. Шаблон для такого типа требований:

When <optional preconditions> <trigger> the <system name> shall <system response>

Пример: When continuous ignition is commanded by the aircraft, the control system shall switch on continuous ignition.

Реакция системы «switch on...» наступает тогда и только тогда, когда происходит инициирующее событие «commanded».

Unwanted behaviors требования. «Нежелательное поведение» — это общий термин, используемый для нежелательных ситуаций: сбоев, нарушений, отклонений от желаемого поведения пользователя, неожиданного поведения взаимодействующих систем. По мнению авторов нежелательное поведение является основным источником упущений в ранних требованиях, что приводит к необходимости дорогостоящей доработки. Требования к нежелательному поведению обозначаются с помощью ключевых слов If и Then:

If <optional preconditions> <trigger>, Then the <system name> shall <system response>

Пример: If the computed airspeed fault flag is set, then the control system shall use modelled airspeed.

В этом примере нежелательное поведение «computed air speed fault flag is set» инициирует реакцию системы «system shall use modelled airspeed.

Использование структуры If — Then позволяет смягчить влияние нежелательного события, или предотвратить вхождение системы в нежелаемое состояние.

State-driven требования. Данный вид требований актуален, когда система находится в определённом состоянии, и использует ключевое слово While (или During):

While <in specific state> the <system name> shall <system response>

Пример: While the aircraft is in-flight, the control system shall maintain engine fuel flow above XXlbs/sec.

Здесь реакция системы «maintain engine fuel flow...» необходима всякий раз, пока система находится в состоянии «in-flight».

Optional features. Данный вид требований используется только в системах, включающих частичный функционал, и использует ключевое слово Where:

Where <feature is included> the <system name> shall <system response>

Пример: Where the control system includes an overspeed protection function, the control system shall test the availability of the overspeed protection function prior to aircraft dispatch.

Здесь функциональность «...shall test the availability of the overspeed protection» имеет смысл (и следовательно требуется) только в том случае, если у системы данная функциональная возможность определена (overspeed protection function).

3.2. Результаты. Основываясь на применении приведенного подхода к некоторому набору требований к существующей системе, авторы (с некоторыми допущениями и ограничениями) утверждают, что предложенный подход позволил избавиться в требованиях от следующих пяти проблем из восьми: сложности (complexity), упущений (omission), дублирования (duplication), неадекватной реализации (inappropriate implementation), нетестопригодности (untestability), и значительно снизить, но не устранить, неоднозначность (ambiguity), неясность (vagueness), многословность (wordiness).

Таблица 2. EARS шаблоны написания требований

Выводы

С точки зрения практической применимости приведенных подходов я выделил для себя следующие тезисы:

• IREB, Foundation level — хорошая точка входа в Requirements Engineering.
• Знание трансформационных эффектов языка, приведенных IREB, позволяет более полно описать поведение системы — выявить скрытые процессы (номинализация), полностью определить глаголы этих процессов (избежание пассивного залога) и условия, при которых они происходят, полностью описать существительные (существительные без референтного индекса), избежать обобщений (универсальные квантификаторы).
• IEEE 29148 дает хороший список типов терминов, вносящих неопределенность в требования
• Для большинства систем наиболее оптимальными подходами для написания требований будут подходы, представленные IREB и IEEE 29148.
• Для Safety Critical и Mission Critical систем наиболее подходящим подходом будет EARS подход как подход, позволяющий наиболее полно описать требованиями сложные системы с большим количеством внутренних состояний и переходов.
• В описанных подходах есть несущественные противоречия (например, IREB рекомендует избегать использования условия when, в то время как IEEE 29148 и EARS используют). Для избежания этих противоречий есть смысл заранее договориться с клиентом / командой об используемых подходах написания требований и какой смысл мы вкладываем в ту или иную терминологию (свой глоссарий может быть актуален).

Отдельное спасибо старшему (по уровню зрелости) коллеге Анатолию Сахно, ознакомившего меня с EARS, вычитавшего эту статью и давшего ценные комменты.

Литература

[1] ISO/IEC/IEEE 12207 Systems and software engineering — Software life cycle processes
[2] ISO/IEC/IEEE 15288 Systems and software engineering — System life cycle processes
[3] ISO/IEC TR 19759 Software Engineering Body of Knowledge
[4] Klaus Pohl, Chris Rupp. Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam
[5] ISO/IEC/IEEE 29148 Systems and software engineering — Life cycle processes — Requirements Engineering
[6] EARS (Easy Approach to Requirements Syntax), Alistair Mavin et al, 17th IEEE International Requirements Engineering Conference (RE 09)
[7] Big EARS: The Return of Easy Approach to Requirements Syntax, Alistair Mavin et al, 18th IEEE International Requirements Engineering Conference (RE 10)
[8] BABOK. A Guide to the Business Analysis Body of Knowledge, v.3
[9] IEEE 24765 System and Software Engineering — Vocabulary