5.2. Процесс разработки требований

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

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

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

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

Различают четыре основных этапа процесса разработки требований:

1. анализ технической осуществимости создания системы;

2. формирование и анализ требований;

3. специфицирование требований и создание соответствующей документации;

4. аттестация требований.

На рис. 5.1 показаны взаимосвязи между этими этапами и докумен­ты, сопровождающие каждый этап процесса разработки системных требований.

Рис. 5.1. Процесс разработки требований

5.3. Составляющие потока анализа требований.

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

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

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

Для обозначения термина «анализ требований» в англоязычной литературе, как правило, используется понятие «Requirement Process». В отечественной практике, наряду с обобщающим термином «анализ требований», принятым, в частности, в ГОСТ Р ИСО/МЭК 12207-99, встречаются также такие термины, как «поток работ «требования», «работа с требованиями», «определение требований» и т.д., что вносит изрядную путаницу. Для того, чтобы внести некоторую ясность, рассмотрим декомпозицию рабочего потока Requirement Process на составляющие, принятую в SWEBOK. SWEBOK предлагает выделить в Requirement Process следующие основные составляющие:

 Requirements Elicitation (Извлечение требований),

 Requirements Analysis (Анализ требований в узком смысле),

 Requirements Specification (Специфицирование требований),

 Requirements Validation (Проверка требований).

В качестве примера альтернативной декомпозиции потока работ можно рассмотреть взгляд, предложенный в RUP (Rational Unified Process) — методология разработки программного обеспечения, созданная компанией Rational Software. RUP предлагает выделить в основном потоке анализа требований такие компоненты, как:

 Analyze the Problem (Анализ проблемы),

 Understand Stakeholder Needs (Понимание потребностей совладельцев),

 Define the System (Определение системы),

 Manage the Scope of the System (Управление контекстом системы),

 Refine the System Definition (Уточнение определения системы).

Обобщая указанные выше декомпозиции далее будем придерживаться следующей, более удобной в методическом плане схемой декомпозиции потока работ «Работа с требованиями»:

 Формирование видения;

 Выявление требований;

 Классификация и спецификация требований;

 Расширенный анализ требований (моделирование и прототипирование);

 Документирование требований;

 Проверка требований;

 Управление требованиями;

 Совершенствование процесса работы с требованиями.

• Результатами анализа и разработки требований могут быть:

• Техническое задание;

• Технические требования;

• Общие технические решения;

• Задание на проектирование;

• Подготовка конкурсной документации.