Сложные программные средства имеют различное назначение, содержание и относятся к разным областям применения. Поэтому существует потребность в четко организованном процессе, методах формализации и управления требованиями к конкретным программным продуктам.
Чаще всего проблемами, с которыми встретились не достигшие своих целей проекты программных продуктов, являются: недостаток информации от пользователя или заказчика о функциях проекта, неполные, некорректные требования, а также многочисленные изменения требований и спецификаций. Это происходит потому, что зачастую разработчики и заказчики считают, что «даже если мы не очень точно знаем, чего хотим достичь, лучше быстрее приступить к реализации проекта, так как мы и так выбились из графика и нам некогда размышлять. Мы можем уточнить требования позднее». Подобный подход приводит к хаотическим, неупорядоченным действиям при разработке ПС, когда никто не знает, что на самом деле хочет заказчик и пользователь и как в действительности функционирует созданная на данный момент система и/или программный продукт.
Формализация и управление требованиями— это систематический метод выявления, организации и документирования требований к системе и/или ПС а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющими проект специалистами, в условиях меняющихся требований к системе
Разработка требований — это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований.
Различают четыре основных этапа процесса разработки требований:
1. анализ технической осуществимости создания системы;
2. формирование и анализ требований;
3. специфицирование требований и создание соответствующей документации;
4. аттестация требований.
На рис. 5.1 показаны взаимосвязи между этими этапами и документы, сопровождающие каждый этап процесса разработки системных требований.
Рис. 5.1. Процесс разработки требований
На этапе анализа требований проходит структуризация уже собранных ранее требований. Цель этапа — предоставить четкий список не дублируемых требований к системе, которые должны быть выделены из избыточных и частично дублирующихся сценариев и пользовательских историй, которые были полученных на предыдущем этапе.
Правильно сгруппированные требования помогут обойтись минимальным количеством функционала для удовлетворения максимально большего количества целей, а это, в свою очередь, поможет сэкономить бюджет и не даст расползтись рамкам проекта.
Анализ требований – один из основных рабочих потоков (workflow) программной инженерии, наряду, с такими, как проектирование интерфейса пользователя, либо программирование.
Для обозначения термина «анализ требований» в англоязычной литературе, как правило, используется понятие «Requirement Process». В отечественной практике, наряду с обобщающим термином «анализ требований», принятым, в частности, в ГОСТ Р ИСО/МЭК 12207-99, встречаются также такие термины, как «поток работ «требования», «работа с требованиями», «определение требований» и т.д., что вносит изрядную путаницу. Для того, чтобы внести некоторую ясность, рассмотрим декомпозицию рабочего потока Requirement Process на составляющие, принятую в SWEBOK. SWEBOK предлагает выделить в Requirement Process следующие основные составляющие:
В качестве примера альтернативной декомпозиции потока работ можно рассмотреть взгляд, предложенный в RUP (Rational Unified Process) — методология разработки программного обеспечения, созданная компанией Rational Software. RUP предлагает выделить в основном потоке анализа требований такие компоненты, как:
Manage the Scope of the System (Управление контекстом системы),
Refine the System Definition (Уточнение определения системы).
Обобщая указанные выше декомпозиции далее будем придерживаться следующей, более удобной в методическом плане схемой декомпозиции потока работ «Работа с требованиями»:
Формирование видения;
Выявление требований;
Классификация и спецификация требований;
Расширенный анализ требований (моделирование и прототипирование);
Документирование требований;
Проверка требований;
Управление требованиями;
Совершенствование процесса работы с требованиями.
Результатами анализа и разработки требований могут быть:
