Проектирование Информационных систем. Часть 10. Разработка требований 10.1. Правила формирования требований

Содержание курса

• ВВЕДЕНИЕ

• Введение в процесс формирования требований

• Инфраструктура (ландшафт) для организации проектной деятельности

• Управление целями заинтересованных лиц

• Формализация потребностей заказчика

• Выявление функции системы. 1.Теория систем Часть 1

• Выявление функции системы. 2. Моделирование сервисов

• Инжиниринг бизнес-процессов заказчика. 1. Применение UML Activity

• Инжиниринг бизнес-процессов заказчика. 2. Применение BPMN. Предварительный расчет ресурсоемкости проекта.

• Разработка логической структуры данных. 1. Применение UML Class diagram. Приемы и подходы проектирования

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

• Моделирование поведения целевой системы. 1. Теория систем Часть 2

• Моделирование поведения целевой системы. 2. Поведенческие диаграммы UML

• Моделирование поведения целевой системы. 3. Моделирование процессов управления

• Разработка требований на создание целевой ИС. 1. Правила формирования требований

• Разработка требований на создание целевой ИС. 2. Формирование Спецификаций требований

• Управление изменениями требований и организация эффективного взаимодействия в команде производства ИТ продукта

• Организация процессов проектирования в производстве ИТ-продукта

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

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

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

В стандарте IEEE Standard Glossary of Software Engineering Terminology (1990), требования охарактеризованы как:

• условия или возможности, необходимые пользователю для решения проблем или достижения целей;

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

•  документированное представление условий или возможностей для пунктов 1 и 2.

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

Дадим основные определения:

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

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

На стадии проектирования ПО, потребности уточняются, структурируются и преобразуются в совокупность требований к системе.

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

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

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

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

2.    Классификация требований

Начнем изучение темы, как обычно с классифицирования объекта рассмотрения. Смотри рисунок ниже.

Бизнес-требование — Высокоуровневая бизнес-цель организации или заказчиков системы, направленные на получение дополнительной прибыли заказчика:

• Либо через внедрение доработки\системы, которая будет приносить прямую прибыль;

• Либо через сокращение издержек и оптимизацию процессов;

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

Бизнес-правило — Политика, предписание, стандарт или правило, определяющее или ограничивающее некоторые стороны бизнес-процессов. Описывает почему система должна работать именно так в разрезе внутренних корпоративных правил, требований закона и различных стандартов.

Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз-утверждений, в виде сценариев использования (use case), пользовательских историй (user stories), сценариев взаимодействия (scenario).

Функциональные требования — определяют требования к функциям системы. Описание требуемого поведения системы в определенных условиях.

Нефункциональное требование — Описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.

Системное требование — Требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять   собой ПО или совокупность ПО и оборудования. «Требования к реализации».

• Требования к безопасности и надёжности

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

Для того, чтобы сделать требования понятными, полными, проверяемыми и пригодными для анализа, реализации и тестирования их уточняют при помощи следующих элементов:

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

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

• требования к используемым технологиям: языки разработки ПО и сопутствующие фреймворки, особенности поддержки и развития реализованного решения;

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

• рамки, ограничения, правила и стандарты. Под ограничениями стандарт понимает любые факторы, которые ограничивают возможности команды разработки, от нормативных политик до соображений безопасности;

• допущения и зависимости. В частности, стандарт отмечает, что эти факторы не являются конструктивными ограничениями ПО, но любые их изменения могут повлиять на требования SRS;

• требования к внешним интерфейсам (UX-интерфейсы пользователя, программные интерфейсы, интерфейсы оборудования, интерфейсы связи и коммуникации).

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

3.    Свойства формулировок требований

Для того чтобы набор собранных требований обладал свойствами качественного документа, необходимо следовать определенным рекомендациям, в соответствии со стандартом ISO/IEC/IEEE 29148:2018.

Стандарт ISO/IEC/IEEE 29148:2018 — это международный стандарт, определяющий процессы, деятельность и задачи, связанные с инженерией требований в жизненном цикле систем и программного обеспечения. Он также устанавливает качества, которым должны соответствовать индивидуальные требования и наборы требований, чтобы быть эффективными и пригодными для реализации.

Стандарт в том числе определяет характеристики (атрибуты) качества требований, деля их на 2 категории: 1) Качества отдельных (единичных) требований; 2) Качества набора требований (требований в совокупности).

Рассмотрим основные свойства требований, определенные стандартом:

C1 – Необходимость (Necessity).

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

Для того, чтобы проверить необходимость требования, задайте вопрос: «Что произойдёт, если мы уберём это требование? Пострадают ли цели или пользователи системы?».

• Если ничего не изменится — требование избыточно.

• Если система потеряет ценность, функциональность, безопасность или соответствие стандартам — требование необходимо.

C2 – Адекватность уровню.

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

Требование должно быть сформулировано конгруэнтно тому уровню абстракции, который соответствует текущему уровню спецификации:

• Бизнес-уровень: цели, результаты, не детализируются функции.

• Пользовательский уровень: то, что делает пользователь, интерфейсы.

• Системный уровень: функции и поведение системы.

• Компонентный уровень: требования к отдельным модулям, интерфейсам, данным.

Примеры требований для разных уровней:

    Пример адекватного требования на бизнес-уровне: «Система должна сократить время обработки заявок клиентов не менее чем на 30%.»

— Подходит для бизнес-целей: отражает, зачем создаётся система.

    Пример адекватного требования на системном уровне: «Система должна автоматически классифицировать входящие заявки по срочности.»

— Конкретизирует, что должна делать система.

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

— Это уже о том, как реализовать, а не просто что делать.

C3 – Однозначность (Unambiguity).

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

• Использовать конкретные, измеримые характеристики.

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

• Избегать оценочных и субъективных понятий.

• Использовать терминологический словарь (глоссарий).

• Проверять требования через рецензии и обсуждения с командой.

C4 – Полнота (Completeness)

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

Каждое отдельное требование и весь набор требований должны:

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

• не оставлять пробелов или двусмысленностей;

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

C5 – Простота (Simplicity).

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

C6 – Реализуемость (Feasibility).

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

Для того, чтобы проверить свойство Реализуемость, чаще всего достаточно получить положительные ответы на следующие вопросы:

• Технологии: существует ли способ это реализовать?

• Ресурсы: есть ли нужные люди, инструменты, время?

• Законодательство: не противоречит ли требование законам?

• Зрелость: не требует ли оно технологий, которых ещё нет?

C7 – Пригодность для верификации (Verifiability).

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

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

• Использовать конкретные, измеримые формулировки.

• Избегать субъективных слов (удобный, красивый, быстрый).

• Чётко указать условия или критерии приемки.

C9 – Соответствие нормам (Compliance).

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

Требование должно соответствовать:

• применимым законодательным актам,

• действующим нормативным стандартам,

• отраслевым правилам,

• внутренним политикам и регламентам организации.

С11 – Непротиворечивость (Consistency).

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

Пример причин возникновения противоречий в требованиях:

• бизнес-аналитик, что что-то уже продумал/описал и делает это по-новой в другом месте;

• требование меняется, но бизнес-аналитик изменяет его не везде, где оно описано;

• бизнес-аналитик невнимателен к граничным значениям – в разных частях требований;

• новый бизнес-аналитик на проекте упустил/не знал про какие-то детали реализации, особенно, когда они не описаны или их сложно отследить в системе управления требованиями;

• текст требования изменили, а макеты не изменили.

С14 – Валидируемость

Реализация набора потребностей должна привести к достижению целей, ожиданий заинтересованных сторон и концепций жизненного цикла в рамках ограничений (стоимостных, временных, технических, правовых и нормативных) с приемлемым риском.

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

Пример валидного требования: «Пользователь должен иметь возможность просматривать историю своих заказов за последние 12 месяцев.»

При такой формулировке можно показать макет или прототип пользователю и спросить: «Такой функционал вам подходит?». Пользователь скажет «да» или «нет», и это будет акт валидации.

4.    Правила формирования требований

Также стандартом ISO/IEC/IEEE 29148:2018 регламентируются характеристики (quality attribute) — это критерий или показатель качества требования, который помогает оценить, насколько требование правильно, понятно и пригодно для использования в процессе разработки системы. А также устанавливаются правила характеристик (rules) — это конкретные предписания или рекомендации, которые помогают правильно формулировать требования и обеспечивают их качество.

Рассмотрим основные характеристики и правила стандарта:

Характеристика Точность (Precision).

В ISO/IEC/IEEE 29148:2018 одна из ключевых характеристик корректного требования: оно должно быть однозначным, конкретным и лишённым субъективности, чтобы исключить любые интерпретации.

Правила применения характеристики Точность:

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

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

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

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

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

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

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

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

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

Уровни:

1)    Уровень бизнес-управления.

2)    Уровень бизнес-операций (операционной деятельности).

3)    Уровень системы.

4)    Уровень подсистемы, элемента.

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

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

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

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

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

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

• время (секунды, минуты, часы),

• объём (МБ, ГБ),

• частота (запросов/сек),

• длина, количество, процент и т.д.

Универсальный шаблон для этого правила:

 «[Кто] должен [что сделать] в течение/при/не более чем [число] [единица измерения].»

R7 — Неточные термины.

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

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

R8 — Снятие ответственности.

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

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

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

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

Характеристика Краткость (Concise).

В ISO/IEC/IEEE 29148:2018 краткость рассматривается как часть требований к стилю формулировки, особенно при обеспечении ясности и однозначности. В этом контексте каждое требование должно быть: правильным, недвусмысленным, полным, согласованным, проверяемым, изменяемым и отслеживаемым.

Правила применения характеристики Кратность:

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

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

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

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

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

Характеристика Однозначность (unambiguity).

В ISO/IEC/IEEE 29148:2018 — это одна из ключевых характеристик хороших требований. Она означает, что требование должно быть сформулировано так, чтобы все заинтересованные стороны (разработчики, аналитики, тестировщики, заказчики и др.) понимали его одинаково, без возможности двойного толкования.

Правила применения характеристики Однозначность:

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

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

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

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

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

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

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

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

С применением косой черты (“/”) это предложение можно истолковать несколькими способами:

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

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

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

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

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

Характеристика Простота (simplicity).

В ISO/IEC/IEEE 29148:2018 рассматривается как важное качество формулировки требований, способствующее их понятности, точности и эффективности коммуникации между всеми участниками проекта. Простой язык делает требования более понятными, однозначными и пригодными для практической работы в реальных проектах.

Правила применения характеристики Простота:

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

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

R19 — Союзы

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

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

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

Следует избегать фраз, которые указывают на “цель“, “намерение” или “обоснования” потребности или требования. Включение обоснования в формулировку — избыточно.

Необходимо вводить или специальный раздел, или атрибут требования – «Обоснование».

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

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

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

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

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

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

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

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

Характеристика Полнота (completeness).

В ISO/IEC/IEEE 29148:2018 является одной из ключевых характеристик качественного требования и всего набора требований. Обеспечивает возможность охватывать все аспекты системы, быть понятным без обращения к внешним источникам, допустимость его реализовать, проверить и проследить.

Правила применения характеристики Полнота:

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

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

Плохой пример: «Система должна выводить пользователю сообщение о подтверждении в среднем за 3 секунды и не более чем через 6 секунд после того, как он отослал информацию ей.»

R25 — Заголовки

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

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

Характеристика Реалистичность (realism).

В ISO/IEC/IEEE 29148:2018 относится к критерию качества требований, который гарантирует, что каждое требование может быть выполнено в рамках доступных ресурсов, технологий, бюджета, сроков и ограничений проекта.

Правила применения характеристики Реалистичность:

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

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

Характеристика Условия (conditions).

В ISO/IEC/IEEE 29148:2018 не выделяется как отдельный критерий качества требования, но играет важную роль в структуре и формулировке правильных требований.

Правила применения характеристики Условия:

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

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

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

Плохой пример: «В случае 1:

должно быть 1.1;

должны быть 1.2;

должны быть 1.3»

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

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

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

Характеристика Уникальность (uniqueness).

В ISO/IEC/IEEE 29148:2018 указывается, что: требования должны быть отдельными, независимыми, недублирующими. Каждое требование должно быть отслеживаемо на протяжении всего жизненного цикла разработки (от бизнес-цели до кода и теста). Важно поддерживать уникальные идентификаторы, особенно при управлении изменениями.

Правила применения характеристики Уникальность:

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждое требование должно иметь собственный уникальный идентификатор;

Характеристика Абстрактность (abstraction).

В ISO/IEC/IEEE 29148:2018 напрямую не выделяется как отдельное качество требований, однако уровень абстракции считается важным аспектом при классификации и структурировании требований.

Стандарт требует, чтобы:

• Требования на разных уровнях были согласованы между собой,

• Высокоуровневые абстрактные требования декомпозировались в низкоуровневые конкретные,

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

Правила применения характеристики Абстрактность:

R31 — Без реализации

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

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

Характеристика Допустимость (feasibility, acceptability).

В ISO/IEC/IEEE 29148:2018 не выделяется как отдельное свойство с одноимённым термином «допустимость», однако понятие допустимости тесно связано с несколькими важными качествами требований.

Правила применения характеристики Допустимость:

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

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

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

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

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

Например: Среднее время между отказами устройства чтения карт должно не превышать 90 дней

Характеристика Единообразие языка (language uniformity / consistency of language).

В ISO/IEC/IEEE 29148:2018 является важным аспектом качества требований, даже если сам термин «единообразие» не всегда используется дословно. Он отражён в требованиях к ясности, однозначности, проверяемости и модифицируемости требований.

Правила применения характеристики Единообразие языка:

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

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

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

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

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

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

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

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

Характеристика Модульность (modularity).

В ISO/IEC/IEEE 29148:2018 не выделяется как отдельный формальный критерий качества требований, но идея модульности непосредственно заложена в нескольких важных принципах инженерии требований. Она особенно актуальна при структурировании, управлении и сопровождении требований.

Правила применения характеристики Модульность:

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

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

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

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

В следующей части мы более подробно рассмотрим подходы структурирования требований и разработки Спецификаций требований (SRS).