Лекция 6. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

Требование - это условие, которому должно удовлетворять программное обеспечение, или свойство, которым оно должно обладать, чтобы:

• удовлетворить потребность пользователя в решении некоторой задачи;
• удовлетворить требования контракта, спецификации или стандарта.

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

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

Методы выявления требований:

• собеседование (интервьюирование);
• анкетирование;
• проведение совещаний;
• сессии по выявлению требований (мозговой штурм);
• раскадровка (storyboard);
• создание и демонстрация работающих прототипов;
• ролевые игры.

В ходе проекта работа с требованиями делится на следующие этапы:

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

Любое требование в базе проекта имеет следующие атрибуты:

• Приоритет (высокий, средний, низкий).
• Статус (предложено, одобрено, реализовано, верифицировано).
• Стоимость реализации (высокая, средняя, низкая - или числовое значение).
• Сложность реализации (высокая, средняя, низкая).
• Стабильность (высокая, средняя, низкая).
• Ответственный исполнитель.

Хороший набор требований удовлетворяет следующим показателям качества (IEEE 830-1998 «Recommended Practice for Software Requirements Specifications»):

• Корректность или адекватность (соответствие реальным потребностям).
• Недвусмысленность (однозначность понимания).
• Полнота (отражение всех выделенных потребностей и всех возможных ситуаций, в которых придется работать системе).
• Непротиворечивость (согласованность между различными элементами).
• Упорядоченность по приоритету и стабильности.
• Проверяемость (выполнение каждого требования нужно должно проверяться достаточно эффективным способом - непроверяемые требования должны быть удалены из рассмотрения или сведены к проверяемым вариантам).
• Модифицируемость (оформление в удобных для внесения изменений структуре и стилях).
• Прослеживаемость в ходе разработки (возможность увязать требование с подсистемами, модулями и операциями, ответственными за его выполнение, и с тестами, проверяющими его выполнение).

Выявленные требования к ПО оформляются в виде ряда документов и моделей. К основным документам, регламентируемым технологией Rational Unified Process, относятся:

• Концепция - определяет глобальные цели проекта и основные особенности разрабатываемой системы. Существенной частью концепции является постановка задачи разработки, определяющая требования к выполняемым системой функциям.
• Словарь предметной области (глоссарий) - определяет общую терминологию для всех моделей и описаний требований к системе. Глоссарий предназначен для описания терминологии предметной области и может быть использован как словарь данных системы.
• Дополнительная спецификация (технические требования) - содержит описание нефункциональных требований к системе, таких, как надежность, удобство использования, производительность, сопровождаемость и др.

Функциональные требования к системе моделируются и документируются с помощью вариантов использования (use case). Вариант использования (use case) - связный элемент функциональности, предоставляемый системой при взаимодействии с действующими лицами. Действующее лицо (actor) - роль, обобщение элементов внешнего окружения системы, ведущих себя по отношению к системе одинаковым образом.

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

Варианты использования - это вид документации, применяемый, когда требуется сконцентрировать усилия на обсуждении принципиальных функциональных требований к разрабатываемой системе, а не на подробном их описании. Стиль их написания зависит от масштаба, количества участников и критичности проекта. Формат описания варианта использования (по Коберну):

• Имя - цель в виде краткой активной глагольной фразы
• Контекст использования - более длинное описание цели
• Область действия (которая может быть одной из списка:
• предприятие как «черный ящик»;
• предприятие как «белый ящик»;
• система как «черный ящик» (в рамках нашего курса рассматриваются описания вариантов использования только с этой областью действия);
• система как «белый ящик»;
• подсистема как «белый ящик»)
• Основное действующее лицо
• Участники и интересы
• Предусловие (определяет, выполнение какого условия гарантирует система перед тем, как разрешить запуск варианта использования)
• Минимальные гарантии (наименьшие обещания системы участникам в случае, когда цель основного действующего лица не может быть достигнута)
• Гарантии успеха (что гарантирует система при успешном завершении варианта использования)

Гарантии успеха, объединенные с минимальными гарантиями, образуют постусловия варианта использования.

• Триггер (событие, которое запускает вариант использования)
• Основной сценарий (простой для понимания типичный сценарий, в котором достигается цель основного действующего лица и удовлетворяются интересы всех участников)
• Расширения или остальные сценарии (запускаются при возникновении определенного условия, содержат последовательность шагов, описывающих, что происходит при этом условии, и заканчивается достижением цели или отказом от неё)
• Список изменений в технологии и данных
• Вспомогательная информация

Существуют четыре уровня точности описания вариантов использования, расположенные по степени повышения точности:

• Действующие лица и цели (перечисляются действующие лица и все их цели, которые будет обеспечивать система). На этом уровне определяется границы системы, контекст в котором она работает. Действующее лицо может: быть активным, посылая запросы в систему; быть пассивным, получая данные от системы. Его роль может исполнять человек - пользователь, устройство, внешняя программная система, время (в случае если функциональность запускается по расписанию), температура или другое свойство состояния окружающей среды, играющее роль триггера.
• Краткое изложение варианта использования (в один абзац) или основной поток событий (без анализа возможных ошибок).
• Условия отказа (анализ мест возникновения возможных ошибок в основном потоке событий, т. е. составление перечня альтернативных потоков). Виды альтернативных потоков:
• Некорректное действие действующего лица (ввод неверного пароля).
• Бездействие основного действующего лица (истечение времени ожидания пароля).
• Предложение "система подтверждает" связано с обработкой неподтверждения (неверный учётный номер).
• Несоответствующая реакция второстепенного действующего лица или её отсутствие (истечение времени ожидания ответа).
• Внутренняя ошибка в разрабатываемой системе, которая должна быть обнаружена и обработана в обычном порядке (заблокирован автомат для выдачи наличных).
• Неожиданная и необычная ошибка, которую необходимо обработать (обнаружено повреждение журнала транзакций).
• Критически важные недостатки в производительности системы (время реакции не укладывается в 5 секунд).
• Обработка отказа (написание содержания альтернативных потоков, т. е. развернутого описания взаимодействия системы и действующего лица в каждом случае отказа).

Введение перечисленных уровней преследует своей целью грамотное планирование и экономию времени разработки. В итерационном цикле создания системы не следует пытаться за один прием подробно описать все требования, их нужно постепенно уточнять, повышая уровень точности. Выбор первоочередных вариантов использования для уточнения определяется их приоритетами. Факторами ранжирования вариантов использования (и вообще всех требований) по приоритетам являются:

• существенное влияние на архитектуру системы;

• рискованные, сложные для реализации или срочные функции;

• применение новой, неапробированной технологии;

• значимость в экономических процессах.

Потоки событий вариантов использования представляют собой перенумерованные наборы шагов. Используются шаги трёх типов: действие системы (например, «Система запрашивает имя пользователя и пароль»); реакция действующего лица («Пользователь вводит имя и пароль»); управление потоком («Выполнение переходит на начало основного потока«). Структура предложений, описывающих шаги, одинакова: подлежащее, сказуемое, остальные части речи. От неё отходят лишь при описании циклов и ветвлений. Цикл задается составным описанием, в начале которого указывается условие цикла («Для каждого ... выполняется») или количество повторений. Далее следует тело цикла -- последовательность вложенных шагов (см. шаг 4 основного потока варианта использования «Ввести заказ»). Ветвление в тривиальных случаях, когда альтернативная ветвь пуста, допускается описывать предложением с союзом если («...»). Чаще ветвление описывают с помощью альтернативных потоков. В основном потоке варианта использования «Ввести заказ» 9-ый шаг указывает основное продолжение потока, а альтернативный поток «9А. Бухгалтерская система временно недоступна» содержит второй вариант развития событий. Как правило, действия по проверке условия ветвления не описывают. Вместо этого указывается шаг, на котором система (или действующее лицо) подтверждает, что условие выполнено, в основном потоке, или обнаруживает, что условие нарушено, в альтернативном потоке.

Пример описания варианта использования (в нем приводятся не все рекомендованные Коберном пункты, область действия описания - система как «черный ящик»):

Вариант использования «Ввести заказ»

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

Основной поток событий

1. Продавец обращается к системе, чтобы ввести новый заказ.

2. Система запрашивает данные о заказе.

3. Продавец вводит данные о заказчике и дате поставки заказа.

4. Для каждой позиции нового заказа выполняется:

4.1. Продавец вводит наименование и количество.

4.2. Система подтверждает, что наименование и количество указаны верно.

5. Продавец сообщает системе о необходимости сохранить заказ.

6. Система сохраняет данные о заказе.

7. Система запрашивает сеанс связи с бухгалтерской системой.

9. Бухгалтерская система подтверждает готовность к приёму данных о заказе.

10. Система передает данные о заказе и завершает сеанс.

11. Бухгалтерская система подтверждает получение данных о заказе.

Альтернативные потоки

4.2А. Ошибка при вводе позиции заказа

1. Система обнаруживает, что наименование предмета мебели либо количество указаны неверно.

2. Система выдает сообщение об ошибке.

3. Управление передается на шаг 4 основного потока.

9А. Бухгалтерская система временно недоступна

9А.1. Система обнаруживает, что невозможно установить связь с бухгалтерской системой.

9А.2. Система подтверждает, что количество выполненных попыток связаться с бухгалтерской системой меньше установленного предела.

9А.3. Система ожидает некоторое установленное время.

9А.4. Выполнение передается на шаг 7 основного потока.

9А.2A. Бухгалтерская система постоянно недоступна

9А.2A.1. Система обнаруживает, что исчерпан лимит попыток для установки связи с бухгалтерской системой.

9А.2A.2. Система удаляет сохранённые сведения о заказе.

9А.2A.3. Система выдает сообщение об ошибке.

Предусловия:Перед началом выполнения данного варианта использования продавец должен войти в систему.

Постусловия: Если вариант использования завершится успешно, данные о заказе будут внесены в систему обработки заказов и переданы в бухгалтерскую систему. В противном случае система данные о заказе не сохраняет и выдаёт сообщение об ошибке.

При определении требований к системе рекомендуется рассматривать систему как «черный ящик». Следует придерживаться правил:

• Ясно укажите, кто «владеет мячом». На каждом шаге одно из действующих лиц "владеет мячом" - сообщением и данными, которые одно действующее лицо передаёт другому.
• Пишите, глядя на вариант использования с точки зрения пользователя, а не системы.
• Не показывайте слишком незначительные, мелкие действия.
• Постусловия варианта использования всегда не пусты.
• Избегайте типичных ошибок в сценариях:

• Отсутствует система.
• Отсутствует основное действующее лицо.
• Слишком много деталей пользовательского интерфейса.
• Слишком низкий (подробный) уровень описания.

Связи коммуникации (ассоциации) между вариантами использования и действующими лицами отображаются на диаграмме вариантов использования:

• Каждый вариант использования должен быть инициирован действующим лицом. От этого лица к нему должна идти ассоциация. Ассоциация от действующего лица к варианту использования должна быть одна.
• Не моделируйте ассоциации между действующими лицами.
• Не соединяйте ассоциацией два варианта использования непосредственно. Диаграммы описывают только, какие варианты использования доступны системе, а не порядок их выполнения. На диаграммах варианты использования могут быть связаны либо зависимостями (связями включения или расширения) или обобщением (наследованием). Для отображения порядка выполнения вариантов использования применяют диаграммы деятельности.
• Избегайте многочисленных и запутанных связей между действующими лицами и вариантами использования.

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

Инструментом структуризации также является обобщение вариантов использования.

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

Методика моделирования вариантов использования в технологии Rational Unified Process предусматривает специальное соглашение, связанное с группировкой структурных элементов и диаграмм модели. Это соглашение включает следующие правила:

• Все действующие лица, варианты использования и диаграммы вариантов использования помещаются в пакет с именем Use Case Model.

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

• структуризации модели в соответствии с типами пользователей (действующих лиц);
• функциональная декомпозиция;
• разделение модели на пакеты между группами разработчиков (в качестве объектов управления конфигурацией).

Дисциплина определения требований в рамках RUP описывается следующим набором ролей и деятельностей:

Наборы рабочих продуктов определения требований:

Спецификация требований в технологии Rational Unified Process не требует обязательного моделирования бизнес-процессов организации, для которых создается ПО, однако, наличие бизнес-моделей существенно упрощает построение системной модели вариантов использования. При переходе от бизнес-модели к начальной версии модели вариантов использования применяются следующие правила:

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

• Варианты использования для данного действующего лица создаются на основе анализа обязанностей соответствующего исполнителя (в простейшем случае для каждой операции исполнителя создается вариант использования, реализующий данную операцию в системе).

Для описания функциональных требований используются диаграммы деятельности:

• для описания потоков событий одного варианта использования;
• для описания потоков событий нескольких взаимосвязанных вариантов использования.

Обратите внимание на области ответственности. Деятельности, приписанные узлам действия, выполняет либо система, либо действующее лицо в зависимости от того, в какой области находится узел.

Модель вариантов использования можно считать завершенной, если есть утвердительные ответы на следующие вопросы:

• Можно ли на основании модели сформировать четкое представление о функциях системы и их взаимосвязях?
• Присутствует ли каждое функциональное требование хотя бы в одном варианте использования? Если требование не нашло отражение в варианте использования, оно не будет реализовано.
• Учли ли вы, как с системой будет работать каждое заинтересованное лицо?
• Какую информацию каждое заинтересованное лицо будет передавать системе?
• Учли ли вы все внешние системы, с которыми будет взаимодействовать данная?