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

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

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

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

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

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

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

• требования к реализации, которые предписывают использовать определенные стандарты, языки программирования, операционную среду и др.;

• требования к надежности, которые определяют допустимую частоту и воздействие сбоев, а также возможности восстановления;

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

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

• собеседование (интервьюирование);

• анкетирование;

• проведение совещаний;

• сессии по выявлению требований (мозговой штурм);

• раскадровка (storyboard);

• создание и демонстрация работающих прототипов;

• ролевые игры.

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

• Определение типов требований и групп участников проекта, работающих с ними.

• Первичный сбор требований, их классификация и занесение в базу данных требований.

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

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

• Приоритет (высокий, средний, низкий).

• Статус (предложено, одобрено, реализовано, верифицировано).

• Стоимость реализации (высокая, средняя, низкая – или числовое значение).

• Сложность реализации (высокая, средняя, низкая).

• Стабильность (высокая, средняя, низкая).

• Ответственный исполнитель.

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

• Корректность или адекватность (соответствие реальным потребностям).

• Недвусмысленность (однозначность понимания).

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

• Непротиворечивость (согласованность между различными элементами).

• Упорядоченность по приоритету и стабильности.

• Проверяемость (выполнение каждого требования нужно должно проверяться достаточно эффективным способом – непроверяемые требования должны быть удалены из рассмотрения или сведены к проверяемым вариантам).

• Модифицируемость (оформление в удобных для внесения изменений структуре и стилях).

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

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

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

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

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

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

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

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

• Имя – цель в виде краткой активной глагольной фразы

• Контекст использования – более длинное описание цели

• Область действия

• Основное действующее лицо

• Участники и интересы

• Предусловие (определяет, выполнение какого условия гарантирует система перед тем, как разрешить запуск варианта использования)

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

• Гарантии успеха (или постусловие – postcondition – устанавливает, что интересы участников удовлетворяются по успешном завершении варианта использования в конце основного сценария)

• Триггер (событие, которое запускает вариант использования)

• Основной сценарий (простой для понимания типичный сценарий, в котором достигается цель основного действующего лица и удовлетворяются интересы всех участников)

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

• Список изменений в технологии и данных

• Вспомогательная информация

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

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

• Краткое изложение варианта использования (в один абзац) или основной поток событий (без анализа возможных ошибок).

• Условия отказа (анализ мест возникновения возможных ошибок в основном потоке событий).

• Обработка отказа (написание всех альтернативных потоков событий).

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

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

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

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

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

Правила написания сценариев:

1. Используйте простые предложения:.

2. Ясно укажите, кто «владеет мячом».

3. Пишите, глядя на вариант использования с точки зрения пользователя, а не системы.

4. Не показывайте слишком незначительные, мелкие действия.

Виды альтернативных сценариев:

• Некорректное действие действующего лица.

• Бездействие основного действующего лица .

• Предложение "система подтверждает" связано с обработкой неподтверждения.

• Несоответствующая реакция второстепенного действующего лица или её отсутствие.

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

• Неожиданная и необычная ошибка, которую необходимо обработать.

• Критически важные недостатки в производительности системы.

Типичные ошибки в сценариях:

• Отсутствует система.

• Отсутствует основное действующее лицо.

• Слишком много деталей пользовательского интерфейса.

• Слишком низкий (подробный) уровень описания.

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

Правила составления этих диаграмм:

1. Каждый вариант использования должен быть инициирован действующим лицом.

2. Не моделируйте связи коммуникации между действующими лицами.

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

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

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

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

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

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

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

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

• структуризации модели в соответствии с типами пользователей (действующих лиц);

• функциональная декомпозиция;

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

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