- •Анализ требований
- •1. Введение
- •1.1. Цель
- •1.2. Область применения
- •1.3. Определения, термины и сокращения
- •1.4. Ссылки
- •2. Общее описание
- •2.1. Перспективы продукта
- •2.1.1. Концепции операций
- •2.1.2. Концепции пользовательского интерфейса
- •2.1.2.1. Концепция зоны в пользовательском интерфейсе
- •2.1.2.2. Концепция пользовательского интерфейса для установки значений характеристик
- •2.2.2. Вариант использования «Перейти в соседнюю зону»
- •2.2.3. Вариант использования «Встретить внешний персонаж»
Анализ требований
Получение корректных требований — сложный процесс. Он состоит из чуткого взаимодействия с теми, кто финансово заинтересован в успехе данного программного приложения.
Рис. 1. Схема разработки программ
Значение анализа требований
Чтобы построить что-либо, мы, прежде всего, должны понять, чем это должно быть. Процесс понимания и документирования этого и называется анализом требований. Обычно требования выражают, что приложение должно делать: зачастую здесь не пытаются сформулировать, как добиться выполнения этих функций.
Результатом анализа требований является документ, который обычно называют спецификацией требований, или спецификацией требований к программному обеспечению (SRS — Software Requirements Specification).
С-требования и D-требования
В течение некоторого времени проходили дебаты относительно того, кому «принадлежат» требования: заказчику или разработчикам (например, [10]). Для решения этого вопроса мы разделяем анализ требований на два уровня. Первый уровень документирует желания и потребности заказчика и пишется на языке, понятном заказчику. Результаты иногда называют требованиями заказчика, или С-требованиями. Первичной аудиторией для С-требований будет сообщество заказчиков, а уже вторичной — сообщество разработчиков. Второй уровень документирует требования в специальной, структурированной форме. Эти документы называются требованиями разработчика, или D-требованиями. Первичной аудиторией для D-требований будет сообщество разработчиков, а уже вторичной — сообщество заказчиков.
Для документирования требований используется стандарт IEEE. Разница между С- и D-требованиями согласно основным идеям шаблона документа стандарта IEEE проиллюстрирована на рис. 3.2.
Рис. 2. Сравнение требований заказчика с детальными требованиями
Хотя целевые аудитории для С- и D-требований различны, заказчики и разработчики тесно сотрудничают при создании успешных продуктов. Один из способов, позволяющих обеспечить хорошее взаимодействие, — совместная работа представителей заказчика и разработчиков.
Типичная схема процесса анализа С-требований, описанного в этой главе, представлена на рис. 3.3. На каждой итерации мы будем заново смотреть на эту схему. На последнем шаге схемы предусматривается сбор детальных D-требований — процесс, описанный в следующей главе. Команда проводит измерения по стадиям процесса, чтобы дать возможность оценить будущие итерации и будущие приложения.
Существует несколько способов организации SRS. Мы будем использовать — и модифицировать — стандарт IEEE 830-1993, оглавление которого приведено ниже.
1. Введение
Цель
Область применения
Определения, термины и сокращения
Ссылки
Обзор
2. Общее описание
2.1. Перспективы продукта
Системные интерфейсы
Пользовательские интерфейсы
Аппаратные интерфейсы
Программные интерфейсы
Коммуникационные интерфейсы
Ограничения по памяти
Операции
Требования по адаптации
Функции продукта
Пользовательские характеристики
Ограничения
Предположения и зависимости
Распределение требований
Конкретные требования
Сопровождающая информация
Анализ требований — это необходимость, а не роскошь. Важным выигрышем от анализа требований является достижение понимания и согласия относительно приложения, которое вы собираетесь создать. Это базис контрактов любого вида.
Описание С-требований (требований заказчика)
Заказчики разрабатывают концепцию — часто подсознательную и неполную — того, как их приложение будет работать. Эту концепцию иногда называют моделью приложения, или концепцией работы. Разные люди обычно имеют различные представления о программном продукте.
Менеджер проекта или разработчик требований помогает заказчику четко сформулировать его концепцию работы. Поскольку обычно заказчики не владеют технологией выражения таких концепций, инженеры могут предложить подходящие технологии, такие как варианты использования, потоки данных или переходы состояний.
Варианты использования, концепция, которую изобрел Якобсон, является очень полезным способом выражения требований заказчика в форме таких взаимодействий. Вариант использования определяется, прежде всего, своим именем и типом пользователя приложения, называемого действующим лицом. Вариант использования состоит из типичного взаимодействия между действующим лицом и приложением.
Некоторые требования естественно описаны потоками данных между обрабатывающими элементами. В диаграмме потоков данных узлы, отмеченные кругами или прямоугольниками, представляют обрабатывающие единицы. Стрелки между ними, подписанные типами данных, обозначают потоки данных. Хранилища данных — места, где хранятся данные, такие как базы данных — отмечены горизонтальными линиями с именем хранилища между ними. Внешние объекты, такие как пользователь и принтеры, представлены прямоугольниками.
Диаграммы переходов состояний. Иногда приложение или его часть лучше всего представлять себе в одном из нескольких состояний. Состоянием приложения является его статус или ситуация, в которой оно находится. Состояния иногда называют фазами или стадиями. Идея заключается в разбиении приложения на состояния, так чтобы приложение всегда находилось в одном и том же состоянии.
После определения состояний добавляются переходы между ними. Переходы обозначаются стрелками, каждая из которых помечена именем события, приводящего к смене состояния приложения. Иногда, когда объект находится в заданном состоянии, при возникновении события объект может перейти в одно из нескольких состояний в зависимости от условия.
ПРИМЕР
Спецификация требований к программному обеспечению (SRS) для видеоигры Встреча, часть 1