Что такое требования в контексте разработки ПО
Разработка требований (Requirements engineering, RE) — процесс определения функций, которые заказчик требует от системы, и ограничений. Требования — это описания функций и ограничений, которые формируются в процессе написания требований. Требования могут быть разным уровнем детализации: от высокоуровневого абстрактного описания сложного сервиса и до подробного математического описания функций.
Требования должны, насколько это возможно, описывать, что должна делать система, но не то, как она должна это делать.
Существует два вида требований по назначению и целевой аудитории:
Требования пользователя
Или пользовательские требования — высокоуровневые абстрактные требования, написанные на обычном языке (не языке программирования), снабженные схематическими рисунками-диаграммами, которые описывают, какие функции система должна предоставлять пользователю, и ограничения, с которыми она может работать.
Системные требования
Подробное описание того, что должна делать система, включая функции и эксплуатационные ограничения программной системы. Документ системных требований (также называемый функциональной спецификацией) должен точно определять, что должно быть реализовано. Он может быть частью юридического соглашения между покупателем системы и компанией-разработчиком программного решения.
Помимо деления по назначению, можно также выделить такие три класса требований:
Функциональные требования
Указывают, какие функции должна предоставлять система, как система должна реагировать на определенные входные данные, и как система должна вести себя в определенных ситуациях. Могут также указывать, что система не должна делать.
Нефункциональные требования
Ограничения на услуги или функции системы, такие как временнЫе ограничения, ограничения на процесс разработки, отраслевые или общепринятые стандарты и т. д. Часто относятся к системе в целом, а не к отдельным функциям или услугам.
Доменные требования
Ограничения к системе, возникающие при ее эксплуатации.
Функциональные требования
Как упоминалось выше, функциональные требования описывают функциональность системы. Они зависят от типа ПО, предполагаемых пользователей, и типа системы, в которой будет работать программное обеспечение.
- Функциональные требования пользователей могут быть высокоуровневым описанием о том, что должна делать система.
- Функциональные системные требования должны детально описывать системные функции.
Проблемы чаще всего возникают, когда требования сформулированы неточно. Двусмысленные, неточные, неполные требования могут быть по-разному интерпретированы разработчиками и пользователями. В принципе, требования должны быть как:
- полными (должны включать описания всех требуемых объектов), так и
- последовательными (в описаниях объектов системы не должно быть конфликтов или противоречий).
Но на практике невозможно создать идеально полный и последовательный документ требований.
Нефункциональные требования
Нефункциональные требования определяют свойства и ограничения системы, например: надежность, время отклика и требования к надежности хранения данных. Ограничениями являются, например, возможности устройств ввода/вывода, обрабатывающих устройств и сети и т. д. Также могут быть прописаны требования к процессам разработки, предписывающие использование определенной IDE, языка программирования или методов разработки. Нефункциональные требования могут быть иногда даже более важными, чем функциональные. Если они не будут исполнены, система может оказаться по факту бесполезной. Нефункциональные требования могут влиять глобально на общую архитектуру системы, а не только отдельные компоненты. Нефункциональное требование, например, к безопасности, может породить ряд связанных с ним функциональных требований, определяющих необходимые системные сервисы; оно также может порождать новые требования, которые влияют на существующие требования.
Три класса нефункциональных требований:
Требования к продукту
Требования, которые определяют, что поставляемый продукт должен вести себя определенным образом, например, точность выполнения, надежность и т.д.
Организационные требования
Требования, которые являются следствием политик и процедур организации, например, используемые стандарты процессов, требования к реализации и т.д.
Внешние требования
Требования, которые возникают из-за факторов, внешних по отношению к системе и процессу ее разработки, например, требования совместимости, законодательные требования и т.д.
Нефункциональные требования может быть очень сложно сформулировать точно, а неточные требования может быть сложно проверить. Если они сформулированы как цель (общее намерение пользователя, например, простота использования), их следует переписать как верифицируемое нефункциональное требование (утверждение с использованием некоторой количественной метрики, которая может быть объективно проверена). Цели полезны для разработчиков, поскольку они передают намерения пользователей.
Доменные требования
Домен (операционная область системы) накладывает требования на систему. Требования к домену могут быть новыми функциональными или нефункциональными требованиями, ограничениями на существующие требования или определять конкретные действия. Если доменные требования не выполнены, система может оказаться неработоспособной. Две основные проблемы с доменными требованиями:
Понятность
Требования выражаются на языке прикладной области, который не всегда понятен программистам, разрабатывающим систему.
Неявность
Специалисты домена настолько хорошо понимают область, что им не приходит в голову сформулировать доменные требования явным образом.
Процесс разработки требований
Процессы сильно различаются в зависимости от домена, вовлеченных людей и организации, разрабатывающей требования. На практике разработка требований представляет собой итеративный процесс, в котором чередуются следующие общие виды деятельности:
- Выяснение требований;
- Анализ требований;
- Валидация требований;
- Управление требованиями.
Выяснение и анализ требований
Команда работает со стейкхолдерами, получая информацию о домене, услугах, которые должна предоставлять система, требуемой производительности системы, аппаратных ограничениях, связанных системах и т. д. Этапы:
Выявление требований
Взаимодействие со стейкхолдерами для выявления их требований. На этом этапе также выявляются доменные требования.
Группировка и упорядочивание требований
Группировка связанных требований в кластеры.
Расстановка приоритетов и переговоры
Расстановка приоритетов требований и разрешение конфликтов между ними.
Спецификация требований
Требования документируются и переводятся на следующий этап.
Закрытые (то есть на основе заранее определенного списка вопросов) и открытые интервью со стейкхолдерами являются важной частью процесса управления требованиями. Пользовательские истории и сценарии — это примеры использования системы, которые легко понять стейкхолдерам. Сценарии должны включать описание исходной ситуации, стандартного хода событий, что может пойти не так, других параллельных действий, состояния системы по завершении сценария. Use-cases, или сценарии использования — это основанная на сценариях техника UML, которая описывает участников взаимодействия и само взаимодействие. Набор сценариев использования должен описывать все возможные взаимодействия с системой.
Проблемы, на которые следует обратить внимание в процессе выявления и анализа требований:
- Стейкхолдеры не знают, чего они хотят
- Стейкхолдеры выражают требования в своих собственных терминах
- Различные стейкхолдеры могут создавать противоречивые требования
- Организационные и политические факторы могут повлиять на требования к системе
- Требования меняются в процессе анализа
- Могут появиться новые заинтересованные стороны и измениться бизнес-среда.
Спецификация требований
Спецификация требований — это процесс записи пользовательских и системных требований в документе требований. Пользовательские требования должны быть понятны конечным пользователям и заказчикам, не имеющим технического образования. Системные требования — это более подробные требования, которые могут содержать больше технической информации. Требования могут быть частью контракта на разработку системы, и важно, чтобы они были как можно более полными.
В принципе, требования должны определять, что должна делать система, а дизайн должен описывать, как она это делает. На практике требования и дизайн неразделимы.
Требования пользователя почти всегда пишутся на естественном языке, дополняясь соответствующими диаграммами и таблицами в документе требований. Системные требования также могут быть написаны на естественном языке, но могут использоваться и другие обозначения, основанные на формах, графических моделях систем или математических моделях систем. Естественный язык выразителен, интуитивно понятен и универсален. Это означает, что требования могут быть понятны пользователям и заказчикам.
Структурированный естественный язык — это способ написания требований к системе, при котором свобода составителя требований ограничена, а все требования написаны стандартным образом. Этот подход сохраняет большую часть выразительности и понятности естественного языка, но обеспечивает определенное единообразие спецификации.
Валидация требований
Валидация требований призвана продемонстрировать, что требования описывают систему, которая действительно нужна заказчику. Стоимость ошибки в требованиях высока, поэтому проверка очень важна.
Какие проблемы следует искать:
- Валидность: обеспечивает ли система функции, которые наилучшим образом соответствуют потребностям заказчика?
- Согласованность: есть ли конфликты в требованиях?
- Полнота: включены ли все функции, нужные заказчику?
- Реалистичность: можно ли реализовать требования с учетом имеющегося бюджета и технологий?
- Проверяемость: можно ли проверить требования?
Методы валидации требований:
Анализ требований
Систематический ручной анализ требований — в процессе формулирования требований должны проводиться регулярные аналитические обзоры (review). На что следует обратить внимание:
- Проверяемость: является ли требование реально проверяемым (верифицируемым)?
- Понятность: правильно ли понято требование?
- Прослеживаемость: четко ли указано происхождение требования?
- Адаптивность: можно ли изменить требование без значительного влияния на другие требования?
Прототипирование
Создание модели системы для проверки требований.
Генерация тест-кейсов
Разработка тестов для требований.
Изменение требований
Управление требованиями — это процесс управления изменяющимися требованиями в ходе процесса разработки требований и развития системы. Новые требования появляются как в процессе разработки системы, так и после ее ввода в эксплуатацию. Причины, по которым требования меняются после развертывания системы:
- Бизнес и техническая среда системы всегда меняются после установки
- Люди, которые платят за систему, и пользователи этой системы редко бывают одними и теми же людьми
- Крупные системы обычно имеют разнообразное сообщество пользователей, причем многие пользователи имеют различные требования и приоритеты, которые могут быть противоречивыми или несовместимыми.
Управление требованиями — лекция CCSU.edu
