Примеры формулировок требований по правилам руководства по написанию требований от INCOSE

Данная статья написана в продолжении статьи "Итоговая сводка по руководству по написанию требований INCOSE (Июнь 2023)". Статья содержит примеры формулировок требований как правильных (т.е. с точки зрения соответствия правилам руководства), так и неправильных (т.е. с точки зрения нарушения правил руководства).

Примеры взяты из реальных проектных документов, из руководства 2022 года, из книги К. Вигерса, часть примеров являются произвольными. Примеры приведены не только в отношении ИТ-систем.

Матрица свойств и правил

Ниже представлена матрица свойств качественных требований/наборов требований и правил, которые придают требованиям/наборам требований эти свойства.

Точность

R1 - Структурированные предложения

Формулировка потребности или требования должна соответствовать определенному согласованному шаблону.

В соответствии с ISO/IEC/IEEE 29148:2018 формулировка может иметь следующие варианты структуры:

[Условие] [Субъект] [Действие] [Объект] [Ограничение/Действие].

ПРИМЕР: В состоянии моря 1 [Условие], Радиолокационная система должна определить цели в радиусе  [Действие или Ограничение] 100 морских миль [Значение].

В самом простом варианте структура формулировки может иметь вид:

[Субъект] [Действие] [Объект].

Комментарий: В столбце "Неправильно" приведен фрагмент из набора требований к системе управления бюджетом:

• Все три формулировки написаны в не единообразном ключе. Первая формулировка написана по структуре, вторая формулировка без слова "должна", в настоящем времени ("загружает"), третья формулировка - в пассивной залоге.

• Первая и третья формулировка содержат 2 требования в одном (после запятой идет второе требование).

• По второй формулировке непонятно из какой внешней системы должны быть загружены заявки.

• Такие информационные объекты как "Заявки на доходы и расходы", "Фактические данные о доходах и расходах" должны быть определены в глоссарии и словаре данных.

• На отчет об исполнении заявок на доходы и расходы должна быть отдельная спецификация, например, в приложении к ТЗ.

В одном из ТЗ, написанных в прошлом проекте, нашла следующие формулировки требований:

• В Системе должно быть обеспечено ведение показателей по инвестиционной деятельности ...

• В Системе будет реализована возможность создания новых/редактирование существующих отчётов.

• Необходима возможность выгрузки отчетов и форм в форматах XLSX.

• Необходимо предусмотреть возможность гибкой настройки расчёта КПЭ ...

• Должна быть возможность настройки уведомлений бизнес-администратором системы ...

В рамках одного документа все выше перечисленные требования сформулированы не единообразно, имеют разную структуру.

R2 - Активный залог

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

R3 - Соответствующие уровню подлежащее и сказуемое

Подлежащее и сказуемое в формулировке потребности/требования должны соответствовать уровню, к которому применимо потребность/требование.

Уровни:

1. Уровень бизнес-управления. Требования на этом уровне формулируются <Компания/бизнес-подразделение> должна/должно ...

2. Уровень бизнес-операций (операционной деятельности). Требования на этом уровне формулируются <Заинтересованная сторона> должна ...

3. Уровень системы. Требования на этом уровне формулируются <Система> должна ...

4. Уровень подсистемы, элемента. Требования на этом уровне формулируются <Подсистема> должна ...

Неправильно на уровне системы формулировать требование как "Пользователь должен ..."
На уровне системы следует предъявлять требования к системе, а не к ее пользователю или оператору. Рекомендуется преобразовать потребность пользователя в требование к системе: «Что должна делать система, чтобы удовлетворить потребность пользователя?»
Ответом на этот вопрос будет формулировка "Система должна...".

R4 - Определенные термины

Необходимо определить все термины, используемые в описаниях потребностей и требований, в соответствующем глоссарии и/или словаре данных.

Неправильно: Система должна отображать текущее время.

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

R5 - Определенные артикли

Данное правило применимо для английского языка.

Следует использовать определенный артикль “the”, а не неопределенный “a”.

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

R6 - Единицы измерения

Каждое числовое значение следует сопровождать единицей измерения.

Комментарий: Из формулировки непонятно в каких единицах Цельсия или Фаренгейта, нужно уточнить.

R7 - Неточные термины

Следует избегать наречий: несколько; любой; допустимо; сколько-нибудь; много; большое количество; мало; почти всегда; очень близко к; приблизительно; около; близко к; почти.

Следует избегать прилагательных: дополнительный; актуальный; обыденный; общий; типовой; важный; гибкий; расширяемый; типичный; достаточный; адекватный; пригодный; эффективный; эффектный; качественный; разумный; общепринятый.

Пример из книги К. Вигерса:

Комментарий: Не понятно, что означает слово "легко". Это очень субъективная категория, что легко для одного человека, может быть трудно для другого.

В ТЗ, написанных в прошлых проектах, нашла требования, нарушающие это правило:

• Система должна обеспечивать гибкий механизм настроек прав доступа к формам и элементам справочников.

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

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

R8 - Снятие ответственности

Не использовать слова, размывающие ответственность: насколько это возможно; как можно меньше; где возможно; как можно больше; если это необходимо; при необходимости; по мере необходимости; сообразно обстоятельствам; как требуется; в рамках целесообразного; если это осуществимо.

Пример из книги К. Вигерса:

Комментарий: Что означает «если возможно»? Значит ли это «технически осуществимо» (вопрос для разработчика) или «когда доступен основной список счетов»? Если вы не уверены, можно ли реализовать функцию, сделайте пометку «TBD» (Требует доработки), чтобы указать, что эта проблема еще не решена. После проверки одно из двух будет ликвидировано — либо пометка «TBD», либо требование. В требовании не указано, что произойдет, если проверка пройдет успешно или окончится неудачей. Избегайте неточных слов вроде «следовало бы».

В ТЗ, написанном в прошлом проекте, нашла требование, нарушающее это правило:

• Должна обеспечиваться возможность создания резервных копий настроек прикладного ПО и информации, обрабатываемой в Системе, а также возможность восстановления из данных резервных копий (при необходимости).

В данной формулировке:

1. Использован пассивный залог вместо активного (нарушение правила R2).

2. В данном требовании содержится 2 требования: создание резервных копий и восстановление из них (нарушение правила R1, R11).

3. Из формулировки неясно, кто должен определить значение «необходимого». Требование было бы яснее без позволяющего избежать ответственности выражения, т.е. убрать это из формулировки.

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

R9 - Открытые формулировки

В формулировках следует избегать: «включая, но не ограничиваясь», «и так далее», «и тому подобное».

В ТЗ, написанном в прошлом проекте, нашла требования, нарушающие это правило:

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

• При формировании в Системе отчетов предусмотреть обязательный параметр с датой отчета в формате: «январь-март по оперативным данным», «январь-март по бухгалтерским данным» и т.д.

• Система должна загружать файлы: заключенные договоры, техническое задание, ТКП, расчет стоимости и т.д.

Краткость

R10 - Лишние глаголы в неопределенной форме

Следует избегать лишних глаголов в неопределенной форме, идущих подряд.

Комментарий: Перечисление друг за другом глаголов в неопределенной форме усложняет формулировку требования.

R11 - Отдельные предложения

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

Комментарий: Сказуемое "должна генерировать" разделено с дополнением "веб-страницы" разделено обстоятельством времени "за 4 сек ...". Не допускается разделять сказуемое и дополнение, это усложняет понимание прочитанного. Для следования этому правилу нужно соблюдать структуру требования (см. правило R1).

R12, R13, R14 - Не нуждаются в примерах.

Однозначность

R15 - Логические операторы

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

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

Например, договариваемся о следующем:

• Использовать квадратные скобки для указания условий.

• Использовать следующие операторы: И, ИЛИ, Искл. ИЛИ.

• Примеры использования: [X И Y]”, “[X ИЛИ Y]”, [X Искл. ИЛИ Y]”, “НЕ [X ИЛИ Y]”.

R16 - Избегать частицы НЕ

В формулировке требования следует избегать частицы «Не».

Пример из книги К. Вигерса:

R17 - Знак косой черты

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

Пример из книги К. Вигерса:

Комментарий: Это предложение можно истолковать несколькими способами:

• «отдел доставки/исполнения» — это название подразделения;

• доставка и исполнение являются синонимами;

• в некоторых проектах упомянутое подразделение называется отделом доставки, а в других — отделом исполнения;

• массовый выпуск продукта может выполнять отдел доставки или отдел исполнения, так что косая черта означает «или»;

• массовый выпуск продукта отдел доставки или отдел исполнения выполняют совместно, так что косая черта означает «и».

Простота

R18 - Одна мысль - Одно предложение

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

Комментарий: Данное предложение является сложносочиненным: 1. Должно обеспечиваться создание резервных копий, 2. Должно обеспечиваться восстановление из резервных копий. Это два равноправных предложения в одном, соединенных союзом "а также". Для следования этому правилу нужно соблюдать структуру требования (см. правило R1).

R19 - Союзы

В формулировках следует избегать союзов, наречий: «и», «или», «затем», «если», «но», «также», «однако», «пока», «с другой стороны», «в противном случае». Наличие этих союзов - это характерный признак наличия нескольких требований в одной формулировке.

Комментарий: После запятой и наречия "затем" следует второе требование. Нужно разделить на два отдельных требования.

Пример из книги К. Вигерса:

Неправильно: Кредитная карточка покупателя должна считаться действительной для платежей до тех пор, пока не истечет ее срок действия.

Отсутствие информации о том, что происходит, когда выполняется условие «пока не», — обычная причина наличия недостающих требований.

Правильно: Разделите это положение на два — для двух условий: когда кредитная карточка действительна и когда срок ее действия истек:

1. Если кредитная карточка покупателя действительна, система должна
   выполнить платеж по этой карточке.

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

R20 - Формулировка с обоснованиями

Следует избегать фраз, которые указывают на “цель“, “намерение” или “обоснования” потребности или требования. Включение обоснования в формулировку - это избыточно, так как есть специальный атрибут А1 "Обоснование".

Неправильно: Система должна формировать отчет "Название отчета", так как организация должна предоставлять его в ФОИВ.

Комментарий: Обоснование следует записать в соответствующий атрибут А1 "Обоснование".

R21 - Круглые скобки

Следует избегать круглых скобок, так как часто там указывают незначащий, лишний текст.

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

В ТЗ, написанном в прошлом проекте, нашла требования, в которых использовались круглые скобки:

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

• Система должна обеспечивать формирование предметно-ориентированных наборов данных (витрин данных) применительно к тому или иному типу сценария.

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

Во всех трех выше перечисленных формулировках в скобках указано синонимичное слово. Следует избавиться от синонимов и определить термин в глоссарии и использовать именно его по всему тексту документа.

R22 - Перечисление

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

Комментарий: "... управлять функциями, связанными с температурой" - это фраза, которая обобщает некоторую совокупность функций. Следует перечислить эти функции явно, разделить на отдельные требования.

R23 - Дополнение диаграммами, моделями

Если в требовании необходимо описать сложное поведение, следует ссылаться на диаграмму или модель.

Пример: Система должна обеспечивать определенную последовательность согласования заявки (см. Приложение А, рис. А1).

Полнота

R24 - Местоимения

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

R25 - Заголовки

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

Пример заголовка: «Требования к аварийному сигналу тревоги».

Неправильно: Эта система должна звучать не более 20 минут.

Правильно: Система должна подавать аварийный сигнал тревоги не более 20 минут.

Реалистичность

R26 - Абсолютные значения

Следует избегать использования недостижимых абсолютных значений, таких как 100% надежность, 100% доступность, все, каждый, всегда, никогда и т.д.

Условия

R27 - Явные условия

Если одно условие распространяется на несколько требований, то следует писать данные требования отдельно друг от друга, в формулировку каждого из требований включить это условие.

Комментарий: Требования сгруппированы вокруг одного условия и не самодостаточны. Требования должны быть самодостаточными и атомарными, каждому из требований присваивается уникальный идентификатор (атрибут А15 "Уникальный идентификатор").

R28 - Множественные условия

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

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

Уникальность

R29 - Классификация

Следует классифицировать потребности и требования в соответствии с аспектами проблемы или системы, к которым они относятся.

Примеры классов:

• По уровню: бизнес-требования, пользовательские требования (требования заинтересованных лиц, требования к системе.

• По функциям;

• Атрибуты качества (качество функционирования)

• Физические характеристики.

• Требования к внешним интерфейсам.

• и пр.

R30 - Уникальность

Требование должно быть уникальным, в наборе требований не должно быть дублей.

Например, в одном наборе требований 2 требования об одном и том же только разными формулировками:

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

• Система должно регистрировать события интеграционного взаимодействия с системой А в журнал.

• ...

Абстрактность

R31 - Без решения

Формулировка требования не должна содержать элементы проектирования, конкретного решения. Исключения допустимы, если на то есть причина, например, какие-то объективные ограничения.

Из книги К. Вигерса:

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

Есть ситуации, когда указание решения в формулировке требования оправдано какими-то техническими, юридическими, проектными ограничениями:

• Для реализации продукта должно использоваться ПО с открытым кодом, доступное в рамках лицензии GNU. [ограничение реализации].

• Приложение должно использовать Microsoft .NET Framework 4.5. [архитектурное ограничение].

Указатели множества

R32 - Все элементы множества

Если необходимо указать на все элементы множества, следует использовать слово «каждый» вместо слов «все», «любой» или «оба».

Слова «все», «любой», «оба» вносят в формулировку неоднозначность: не ясно, имеется ли в виду всё множество или каждый его элемент.

Допустимость

R33 - Диапазон значений

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

Например: Насосная станция должна поддерживать поток воды со скоростью 120±10 литров в секунду в течение более 30 минут.

Количество

R34 - Измеримые величины

В формулировке требования необходимо количественно определять величины, для которых это уместно. В формулировках следует употреблять слова, обозначающие явно требуемую величину. К таким словам относятся: «немедленный», «быстрый», «как положено», «максимальный», «минимальный», «оптимальный», «номинальный», «простой в использовании», «с высокой скоростью», «средний», «лучшие практики», и «удобные для пользователя». Требования с такими словами неоднозначны.

R35 - Временные промежутки

Временные промежутки следует указывать явно. В формулировках требований следует избегать: «в итоге», «до», «раньше», «когда», «после», «как», «один раз», «самый ранний», «последний», «мгновенный», «одновременно», «пока» и «наконец».

Единообразие языка

R36 - Согласованные термины и единицы измерения

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

Неприемлемо в двух различных требованиях указывать на одну и ту же сущность двумя разными словами.

Например:

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

• Система должна сортировать элементы справочника по уникальному ключу.

В данном случае выделенные слова являются синонимами.

R37 - Единый список акронимов

Следует использовать единый список акронимов и использовать акронимы в формулировках потребностей/требований в строгом соответствии с этим списком.

Не следует в тексте документа в одном случае писать "Система управления бюджетом должна ...", в другом случае "СУБ должна ...".

R38 - Сокращения в формулировках

В формулировках требований не следует применять сокращения.

Например, под сокращением "Оп." - в одном месте документа подразумевается "Операция", в другом "Оператор". Это вносит неоднозначность.

R39 - Руководство по стилю

На протяжении всего проекта следует использовать руководство по стилю, в котором должны быть определены требования к оформлению, к формулировкам, шаблоны.

R40 - Десятичный формат

Следует использовать согласованный формат и согласованное количество значащих цифр после запятой для десятичных чисел.

Модульность

R41 - Связанные потребности и требования

Сгруппируйте связанные потребности и требования. В документе спецификации требований следует связанные друг с другом требования относить к одной группе, например, по принадлежности к одному классу (см. правило R29 "Классификация").

R42 - Структурированные наборы

Формировать наборы требований следует в соответствии с определенными структурами или шаблонами. Для обеспечения структурированности набора требований следует применять шаблоны документа спецификации требований и шаблоны для отдельных требований (см. правило R1).