Анализ требований

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

Рис. 1. Схема разработки программ

Значение анализа требований

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

Результатом анализа требований является документ, который обычно назы­вают спецификацией требований, или спецификацией требований к программно­му обеспечению (SRS — Software Requirements Specification).

С-требования и D-требования

В течение некоторого времени проходили дебаты относительно того, кому «при­надлежат» требования: заказчику или разработчикам (например, [10]). Для ре­шения этого вопроса мы разделяем анализ требований на два уровня. Первый уровень документирует желания и потребности заказчика и пишется на языке, понятном заказчику. Результаты иногда называют требованиями заказчи­ка, или С-требованиями. Первичной аудиторией для С-требований будет сообще­ство заказчиков, а уже вторичной — сообщество разработчиков. Второй уровень документирует требования в специальной, структурированной форме. Эти доку­менты называются требованиями разработчика, или D-требованиями. Первич­ной аудиторией для D-требований будет сообщество разработчиков, а уже вто­ричной — сообщество заказчиков.

Для документирования требований используется стандарт IEEE. Разница между С- и D-требованиями согласно основным идеям шаблона доку­мента стандарта IEEE проиллюстрирована на рис. 3.2.

Рис. 2. Сравнение требований заказчика с детальными требованиями

Хотя целевые аудитории для С- и D-требований различны, заказчики и раз­работчики тесно сотрудничают при создании успешных продуктов. Один из спо­собов, позволяющих обеспечить хорошее взаимодействие, — совместная работа представителей заказчика и разработчиков.

Типичная схема процесса анализа С-требований, описанного в этой главе, представ­лена на рис. 3.3. На каждой итерации мы будем заново смотреть на эту схему. На последнем шаге схемы предусматривается сбор детальных D-требований — процесс, описанный в следующей главе. Команда проводит измерения по стадиям процес­са, чтобы дать возможность оценить будущие итерации и будущие приложения.

Существует несколько способов организации SRS. Мы будем использовать — и модифицировать — стандарт IEEE 830-1993, оглавление которого приведено ниже.

1. Введение

1. Цель

2. Область применения

3. Определения, термины и сокращения

4. Ссылки

5. Обзор

2. Общее описание

2.1. Перспективы продукта

1. Системные интерфейсы

2. Пользовательские интерфейсы

3. Аппаратные интерфейсы

4. Программные интерфейсы

5. Коммуникационные интерфейсы

6. Ограничения по памяти

7. Операции

8. Требования по адаптации

2. Функции продукта

3. Пользовательские характеристики

4. Ограничения

5. Предположения и зависимости

6. Распределение требований

3. Конкретные требования

4. Сопровождающая информация

Анализ требований — это необходимость, а не роскошь. Важным выигрышем от анализа требований является достижение понимания и согласия относительно приложения, которое вы собираетесь создать. Это базис контрактов любого вида.

Описание С-требований (требований заказчика)

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

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

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

Некоторые требования естественно описаны потоками данных между обрабаты­вающими элементами. В диаграмме потоков данных узлы, отмеченные кругами или прямоугольниками, представляют обрабатывающие единицы. Стрелки меж­ду ними, подписанные типами данных, обозначают потоки данных. Хранилища данных — места, где хранятся данные, такие как базы данных — отмечены горизон­тальными линиями с именем хранилища между ними. Внешние объекты, такие как пользователь и принтеры, представлены прямоугольниками.

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

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

ПРИМЕР

Спецификация требований к программному обеспечению (SRS) для видеоигры Встреча, часть 1