Введение
У INCOSE (Международного совета по системной инженерии) в июне 2023 года вышла итоговая сводка по руководство по написанию требований (ссылка).
Данная итоговая сводка содержит определения, краткое описание свойств, которыми должны обладать качественно сформулированные потребности/требования, а также наборы потребностей/требований. В итоговой сводке содержится краткое изложение правил написания качественных потребностей/требований, а также их атрибутов.
Данная статья - перевод с английского языка итоговой сводки по написанию требований.
Определения
Сущность - это отдельный элемент, к которому применима концепция, потребность или требование. Сущностью может быть организация, бизнес-подразделение, проект, поставщик, услуга, процедура, система (система, подсистема, системный элемент), продукт, процесс или класс заинтересованных сторон (пользователь, оператор, тестировщик, сопровождающий и т.д.).
Формулировка потребности - это результат формального преобразования одного или нескольких источников или концепций жизненного цикла в согласованное обязательство того, что сущность будет выполнять определенную функцию или обладать определенным качеством в рамках определенных ограничений с приемлемым риском.
Формулировка требования - это результат формального преобразования одного или нескольких источников, потребностей или требований более высокого уровня в согласованное обязательство того, что сущность будет выполнять определенную функцию или обладать определенным качеством в рамках определенных ограничений с приемлемым риском.
Набор потребностей - это структурированный набор согласованных выражений потребностей для сущности (предприятия/бизнес-единицы/системы/подсистемы/системного элемента/процесса) и ее внешних интерфейсов.
Набор требований - это структурированный набор согласованных выражений требований для сущности (предприятия/бизнес-единицы/системы/подсистемы/системного элемента/процесса) и ее внешних интерфейсов.
Атрибут - дополнительная информация, связанная с потребностью/требованием, которая используется для облегчения её/его определения, понимания и управления.
Выражение потребности - формулировка потребности + атрибуты.
Выражение требования - формулировка требования + атрибуты.
Процессы верификации и валидации системы
Потребности и требования "нитями" связывают воедино все этапы и артефакты жизненного цикла создания системы. Как только потребности верифицированы и отвалидированы, все последующие артефакты проверяются на соответствие потребностям, и как только входные требования для проектирования проверены и отвалидированы, все последующие артефакты проверяются на соответствие этим входным требованиям к проектированию.
Свойства формулировок отдельных потребностей/требований
Формальное преобразование
Свойство |
Краткое описание |
C1 - Необходимость |
Формулировка потребности/требования определяет важную характеристику, способность, ограничение или качество, реализация которых действительно необходима для удовлетворения исходных потребностей или требования более высокого уровня |
C2 – Адекватность уровню |
Конкретная цель и степень детализации формулировки потребности/требования соответствуют выбранному уровню (уровню абстракции, организации или архитектуры системы) сущности, к которой потребность/требование относится |
C5 – Простота |
Формулировка потребности/требования содержит только одну способность, характеристику, ограничение или показатель качества |
C8 – Корректность |
Формулировка потребности должна точно отражать концепцию жизненного цикла или источник, на основании которого она была создана. Формулировка требования должна точно отражать потребность, источник, требование более высокого уровня, на основании которых требование было создано |
C9 – Соответствие нормам |
Формулировка потребности/требования должна соответствовать утвержденному стандартному руководству по стилю/стандарту, шаблону для написания и управления потребностями и требованиями |
Формальное соглашение
Свойство |
Краткое описание |
C3 – Однозначность |
Вся аудитория, которая читает формулировку потребности/требования, интерпретирует её одинаковым образом |
C4 – Полнота |
Формулировка потребности в достаточной степени описывает необходимую способность, характеристику, ограничение, или качество для удовлетворения потребности источника более высокого уровня, из которого оно было получено. Формулировка требования в достаточной степени описывает необходимую способность, характеристику, ограничение, или качество для удовлетворения потребности, источника или требования более высокого уровня, из которого оно было получено |
C6 – Реализуемость |
Потребность/требование можно реализовать с приемлемым риском в заданных ограничениях: стоимостных, временных, технических, юридических, этических, ограничениях безопасности |
C7 – Пригодность для верификации |
Потребность/требование должно быть сформулировано и структурировано так, что его выполнение можно проверить утверждающим органом |
Свойства набора требований
Формальное преобразование
Свойство |
Краткое описание |
C10 – Полнота |
Набор потребностей и требований должен в достаточной степени описывать необходимые возможности, характеристики, функциональность, производительность, движущие силы, ограничения, условия, взаимодействия, стандарты, нормативные акты, безопасность, отказоустойчивость и факторы качества без других наборов потребностей или требований на соответствующем уровне абстракции |
С11 – Непротиворечивость |
Набор потребностей и набор требований является согласованным, если содержит отдельные потребности или требования, которые являются уникальными, не противоречат, не пересекаются друг с другом, разрабатываются с помощью единообразного языка с использование согласованных терминов |
С15 – Корректность |
Набор потребностей должен точно отражать концепцию жизненного цикла или источник, на основании которого он был создан. Набор требований должен точно отражать потребность, источник, требование более высокого уровня, на основании которых он был создан |
Формальное соглашение
Свойство |
Краткое описание |
С12 – Реализуемость |
Набор потребностей/требований можно реализовать с приемлемым риском в заданных ограничениях: стоимостных, временных, технических, юридических, этических, ограничениях безопасности |
С13 – Понятность |
Набор потребностей/требований должен содержать ясное описание ожиданий сущности и описание отношения сущности к системе, частью которой она является |
С14 – Валидируемость |
Реализация набора потребностей должна привести к достижению целей, ожиданий заинтересованных сторон и концепций жизненного цикла в рамках ограничений (стоимостных, временных, технических, правовых и нормативных) с приемлемым риском. Реализация набора требований должна привести к удовлетворению набора потребностей и требований более высокого уровня в рамках ограничений (стоимостных, временных, технических, правовых и нормативных) с приемлемым риском |
Правила, придающие свойства
Для того чтобы потребность/требование обладали теми или иными свойствами качественных потребностей/требований, нужно следовать определенным правилам.
Точность
R1 - Структурированные предложения
Формулировка потребности или требования должна соответствовать определенному согласованному шаблону.
R2 - Активный залог
В формулировках потребностей или требований нужно использовать активный залог (а не пассивный), чтобы четко указать какая сущность является субъектом (подлежащим).
R3 - Соответствующие уровню подлежащее и сказуемое
Подлежащее и сказуемое в формулировке потребности/требования должны соответствовали уровню, к которому применимо потребность/требование.
Неприемлемо:
На бизнес-уровне в формулировках бизнес-требований использовать: Система должна ...
На уровне системы в формулировках требований использовать: Пользователь должен ...
R4 - Определенные термины
Необходимо определить все термины, используемые в описаниях потребностей и требований, в соответствующем глоссарии и/или словаре данных.
R5 - Определенные артикли
Данное правило применимо для английского языка.
Следует использовать определенный артикль “the”, а не неопределенный “a”.
R6 - Единицы измерения
Каждую числовое значение следует сопровождать единицей измерения.
R7 - Неточные термины
Следует избегать наречий: несколько; любой; допустимо; сколько-нибудь; много; большое количество; мало; почти всегда; очень близко к; приблизительно; около; близко к; почти.
Следует избегать прилагательных: дополнительный; актуальный; обыденный; общий; типовой; важный; гибкий; расширяемый; типичный; достаточный; адекватный; пригодный; эффективный; эффектный; качественный; разумный; общепринятый.
R8 - Снятие ответственности
Не использовать слова, размывающие ответственность: насколько это возможно; как можно меньше; где возможно; как можно больше; если это необходимо; при необходимости; по мере необходимости; сообразно обстоятельствам; как требуется; в рамках целесообразного; если это осуществимо.
R9 - Открытые формулировки
В формулировках следует избегать: «включая, но не ограничиваясь», «и так далее», «и тому подобное».
Краткость
R10 - Лишние глаголы в неопределенной форме
Следует избегать лишних глаголов в неопределенной форме, идущих подряд.
Неприемлемо: Система должна обладать способностью хранить ...
Приемлемо: Система должна хранить ...
R11 - Отдельные предложения
Требования следует формулировать так, чтобы в одном простом предложении было определено только одно состояние или одна характеристика.
Однозначность
R12 - Правила грамматики
В формулировках следует избегать грамматических ошибок.
R13 - Правила орфографии
В формулировках следует избегать орфографических ошибок.
R14 - Правила пунктуации
В формулировках следует избегать пунктуационных ошибок.
R15 - Логические операторы
В формулировках необходимо единообразно выделять и использовать логические операторы: “[X И Y]”, “[X ИЛИ Y]”, [X Искл. ИЛИ Y]”, “НЕ [X ИЛИ Y]” и пр.
R16 - Избегать частицы НЕ
В формулировке требования следует избегать частицы «Не».
R17 - Знак косой черты
Избегайте использования знака косой черты в формулировках ("/"), за исключением единиц измерения, например, км/ч.
Знак косой черты вносит в формулировку неопределенность, так как может разная интерпретация. Например, запись «и/или».
Простота
R18 - Одна мысль - Одно предложение
Одно предложение должно содержать одну мыль, которая может быть дополнена придаточными предложениями.
R19 - Союзы
В формулировках следует избегать союзов: «и», «или», «затем», «если», «но», «также», «однако», «пока», «с другой стороны», «в противном случае». Наличие этих союзов - это характерный признак наличия нескольких требований в одной формулировке.
R20 - Формулировка с обоснованиями
Следует избегать фраз, которые указывают на “цель“, “намерение” или “обоснования” потребности или требования. Включение обоснования в формулировку - это избыточно, так как есть специальный атрибут А1 "Обоснование".
R21 - Круглые скобки
Следует избегать круглых скобок, так как часто там указывают незначащий, лишний текст.
R22 - Перечисление
Следует перечислять наборы требований явно вместо использования обобщающих фраз для обозначения набора.
Неприемлемо: Система должна формировать отчетность по исполнению бюджета.
Приемлемо:
Система должна формировать отчет "Название отчета 1".
Система должна формировать отчет "Название отчета 2".
Система должна формировать отчет "Название отчета 3".
R23 - Дополнение диаграммами, моделями
Если в требовании необходимо описать сложное поведение, следует ссылаться на диаграмму или модель.
Полнота
R24 - Местоимения
Следует избегать использования личных и неопределенных местоимений.
R25 - Заголовки
Не следует полагать, что заголовок - это часть требования. Требование должно быть самодостаточным и без заголовка.
Реалистичность
R26 - Абсолютные значения
Следует избегать использования недостижимых абсолютных значений, таких как 100% надежность, 100% доступность, все, каждый, всегда, никогда и т.д.
Условия
R27 - Явные условия
Если одно условие распространяется на несколько требований, то следует писать данные требования отдельно друг от друга, в формулировку каждого из требований включить это условие.
Неприемлемо:
Если наступит условие А, то
Система должна сделать X
Система должна сделать Y
Система должна сделать Z.
Приемлемо:
Если наступит условие А, то Система должна сделать X
Если наступит условие А, то Система должна сделать Y
Если наступит условие А, то Система должна сделать Z.
R28 - Множественные условия
Если в требовании присутствует несколько условий, следует явно указывать логические правила между ними.
Неприемлемо:
Система должна выполнить функцию А в случае следующих условий:
Условие X
Условие Y
Условие Z.
Приемлемо:
Система должна выполнить функцию А в случае одновременного выполнения следующих условий:
Условие X
Условие Y
Условие Z.
Уникальность
R29 - Классификация
Следует классифицировать потребности и требования в соответствии с аспектами проблемы или системы, к которым они относятся.
R30 - Уникальность
Требование должно быть уникальным, в наборе требований не должно быть дублей.
Абстрактность
R31 - Без решения
Формулировка требования не должна содержать элементы проектирования, конкретного решения. Исключения допустимы, если на то есть причина, например, какие-то объективные ограничения.
Указатели множества
R32 - Все элементы множества
Если необходимо указать на все элементы множества, следует использовать слово «каждый» вместо слов «все», «любой» или «оба».
Допустимость
R33 - Диапазон значений
Для количественной оценки в формулировке требования следует указывать диапазон значений. Например, "... с точностью ±3 метра".
Количество
R34 - Измеримые величины
В формулировке требования необходимо количественно определять величины, для которых это уместно.
Неприемлемо: Канал связи должен обладать максимальной пропускной способностью.
Приемлемо: Канал связи должен пропускать не менее 100 мбит/сек.
R35 - Временные промежутки
Временные промежутки следует указывать явно. В формулировках требований следует избегать: «в итоге», «до», «раньше», «когда», «после», «как», «один раз», «самый ранний», «последний», «мгновенный», «одновременно», «пока» и «наконец».
Единообразие языка
R36 - Согласованные термины и единицы измерения
Следует убедиться, что каждый термин используется в одном и том же значении во всем наборе потребностей/требований.
R37 - Единый список акронимов
Следует использовать единый список акронимов и использовать акронимы в формулировках потребностей/требований в строгом соответствии с этим списком.
R38 - Сокращения в формулировках
В формулировках требований не следует применять сокращения. Например, не следует использовать сокращение "Оп" в рамках одного набора требований, где в одном случае "Оп" - оператор, в другом операция.
R39 - Руководство по стилю
На протяжении всего проекта следует использовать руководство по стилю, в котором должны быть определены требования к оформлению, к формулировкам, шаблоны.
R40 - Десятичный формат
Следует использовать согласованный формат и согласованное количество значащих цифр после запятой для десятичных чисел.
Модульность
R41 - Связанные потребности и требования
Сгруппируйте связанные потребности и требования.
R42 - Структурированные наборы
Формировать наборы требований следует в соответствии с определенными структурами или шаблонами.
Матрица свойств и правил
Ниже представлена матрица свойств качественных требований/наборов требований и правил, которые придают требованиям/наборам требований эти свойства.
Атрибуты
Атрибуты, помогающие определить потребности и требования и их обоснование
A1 - Обоснование
A2 - Ссылка на родительское требование
A3 - Ссылка на источник
A4 - Состояния и режимы
A5 – Распределение / Бюджетирование
Атрибуты, связанные с верификацией и валидацией системы
A6 - Критерии успеха для верификации или валидации системы
A7 - Стратегия для верификации или валидации системы
A8 - Метод для верификации или валидации системы
A9 - Организация, ответственная за верификацию или валидацию системы
A10 - Уровень верификации или валидации системы
A11 - Этап верификации или валидации системы
A12 - Условия применения
A13 - Результаты верификации или валидации системы
A14 - Статус верификации или валидации системы
Атрибуты, помогающие поддерживать требования
A15 - Уникальный идентификатор
A16 - Уникальное имя
A17 - Автор/Инициатор
A18 - Дата внесения требования
A19 - Владелец
A20 - Заинтересованные стороны
A21 - Комитет по изменениям
A22 - Предложенное изменение
A23 - Номер версии
A24 - Дата утверждения
A25 - Дата последнего изменения
A26 - Стабильность
A27 - Ответственное за реализацию лицо
A28 - Статус верификации потребности или требования
A29 - Статус валидации потребности или требования
A30 - Статус требования
A31 - Статус (реализации)
A32 – Ссылка на описание интерфейса
A33 – Ссылка на требование того же уровня
A34 - Приоритет
A35 - Критичность
A36 - Риск (реализации)
A37 - Профилактика риска
A38 – Ключевое требование
A39 - Дополнительные комментарии
A40 - Тип/категория
Атрибуты, способствующие повторному использованию требований
A41 - Применимость
A42 - Регион
A43 - Страна
A44 - Штат/Область
A45 - Рыночный сегмент
A46 – Структурное подразделение
Атрибуты, помогающие в управлении продуктовой линейкой
A47 – Продуктовая линейка
A48 - Общие потребности и требования к продуктовой линейке
A49 - Потребности и требования к варианту продуктовой линейки
Комментарии (6)
sophist
27.08.2023 09:39Система должна выполнить функцию А в случае одновременного выполнения следующих условий:
Условие X
Условие Y
Условие Z.
Возможно, лучше было бы использовать в таком контексте пару "неправильно/правильно". Не дословно, зато по смыслу.
avshkol
Понятно, что это перевод международного нормативного документа, но хорошо бы раскрыть в нескольких статьях с примерами "вот так правильно формулировать требования в техдокументации, а так - неправильно", поскольку человеку вне контекста системной инженерии трудно понять все эти многочисленные пункты перечислений...
И еще - сущность и атрибуты - это то же самое, что и классы и атрибуты в ООП? Можно ли их формализовать в коде?
Renata_Bakhtiarova Автор
Здравствуйте, спасибо за комментарий. По поводу раскрытия правил в примерах - согласна, постараюсь привести их в отдельной статье. По поводу сущности, как я понимаю, это подлежащее в формулировке требования, т.е. субъект который выполняет действие. Например, если требования сформулированы с точки зрения пользователя, то сущностью является пользователь: Пассажир должен иметь возможность зарегистрироваться на рейс. В этом случае при дальнейшем проектировании системы "Пассажир" может быть определен как класс и формализован в коде. Про атрибуты: тут имеется ввиду атрибуты самого требования. Самый простой пример, когда заводится задача в трекере задач (например, мы используем Redmine, YouTrack), то там задаем атрибуты: статус, приоритет, принадлежность спринту, плановый срок реализации и пр. В данном руководстве приводится расширенный список этих атрибутов, а какие использовать, каждый решает сам. Так что эти атрибуты не формализуются в коде целевой системы.