Содержание курса
Инфраструктура (ландшафт) для организации проектной деятельности
Инжиниринг бизнес-процессов заказчика. 1. Применение UML Activity
Разработка логической структуры данных. 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 формулировка может иметь следующие варианты структуры:
[Условие] [Субъект] [Действие] [Объект] [Ограничение/Действие].
[Субъект] [Действие] [Объект].
Неправильно | Правильно |
"Автосохранение заявки каждые 5 минут." | "Система должна сохранять черновик заявки автоматически каждые 5 минут." · Субъект: Система · Действие: должна сохранять · Объект: черновик заявки · Условие: автоматически каждые 5 минут |
R2 - Активный залог.
В формулировках потребностей или требований нужно использовать активный залог (а не пассивный), чтобы четко указать какая сущность является субъектом (подлежащим).
Неправильно | Правильно |
Отчет об исполнении заявок на доходы и расходов должен быть сформирован | Система должна сформировать отчет об исполнении заявок на доходы и расходы |
R3 - Соответствующие уровню подлежащее и сказуемое.
Подлежащее и сказуемое в формулировке потребности/требования должны соответствовать уровню, к которому применимо потребность/требование. Соразмерно свойству требования – «C2 Адекватность уровню».
Уровни:
1) Уровень бизнес-управления.
2) Уровень бизнес-операций (операционной деятельности).
3) Уровень системы.
4) Уровень подсистемы, элемента.
Неправильно на уровне системы формулировать требование как: «Пользователь должен ...»
На уровне системы следует предъявлять требования к системе, а не к ее пользователю. Рекомендуется преобразовать потребность пользователя в требование к системе: «Что должна делать система, чтобы удовлетворить потребность пользователя?»
R4 - Определенные термины.
Необходимо определить все термины, используемые в описаниях потребностей и требований, в соответствующем глоссарии и/или словаре данных.
Неправильно формулировать требование как: «Система должна отображать текущее время». Ведь из формулировки непонятно, какое время нужно отображать. Нужно дать определение понятию текущего времени в глоссарии/словаре данных, а именно: часовой пояс, формат времени, точность.
R6 - Единицы измерения
Каждое числовое значение следует сопровождать единицей измерения:
время (секунды, минуты, часы),
объём (МБ, ГБ),
частота (запросов/сек),
длина, количество, процент и т.д.
Универсальный шаблон для этого правила:
"[Кто] должен [что сделать] в течение/при/не более чем [число] [единица измерения]."
Неправильно | Правильно |
В режиме поддержания температуры термопот должен сохранять температуру жидкости 80 градусов | В режиме поддержания температуры термопот должен сохранять температуру жидкости 80 градусов Цельсия |
R7 - Неточные термины.
Следует избегать наречий: несколько; любой; допустимо; сколько-нибудь; много; большое количество; мало; почти всегда; очень близко к; приблизительно; около; близко к; почти.
Следует избегать прилагательных: дополнительный; актуальный; обыденный; общий; типовой; важный; гибкий; расширяемый; типичный; достаточный; адекватный; пригодный; эффективный; эффектный; качественный; разумный; общепринятый.
R8 - Снятие ответственности.
Не использовать слова, размывающие ответственность: насколько это возможно; как можно меньше; где возможно; как можно больше; если это необходимо; при необходимости; по мере необходимости; сообразно обстоятельствам; как требуется; в рамках целесообразного; если это осуществимо.
Неправильно | Правильно |
Если возможно, номера счетов следовало бы проверять по списку корпоративных счетов | В момент ввода номера счета система должна отобразить сообщение об ошибке, если этого номера счета нет в основном корпоративном списке счетов |
R9 - Открытые формулировки.
В формулировках следует избегать: «включая, но не ограничиваясь», «и так далее», «и тому подобное».
Пример плохого требования: «Система должна обеспечивать поддержку показателей с разными временными периодами (например, ежемесячный, ежеквартальный, ежегодный и т.д.).»
Характеристика Краткость (Concise).
В ISO/IEC/IEEE 29148:2018 краткость рассматривается как часть требований к стилю формулировки, особенно при обеспечении ясности и однозначности. В этом контексте каждое требование должно быть: правильным, недвусмысленным, полным, согласованным, проверяемым, изменяемым и отслеживаемым.
Правила применения характеристики Кратность:
R10 - Лишние глаголы в неопределенной форме
Следует избегать лишних глаголов в неопределенной форме, идущих подряд.
Перечисление друг за другом глаголов в неопределенной форме усложняет формулировку требования. Пример плохой формулировки: «Система должна обладать возможностью хранить загруженные данные.»
R11 - Отдельные предложения
Требования следует формулировать так, чтобы в одном простом предложении было определено только одно состояние или одна характеристика. Допускается формулировать требование с уточнением в виде придаточного предложения. В этом случае не допускается разделять сказуемое и дополнение.
Неправильно | Правильно |
Система должна обрабатывать платежи быстро и обеспечивать отчеты для пользователей. | · Система должна обрабатывать платежи в течение 2 секунд. · Система должна предоставлять пользователям отчеты по платежам. |
Характеристика Однозначность (unambiguity).
В ISO/IEC/IEEE 29148:2018 - это одна из ключевых характеристик хороших требований. Она означает, что требование должно быть сформулировано так, чтобы все заинтересованные стороны (разработчики, аналитики, тестировщики, заказчики и др.) понимали его одинаково, без возможности двойного толкования.
Правила применения характеристики Однозначность:
R15 - Логические операторы
В формулировках необходимо единообразно выделять и использовать логические операторы. Руководство по написанию требований рекомендует формализовать правила использования логических операторов, и использовать их во всем тексте документа.
Например, договариваемся о следующем: Использовать квадратные скобки для указания условий. Использовать следующие операторы: И, ИЛИ, Искл. ИЛИ.
Примеры использования: [X И Y]”, “[X ИЛИ Y]”, [X Искл. ИЛИ Y]”, “НЕ [X ИЛИ Y]”.
R16 - Избегать частицы НЕ
В формулировке требования следует избегать частицы «Не».
Неправильно | Правильно |
Пользователь не должен иметь возможность активизировать договор, если он не сбалансирован. | Система должна позволять пользователю активировать договор, только если этот договор сбалансирован. |
R17 - Знак косой черты
Избегайте использования знака косой черты в формулировках ("/"), за исключением единиц измерения, например, км/ч.
Неправильно | Правильно |
Система должна обеспечивать автоматический сбор информации о лицензионных ключах при массовом выпуске продукта отделом доставки/исполнения | Система должна обеспечивать автоматический сбор информации о лицензионных ключах при массовом выпуске продукта отделом доставки и отделом исполнения |
С применением косой черты (“/”) это предложение можно истолковать несколькими способами:
«отдел доставки/исполнения» — это название подразделения;
доставка и исполнение являются синонимами;
в некоторых проектах упомянутое подразделение называется отделом доставки, а в других — отделом исполнения;
массовый выпуск продукта может выполнять отдел доставки или отдел исполнения, так что косая черта означает «или»;
массовый выпуск продукта отдел доставки или отдел исполнения выполняют совместно, так что косая черта означает «и».
Характеристика Простота (simplicity).
В ISO/IEC/IEEE 29148:2018 рассматривается как важное качество формулировки требований, способствующее их понятности, точности и эффективности коммуникации между всеми участниками проекта. Простой язык делает требования более понятными, однозначными и пригодными для практической работы в реальных проектах.
Правила применения характеристики Простота:
R18 - Одна мысль - Одно предложение
В требовании должна содержаться одна и только одна мысль, которая может быть дополнена придаточными предложениями.Следует избегать сложносочиненных (равноправных предложений).
Неправильно | Правильно |
Должна обеспечиваться возможность создания резервных копий настроек прикладного ПО и информации, обрабатываемой в Системе, а также возможность восстановления из данных резервных копий. | 1. Система должна создавать резервные копии ... 2. Система должна восстанавливать данные из резервных копий ... |
R19 - Союзы
В формулировках следует избегать союзов, наречий: «и», «или», «затем», «если», «но», «также», «однако», «пока», «с другой стороны», «в противном случае». Наличие этих союзов - это характерный признак наличия нескольких требований в одной формулировке.
После запятой и наречия обычно следует второе требование. Их нужно разделить на отдельные требования.
R20 - Формулировка с обоснованиями
Следует избегать фраз, которые указывают на “цель“, “намерение” или “обоснования” потребности или требования. Включение обоснования в формулировку - избыточно.
Необходимо вводить или специальный раздел, или атрибут требования – "Обоснование".
Неправильно | Правильно |
Система должна обеспечивать резервное копирование данных каждые 4 часа, так как может произойти сбой и потеря данных. | Система должна обеспечивать резервное копирование данных каждые 4 часа. |
R21 - Круглые скобки
Следует избегать круглых скобок, так как часто там указывают незначащий, лишний текст.
В скобки заключен излишний, ненужный текст, который усложняет формулировку. Следует исключить его.
Неправильно | Правильно |
Блок управления должен отключать питание котла, когда температура воды выше 85 °C (обычно к концу цикла кипения). | Блок управления должен отключать питание котла, когда температура воды выше 85 °C. |
R22 - Перечисление
Следует перечислять наборы требований явно вместо использования обобщающих фраз для группировки набора требований.
Неправильно | Правильно |
Приложение должно поддерживать форматы файлов PDF, DOCX, XLSX и PPTX, а также TXT и CSV. | Приложение должно поддерживать форматы документов: · Текстовые: PDF, DOCX, TXT · Табличные: XLSX, CSV · Презентации: PPTX |
R23 - Дополнение диаграммами, моделями
Если в требовании необходимо описать сложное поведение, следует ссылаться на диаграмму или модель.
Пример: «Система должна обеспечивать определенную последовательность согласования заявки (см. Приложение А, рис. А1).»
Характеристика Полнота (completeness).
В ISO/IEC/IEEE 29148:2018 является одной из ключевых характеристик качественного требования и всего набора требований. Обеспечивает возможность охватывать все аспекты системы, быть понятным без обращения к внешним источникам, допустимость его реализовать, проверить и проследить.
Правила применения характеристики Полнота:
R24 - Местоимения
Следует избегать использования личных и неопределенных местоимений, так как это вносит неопределенность.
Плохой пример: «Система должна выводить пользователю сообщение о подтверждении в среднем за 3 секунды и не более чем через 6 секунд после того, как он отослал информацию ей.»
R25 - Заголовки
Не следует полагать, что заголовок — это часть требования. Требование должно быть самодостаточным и без заголовка.
Пример заголовка: «3.1. Требования к аварийному сигналу тревоги»:
Неправильно | Правильно |
Эта система должна звучать не более 20 минут | Система должна подавать аварийный сигнал тревоги не более 20 минут. |
Характеристика Реалистичность (realism).
В ISO/IEC/IEEE 29148:2018 относится к критерию качества требований, который гарантирует, что каждое требование может быть выполнено в рамках доступных ресурсов, технологий, бюджета, сроков и ограничений проекта.
Правила применения характеристики Реалистичность:
R26 - Абсолютные значения
Следует избегать использования недостижимых абсолютных значений, таких как 100% надежность, 100% доступность, все, каждый, всегда, никогда и т.д..
Неправильно | Правильно |
Система должна обладать стопроцентной доступностью. | Система должна быть доступна 98% времени между 5:00 и полуночью по местному времени и 90% времени между полуночью и 5:00 по местному времени, за исключением времени планового обслуживания. |
Характеристика Условия (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).
