Incose руководство по написанию требований

Уровень сложности
Простой

Время на прочтение
11 мин

Количество просмотров 2K

Введение

У INCOSE (Международного совета по системной инженерии) в июне 2023 года вышла итоговая сводка по руководство по написанию требований (ссылка).

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

Данная статья — перевод с английского языка итоговой сводки по написанию требований.

Определения

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

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

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

• Набор потребностей — это структурированный набор согласованных выражений потребностей для сущности (предприятия/бизнес-единицы/системы/подсистемы/системного элемента/процесса) и ее внешних интерфейсов.

• Набор требований — это структурированный набор согласованных выражений требований для сущности (предприятия/бизнес-единицы/системы/подсистемы/системного элемента/процесса) и ее внешних интерфейсов.

• Атрибут — дополнительная информация, связанная с потребностью/требованием, которая используется для облегчения её/его определения, понимания и управления.

• Выражение потребности — формулировка потребности + атрибуты.

• Выражение требования — формулировка требования + атрибуты.

Процессы верификации и валидации системы

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

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

Формальное преобразование

Формальное соглашение

Свойства набора требований

Формальное преобразование

Формальное соглашение

Правила, придающие свойства

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

Точность

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. Система должна формировать отчет «Название отчета 1».

2. Система должна формировать отчет «Название отчета 2».

3. Система должна формировать отчет «Название отчета 3».

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

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

Полнота

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

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

R25 — Заголовки

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

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

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

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

Условия

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

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

Неприемлемо:

Если наступит условие А, то

• Система должна сделать X

• Система должна сделать Y

• Система должна сделать Z.

Приемлемо:

1. Если наступит условие А, то Система должна сделать X

2. Если наступит условие А, то Система должна сделать Y

3. Если наступит условие А, то Система должна сделать 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 — Потребности и требования к варианту продуктовой линейки

© 2023 Prezi Inc.
Terms & Privacy Policy

Error get alias