Лекция 02 (анализ требований)

Технологии разработки
программного обеспечения
Анализ и описание требований к ПО
Основные этапы разработки ПО
1. Выявление и описание требований к ПО.
2. Планирование выполнения проекта
разработки ПО.
3. Анализ решаемой задачи.
4. Проектирование ПО.
– Разработка архитектуры
5. Кодирование и тестирование единиц кода.
6. Системное тестирование.
7. Внедрение разработанного ПО у заказчика.
Выявление и детальное описание
требований к ПО
Понятие «требование»
• В разработке ПО под требованиями к ПО понимается набор
свойств разрабатываемой ПС, которые желает иметь
заказчик, оплачивающий ее разработку.
• В требованиях к системе описывается,
– что система должна делать;
– какие сервисы она должна предоставлять;
– какие ограничения на них наложены.
• Эти требования отражают потребности пользователей к
системе, которая предназначена для выполнения
некоторой цели, такой, как управление устройством,
размещение заказа, поиска информации.
• Процесс выявления, анализа, документирования и
проверки таких сервисов и ограничений называется
разработкой требований (инженерией требований,
requirements engineering, RE).
• Требование можно определить как «подробное описание того, что
должно быть реализовано».
• Существует два основных типа требований:
– функциональные требования – какое поведение должна предлагать система;
– нефункциональные требования – особое свойство или ограничение,
накладываемое на систему.
• Требования указывают, что должно быть построено, но не говорят,
как это сделать.
• Требования – это (по крайней мере, так должно быть) являются основой
для создания любой системы.
• Это, по сути, формулировка того, что должна делать система.
• В принципе требования должны быть только изложением того, что
система должна делать, но не того, как она должна это делать. Это
важное различие.
• Можно определить, что должна делать и какое поведение должна
демонстрировать система, но при этом не обязательно что-либо говорить
о том, как эта функциональность может быть реализована.
Выявление и спецификация требований
• Во всех моделях разработки ПО в той или иной форме
выполняется выявление и описание требований к ПО.
• В гибких подходах к разработке предполагается, что будут
выявлены и документально описаны только
высокоуровневые требования, а детальные требования
будут выявлены в результате взаимодействия с
потребителем.
• Другие подходы предпочитают, чтобы требования были
выявлены и точно описаны заранее.
• В этих случаях целью деятельности по работе с требования
является создание Спецификаций Требований к ПО
(СТПО), которые детально описывают, что должна уметь
делать разрабатываемое ПО.
• Спецификаций Требований к ПО (СТПО) ==
Software Requirements Specification (SRS)
Типы требований к ПО
• Требования к ПО часто делятся на:
– Функциональные
• описание сервисов, которые ПС должна предоставлять,
• как ПС должна реагировать на конкретные введенные
данные,
• как система должна себя вести в конкретных ситуациях;
• в некоторых случаях, в функциональных требованиях также
должно быть явно указано, что система не должна делать.
– Не функциональные требования - ограничения на
сервисы и функции предлагаемые системой:
• временные ограничения;
• ограничения на процесс разработки;
• ограничения налагаемые стандартами.
Нефункциональные требования
• Классификация не функциональных требований
Количественные показатели
№
Свойство
Измеряемый показатель
1
Скорость
Количество обработанных транзакций/секунды
Время ответа на запросы пользователей/события
Время обновления экрана
2
Размер
Мегабайты
Кол-во чипов памяти (ROM)
3
Простота использования
Время подготовки
Кол-во экранов помощи (help frames)
4
Надежность
Среднее время между сбоями
Вероятность недоступности
Скорость возникновения сбоев
Доступность
5
Устойчивость
Время рестарта после сбоя
Процент событий вызывающих сбой.
Вероятность нарушения данных при сбое.
6
Переносимость
Процент операторов, зависящих от новой платформы.
Количество возможных новых платформ.
Пользователи спецификации требований к
ПО
1. Важность хороших СТПО
• Источником большинства ПС являются требования
каких-то заказчиков (которые платят деньги).
• Сама ПС создается некоторыми разработчиками
(которые деньги поучают).
• И, наконец, созданная система будет
использоваться конечными пользователями.
• Т.о. существует 3 основных стороны,
заинтересованные в создании новой ПС:
1. Заказчик
2. Разработчик
3. Пользователи
• Каким-то образом требования к ПС, которые
будут удовлетворять потребностям
заказчиков и заботам пользователей
должны быть переданы разработчикам.
• Между этими участниками проекта
разработки имеется коммуникационный
разрыв (не понимание).
• СТПО является средством (мостом) для
преодоления такого разрыва, т.к. они
являются общим представление
разрабатываемого ПО.
Основные преимущества СТПО
1. СТПО создает основу для соглашения между
заказчиком и поставщиком, о том что
должно делать разрабатываемое ПО.
• Такая основа для соглашения часто формализуется
в юридический контракт между заказчиком
(потребителем) и разработчиком (поставщиком)
(техническое задание).
• С помощью СТПО заказчик явно описывает, что он
ожидает от поставщика, а разработчик явно
понимает, какими возможностями должно
обладать разрабатываемое ПО.
Основные преимущества СТПО (2)
2. СТПО предоставляет руководство для
проверки конечного продукта.
• Т.е. СТПО помогает заказчику определить,
соответствует ли разработанное ПО
согласованным требованиям.
• Без хорошо составленного СТПО:
– для заказчика нет возможности определить,
является ли переданное ПО тем, что было заказано;
– для разработчика нет возможности убедить
заказчика, что все его требования были
удовлетворены.
• СТПО является основой для соглашения и проверки. Это
является сильной причиной, как для заказчика, так и для
разработчиков полно и строго выполнять работу по
пониманию требований и их точному описанию.
• Имеются и другие очень практичные и уважительные
причины иметь хороший СТПО документ.
– Исследования показали, что в ходе работы с требованиями
возникало много ошибок.
– Такие ошибки приводили к ошибкам в конечной ПО, которое
реализовывало СТПО.
– Понятно, если нужен высококачественный продукт, имеющий
немного ошибок, то нужно начинать с высококачественных СТПО.
• Другими словами, можно сделать вывод:
– Высококачественный СТПО документ является обязательным
предварительным условием для высококачественного ПО.
Влияние качества СТПО на стоимость и
сроки проекта
• В описании требований к ПО (СТПО) могут быть
сделаны ошибки.
• С увеличением времени выполнения проекта
стоимость (затраты) на поиск и исправление
ошибок увеличивается почти экспоненциально.
• За счет улучшение качества требований можно
значительно сократить будущие расходы, т.к.
исправления ошибок в СТПО является менее
затратным.
• Вывод: высококачественные СТПО уменьшают
затраты на разработку.
2. Процесс работы с требованиями
• Процесс работы с требованиями является
последовательностью видов деятельности, в
результате которых создается
высококачественный документ, содержащий
СТПО.
• Процесс работы с требованиями обычно
состоит из трех основных задач:
1. анализ проблемы или требований;
2. спецификация (детальное описание) требований;
3. проверка требований.
Процесс работы с требованиями к ПО
• Figure 4.6 The requirements engineering process
Схема процесса работы с требованиями
• Общий процесс работы с требованиям показан ниже
потребности
Анализ
Спецификация
Проверка
1. Анализ проблемы
• Анализ проблемы часто начинается с высокоуровневой
постановки задачи (problem statement).
• В ходе анализа выполняется моделирование ПрО
(предметная область) и проблемной среды, для
понимания поведения системы, ограничений
налагаемых на систему, входных и выходных данных и
т.п.
• Базовой целью данного вида деятельности является
получение полного понимания того, что должно
делать разрабатываемое ПО.
• Часто в ходе анализа, аналитики будут проводят серию
встреч с потребителями и конечными пользователями.
Встречи с заказчиком
• Часто в ходе анализа, аналитики будут проводят серию встреч с
потребителями и конечными пользователями.
1. Ранняя встреча.
1. в ходе данной встречи заказчики и пользователи будут пояснять аналитикам свою
работу, свою среду, свои потребности, как они их ощущают.
– могут быть переданы любые документы описывающие данную работу или ее
организацию совместно с результатами существующих методов выполнения
задач.
– на этой встречи аналитики являются в основном слушателями, впитывающими
предоставляемую им информацию.
2. После того, как аналитик понял в некоторой степени существующую систему,
он организует следующие несколько встреч, для выяснения тех разделов,
которые не до конца понятны .
– он может документировать данную информацию или строить некоторые модели;
– может организовать некоторого вида «мозговой штурм» или обсуждение того,
что создаваемая система должная делать.
3. На финальных встречах аналитик по существу объясняет заказчику:
– как он понял, что должно делать ПО;
– использует данные встречи как средство проверки согласуется ли, то что
предполагаемое ПО должно делать с целями заказчиков.
Выявление требований
Проведение интервью,
собеседований
2. Детальное описание требований
• Понимание полученное в результате анализа проблемы
создает основу для спецификации требований, в
которых основное внимание уделяется точному
детальному описанию требований в виде документа.
• В ходе данного вида работ рассматриваются способы
представления требований, языки и программные
инструмента описания спецификаций.
• Так как в результате анализа создается кол-во
информации и знаний с возможной избыточностью, то
правильная организация и описание требований
является важной целью данного вида деятельности.
3. Проверка требований
• В ходе проверки требований основное
внимание уделяется следующему:
– полноте требований - действительно ли в СТПО
описаны все требования к ПО;
– качеству описания СТПО.
• Процесс выявления требований заканчивается
получением проверенных СТПО.
Спецификация
(детальное описание)
требований
(requirements specification)
3. Спецификация требований
• Окончательным результатом работы с требованиями
является документ спецификации требований к ПО
(СТПО, SRS).
• В ходе анализа выполняется формальное
моделирование решаемой проблемы, но это еще не
СТПО.
• По существу, моделирование является инструментом,
который помогает получить основательные и полные
знания о предлагаемой системе.
• Моделирование является инструментом, который
помогает получить основательные и полные знания о
предлагаемой системе.
• Моделирование обычно фокусирует внимание на
структуре проблемы, а не на ее внешнем поведении.
• Пользовательские интерфейсы редко
моделируются, хотя они часто составляют
крупную часть СТПО.
• Аналогично, для упрощения моделирования,
часто «не существенные вопросы», такие, как
ошибочные состояния (например, ошибки во
входных данных) редко моделируются
правильно, в то время, как в СТПО, поведение в
таких ситуациях также должно быть
специфицировано.
• На основании этого нужно понимать, что
результаты моделирования не могут
формировать желаемые СТПО.
• Переход от результатов анализа к спецификациям
требований не является простым, даже если в ходе
анализа используется формальное моделирование.
• Хорошие СТПО должны специфицировать большой
набор требований, некоторым из которых не уделяется
должного внимания в ходе анализа.
• СТПО составляются на основе знаний, приобретенных в
ходе анализа.
• Т.к. преобразование знаний в структурированный
документ не является простой задачей, то само
составление спецификаций требований является
большой, относительно независимой, задачей.
Желательные характеристики SRS
• Для удовлетворения основным целям, СТПО
должны обладать определенным набором
свойств и содержать определенные типы
требований:
1. правильность:
2. полнота;
3. однозначность;
4. проверяемость;
5. согласованность;
6. ранжированность по важности и/или
стабильности.
Показатели качества требований
• СТПО является правильным (корректным), если
каждое требование, включенное в него, соответствует
чему-то требуемому от финальной ПС.
• СТПО является полным, если в нем описано все, что
разрабатываемое ПО должна делать и то, как оно
должно отвечать на все виды входных данных.
• СТПО является не двусмысленным, если и только если
каждое требование может иметь только одну
интерпретацию (понимание).
• СТПО является проверяемым, если и только если
каждое заявленное требование м.б. проверенным.
– Требование м.б. проверенным, если существует не дорогой
процесс, который может проверить, соответствует ли
финальное ПО данному требованию.
Показатели качества требований (2)
• СТПО является согласованным, если между разными
требованиями нет
– терминологических разногласий (например при ссылке на один и тот
же объект);
– логических и временных конфликтов.
• СТПО является ранжированным по важности, если для каждого
требования указана его важность и стабильность.
– Требования включенные в СТПО не имеют одинаковую важность.
Можно выделить следующие группы требований:
• критически важными,
• важные
• желательные, но не очень важные.
– Стабильность требования отражает вероятность его изменения в
будущем. Оценивается в терминах ожидаемого объема изменений.
• Такое понимание важности каждого требования является
существенно важным для итеративной модели разработки, в
которой выбор требований для очередной итерации основывается
на такой оценке
Полнота требований
• Одной из наиболее важных характеристик СТПО
является полнота требований.
• Данная характеристика также является наиболее
трудной для реализации и проверки.
• Отсутствие каких-то требований в СТПО, приводит
к необходимости добавления и изменения
требований на более поздних шагах разработки,
когда сделать это становится уже очень дорого.
• Не полнота также часто является источником
разногласий между заказчиком и разработчиком.
• Однако некоторые специалисты полагают, что полнота во всех
деталях м.б. и не желательной.
• Стремление достичь полноту требований может привести к тому, что
за понятными деталями станет трудно определить важные
требования.
• Нужно иметь полноту требований, но не опускаться до излишней их
детализации.
• Для разных моделей процесса разработки необходимость полноты и
детальности разная:
– для модели водопада лучше иметь детальную спецификацию, для
минимизации изменений;
– для итеративной модели спецификация м.б. менее детальной, т.к.
имеется обратная связь с заказчиком и возможность изменения по ходу
разработки;
– в гибкой модели разработки полнота рассматривается только для
высокоуровневых требований, а детали могут и не оформляться в
письменной форме, и извлекаться по мере реализации
высокоуровневых требований.
Разделы документа спецификации
требований
• Трудно достичь полноты спецификаций, еще
труднее ее проверить.
• Рекомендации о составе СТПО может помочь
добиться полноты спецификации требований.
• Основными вопросами, на которые отвечают СТПО
являются:
1. функциональные требования;
2. не функциональные требования
– требования к производительности;
– проектные ограничения налагаемые на реализацию;
– требования к внешним интерфейсам.
Функциональные требования
• Функциональные требования определяют
ожидаемое поведение системы – какие выходные
данные и какое поведение должно быть получено
при заданных входных данных.
• Для каждого функционального требования
должно быть детально описаны:
– все входные данные и их источники;
– единицы измерения и интервалы допустимых входных
значений;
– все выполняемые операции над входными данными;
– порядок проверки правильности входных данных;
– описание процесса преобразования входных данных в
выходные данные.
• Важной частью спецификации является
поведение системы в не нормальных
ситуациях.
• Например:
– неверные входные данные;
– ошибки в ходе вычислений.
Не функциональные требования
1. требования к производительности;
2. проектные ограничения налагаемые на
реализацию;
3. требования к внешним интерфейсам.
Требования к производительности
• Требования к производительности являются частью
СТПО и определяют ограничения на работу
создаваемого ПО.
• Типы требований к производительности:
– Статические требования – объемные требования,
такие, как
• кол-во поддерживаемых терминалов;
• кол-во одновременно поддерживаемых пользователей;
• кол-во файлов, которые система должна обрабатывать и их
размеры.
– Динамические требования – определяют ограничения на
ход работы системы:
• время ответа системы – время ожидания завершения операции
при заданных условиях;
• пропускная способность – ожидаемое кол-во операций, которые
м.б. выполнены в единицу времени.
Проектные ограничения
• Проектные ограничения (design constraints) большое кол-во факторов в среде заказчика,
которые могут ограничить выбор
принимаемых решений в ходе выполнения
проектирования.
• К таким факторам относятся:
– ограничение в ресурсах;
– ограничение среды работы ПО;
– требования надежности и безопасности;
– политики, которые могут влиять на
проектирование системы.
Примеры проектных ограничений
1.
2.
3.
4.
Соответствие стандартам.
Ограничения технических средств.
Надежность и устойчивость при ошибках.
Безопасность.
Спецификация внешних интерфейсов
• В разделе «спецификации внешних
интерфейсов» описываются все
взаимодействие ПО с людьми, техническими
устройствами и другим ПО.
• Интерфейс пользователя.
• Требования к интерфейсу с техническими
устройствами.
• Интерфейсы взаимодействия с другими ПС.
Структура СТПО документа
•
•
•
•
Требования должны быть описаны на некотором
языке спецификации требований.
Хотя существуют системы формальных
обозначений для описания специфических
свойств системы, наиболее часто для этого
используется естественный язык.
Формальный язык обычно используется для
описания конкретных свойств или конкретных
частей системы, в качестве части СТПО.
Все описания требований, сделанные на
естественном или формальном языке должны
быть включены в ясный и краткий документ.
Общая структура СТПО документа
• В руководстве IEEE (Институт инженеров
электротехники и электроники) рекомендована
следующая структура спецификаций
требований к ПО:
1. Введение - включает, цель, масштаб и общее
описание документа требований.
– Основным содержанием является пояснение
мотивом и целей бизнеса, которые направляют
данный проект, а также масштаб проекта.
2. Общее описание 3. Детальные требования
Общая структура СТПО документа
• В руководстве IEEE рекомендуется следующая структура
спецификаций требований к ПО:
1. Введение
1.1. Цель
1.2. Масштаб
1.3. Определения, сокращённое имя и аббревиатуры
1.4. Ссылки
1.5. Общий обзор
2. Общее описание
2.1. Представление продукта.
2.2. Функции продукта.
2.3. Характеристики пользователей.
2.4. Общие ограничения.
2.5. Предположения и зависимости.
3. Детальные требования
Пояснение разделов СТПО
• В разделе «Представление продукта» по существу
выполняется описание взаимосвязи данного продукта с
другими продуктами.
– является ли данный продукт независимым или часть более
крупного продукта;
– какие важные интерфейсы данный продукт имеет.
• Далее дается общее описание функций, которые
данный продукт должен выполнять.
– Для этого часто используются общие схематические
диаграммы, показывающие общее представление разных
функций и их взаимосвязи между собой.
• Также описываются типичные характеристики
конечных пользователей и общих ограничений.
– При использовании гибких моделей разработки это м.б.
достаточно для начального этапа описания требований.
Описание детальных требований
• В разделе «детальные требования» описываются
подробности требований, которые разработчик
должен знать при проектировании и разработке
системы.
• Обычно это самая большая и важная часть
данного документа.
• Для данного раздела разные организации
предложили свои стандарты.
• Такие требования могут быть организованы в
виде иерархий режимов работы, классов
пользователей, объектов, особенностей,
стимулов и функций.
Детальные требования
• Одним из методов организации
специфических требований является
следующий:
– внешние интерфейсы;
– функциональные требования;
– требования к производительности;
– проектные ограничения;
– системные атрибуты.
Описание детальных требований
3. Детальные требования
3.1. Требования к внешним интерфейсам
3.1.1 Пользовательские интерфейсы
3.1.2 Технические интерфейсы
3.1.3 Программные интерфейсы
3.1.4 Коммуникационные интерфейсы
3.2. Функциональные требования
3.2.1 Режим 1
3.2.1.1. Функциональные требования 1.1
:
3.2.1.n. Функциональные требования 1.n
:
3.2.m. Режим m
3.2.m.1. Функциональные требования m.1
:
3.2.m.n. Функциональные требования m.n
3.3. Требования к производительности
3.4. Ограничения проектирования
3.5. Атрибуты
3.6. Другие требования.
Требования к внешним интерфейсам
• В разделе требований к внешним интерфейса
детально описывает все интерфейсы ПО:
– интерфейсы пользователей;
– интерфейсы взаимодействия с другими
программами;
– интерфейсы взаимодействия с техническими
устройствами;
– другие интерфейсы взаимодействия ПС (например,
коммуникационные).
Интерфейсы пользователей
• Интерфейсы пользователей являются очень
важным подразделом; в нем описываются все
способы взаимодействия человека с данной
ПС:
– экранные графические формы;
– содержание меню;
– структура команд (например, при использовании
монитора команд);
– файлы настройки.
Интерфейсы технического обеспечения
• В данном разделе описываются логические характеристики
каждого интерфейса между ПО и техническим
обеспечением, с которым выполняется взаимодействие:
– регистры;
– команды;
– диаграммы взаимодействия;
• Здесь перечисляются все предположения, которые ПО
делает о ТУ.
• Обычно взаимодействие с ТУ выполняется с помощью
драйверов этих устройств.
• Драйвер устройства это программный компонент
(библиотека, компонент) позволяющий высокоуровневой
программе взаимодействовать с техническим устройством.
Описание функциональных
требований к ПО
Функциональные требования
• В разделе «Функциональные требования»
описываются функциональные возможности
разрабатываемого ПО.
Сценарии
• Людям обычно проще пояснить свои требования к ПО
путем их связывания с реальной жизнью (а не с
абстрактными понятиями).
• Они могут понимать и критиковать сценарии (ситуации)
того, как они могут взаимодействовать с ПС.
• Специалисты по выявлению и описанию требований к
ПО могут использовать информацию, полученную из
такого обсуждения, для формулировки реальных
требований к системе.
• Сценарии м.б. особенно полезными для добавления
деталей к общим описаниям требований.
• Сценарии являются описаниями примеров сеансов
взаимодействия пользователей с системой.
Варианты использования
• Figure 4.15 Use cases for the MHC-PMS
Варианты использования
• Функциональные требования часто составляют ядро
документа с описаниями требований.
• Традиционный подход к спецификации
функциональности состоит в описании каждой функции,
которую разрабатываемая система должна
предоставить.
• Варианты использования (ВИ, Use Cases)
специфицируют функциональность системы путем
описания ее поведения, зафиксированного в виде
взаимодействий пользователя с данной системой.
• Варианты использования (ВИ) могут применяться для
описания бизнес-процессов большого предприятия или
организации, которые используют ПО, или ВИ могут
просто описывать поведение ПС.
Варианты использования
• Одним из наиболее часто используемых современных
подходов к разработке функциональных требований
является применение вариантов использования
(прецедентов, use case).
• Вариант использования это описание взаимодействия
между одним или несколькими субъектами (актерами,
действующими лицами, actor) и разрабатываемой
системой.
• На этапе работы с требованиями (requirements phase),
варианты использований рассматривают
разрабатываемую систему в виде черного ящика и
описывают взаимодействие между субъектом (или
субъектами) и ПС в упрощенном форме, включающей
ввод данных от пользователей и ответы системы.
• ВИ привлекли внимание разработчиков, после
того, как они были использованы в подходе к
разработке на основе ОО моделирования,
предложенного Якобсоном.
• В связи с их связью с ООП, ВИ иногда
рассматриваются в как часть ООП,
применяемого к разработке ПО.
• Однако, они являются общим методом для
описания взаимодействия систем (в том числе
и не IT систем).
Основные понятия вариантов
использования
• Разрабатываемая ПС может использоваться
разными пользователями или другими ПС.
• В терминологии ВИ, актер это человек или
некоторая система, которая использует
разрабатываемую ПС для достижения некоторой
цели.
• Т.к. актер взаимодействует для достижения
некоторой цели, то это логическая сущность,
которая представляет собой группу пользователей
(людей или систем), которые ведут себя
одинаковым образом.
• Разные актеры представляют собой разные цели.
Варианты использования
• Термины вариантов использования.
Термин
Определение
Актер
Actor
A person or a system which uses the system being built for
achieving some goal.
Основной
актер
The main actor for whom a use case is initiated and whose goal
satisfaction is the main objective of the use case.
Сценарий
A set of actions that are performed to achieve a goal under some
specified conditions.
Основной
успешный
сценарий
Describes the interaction if nothing fails and all steps in the
scenario succeed.
Расширенный Describes the system behavior if some of the steps in the main
сценарий
scenario do not complete successfully.
• Для описания взаимодействия ВИ применяют сценарии.
• Сценарий описывает набор действий, который выполняется для
достижения цели в некоторых специфических условиях.
• Набор действий в общем случае описывается, как
последовательность (т.к. это наиболее удобный способ выразить это
в виде текста), хотя реально данные действия могут выполняться
параллельно или в некотором другом порядке.
• Каждый шаг сценария является логически завершенным действием,
выполняемым или актером или системой.
• В общем случае, шаг это
– некоторое действие, выполняемое актером (например, ввод
информации);
– некоторый логический шаг, который выполняет система для
продвижения по пути достижения своих целей (например, проверка
информации, доставка информации и т.п.);
– изменение внутреннего состояния системы, для удовлетворения
некоторых целей (например, запись в журнал транзакции, обновление
записи в БД)
Простой вариант использования
• Пример простого варианта использования:
Актеры
• Актер представляет собой некоторую роль,
выполняемую в прикладной области приложения.
Обычно актером является человек пользователь.
• Пользователь это индивидуум, в то время, как актер
представляет собой роль, которую играют все
пользователи одного и того же типа.
– Например, тип существует несколько клиентов
(потребителей) в Банковской Системе, которые
представляются в виде актера «ATM Customer» (клиент
банкомата)
– Тогда, актер «ATM Customer» моделирует тип пользователя,
а конкретный клиент является экземпляром данного актера.
• Актер очень часто является человеком – пользователем.
• Поэтому, в языке UML, актер обозначается в виде
«рисованного человечка».
• Во многих информационных системах, люди
являются единственными актерами.
• Однако, возможно, что актером является
внешняя система, которая взаимодействует с
разрабатываемой системой.
Моделирование актеров
• Человек-актер обычно использует разные
устройства ввода/вывода для физического
взаимодействия с системой (такие, как
клавиатура, дисплей или «мышь»).
• Иногда человек актер может
взаимодействовать с системой посредством
не стандартных устройств, таких, как датчики
(например, Kinect).
• Во всех этих случаях человек является
актером, а устройства I/O актерами не
являются.
Первичные и вторичные актеры
• Первичный актер инициирует (начинает
действие) вариант использования.
– В этом случае, ВИ начинается с ввода данных
первичным актером, на которые система должна
отвечать.
• Вторичными актерами называют других
актеров, которые могут участвовать в данном ВИ.
• Актер м.б. первичный актером в одном ВИ, и
вторичным в другом ВИ.
• По крайней мере один актер может получать
выгоду от варианта использования, обычно это
первичный актер.
• Пример первичного и вторичного актеров, а
также внешних для системы актеров.
Пример актеров - людей
• В системе реагирования на чрезвычайные состояния (Emergency Response
System) примером актера является Следящий Оператор (диспетчер,
Monitoring Operator), который взаимодействует с данной системой
посредством стандартных устройств I/O (как показано на рис.).
• Другим примером человека-актера является клиент банкомата, который
взаимодействует с банковской системой используя такие устройства I/O, как
карт-ридер, устройство выдачи наличных денег, принтер чека, а также
клавиатутра и дисплей.
Пример актеров - устройств
• Актером м.б внешнее устройство, которое инициирует (как
первичный актер) ВИ, или участвует в ВИ.
• Например, Удаленная система в системе отслеживания
чрезвычайных состояний.
• В некоторых случаях актерами могут быть устройства ввода
(например датчики) или устройства ввода/вывода.
Актер - таймер
• Актером может быть таймер (timer actor), который
периодически посылает события таймера системе.
• Периодические ВИ требуются, когда некоторая
информация периодически должны выдаваться
системой
Актер и варианты использования
банковской системы
Пример описания варианта
использования
• Актер и ВИ системы он-лайн торговли
Взаимосвязи между вариантами
использования
• Если ВИ становятся слишком сложными, то можно
между ними задать зависимости с помощью
отношений включить (include) и расширить
(extend).
• Включенные ВИ описываются для выявления
общих последовательностей взаимодействия в
разных ВИ, которые затем могут извлекаться и
многократно использоваться
• Обобщение ВИ аналогично расширению
взаимосвязи, т.к. оно также используется для
преодоления разнообразия. Однако, понятие
обобщения часто сбивает пользователей с толку.
Отношение включения
• После того, как ВИ начально разработаны, иногда м.б.
выделены общие последовательности взаимодействия
между актером и системой, которые участвуют в
нескольких ВИ.
• Такие общие последовательности взаимодействия
содержать функциональность, которая является общей
для нескольких ВИ.
• Общие последовательности взаимодействия могут быть
извлечены из нескольких исходных ВИ и оформлены в
виде нового ВИ, который называется включаемым ВИ.
• Обычно включаемым ВИ, являются абстрактными и не
могут выполняться самостоятельно.
• Абстрактные ВИ должны выполняться, как часть
конкретного (т.е. выполняемого) ВИ.
Пример отношения включения и
включения вариантов использования
• Пример включенного ВИ и отношений «включение».
Структуризация длинных вариантов
использования
• Пример множественного включения вариантов
использования и отношения «включение».
Пример точки расширения
расширяющих вариантов использования
• Figure 6.11. Example of an extend relationship
and extension use cases
Пример: ВИ аукционной системы
• ВИ1: Размещение некоторого элемента на аукционе.
– Основной актер: Продавец (Seller)
– Предусловие: Продавец должен подключиться к системе (logged in).
• Основной успешный сценарий:
1.
2.
3.
4.
Продавец отправляет элемент (его категорию, описание, изображение
и т.п.) на аукцион.
Система показывает продавцу ранее выставленные на продажу
элементы.
Продавец определяет начальную цену торгов и время закрытия
аукциона.
Система принимает данный элемент и публикует его.
• Не стандартные сценарии:
– 2 a) В данной категории нет ранее выставленных на продажу
элементов.
• Система сообщает продавцу о такой ситуации.
• ВИ2: Выполнение торгов
– Основной актер: Покупатель
– Предусловие : Покупатель должен подключиться к системе (logged in).
• Основной успешный сценарий:
1. Покупатель выполняет поисковый запрос, или выполняет просмотр и выбор
нужного элемента.
2. Система показывает рейтинг продавца, начальную запрашиваемую цену,
текущую цену и высшую цену; просит покупателя предложить свойю цену.
3. Покупатель вводит предлагаемую цену, за которую он согласен купить
данный элемент.
4. Система принимает предлагаемую цену; блокирует деньги на счете
покупателя.
5. Система обновляет текущую цену; информирует других пользователей;
обновляет записи для данного элемента.
• Не стандартные сценарии :
– 3 a) Предлагаемые цены меньше чем максимальная предложенная цена.
• Система просит покупателя ввести новую цену.
– 4 a) Покупатель не имеет достаточно денег на своем счету.
• Система прерывает покупку и просит покупателя увеличить кол-во денег
на его счету.
• ВИ3: Завершение аукциона
– Первичный актер: Аукционная система.
– Предусловие: Достигнуто завершение последней даты
проведения торговли.
• Основной успешный сценарий :
1. Выбрать покупателя предложившего наивысшую цену; послать эл.
письма выбранному покупателю и продавцу с информацией о
конечной цене элемента; послать email другим участникам торга.
2. Списать деньги со счета покупателя и записать их на счет продавца.
3. Разблокировать все деньги заблокированные у участников торга.
4. Передать со счета продавца комиссионные деньги на счет
организации аукциона.
• Не стандартные сценарии: Нет
Проверка требований
Способы проверки требований
• Существует набор способов проверки
требований, которые могут использоваться по
отдельности или совместно:
– просмотр требований
– прототипирование
– формирование тестовых ситуаций
Управление требованиями
• Развитие требований
Долговременные и изменчивые
требования
Проверка требований
Статистика ошибок в требованиях
• В некоторых проектах собиралась статистика по ошибкам в требованиях
• Например было описано исследование эффективности применения разных
методов и инструментов для выявления ошибок в спецификациях
требований.
• В общем было выявлено более 250 ошибок:
Пропуск
Не правильный факт Не согласованность
Не однозначность
26%
10%
26%
38%
• В другом источнике описывалось проверка спецификации требований в
проекте A-7 (ПО для системы реального времени по управлению полетами).
Всего было выявлено около 80 ошибок, из которых 23% были связаны с
описками. Из оставшихся распределение ошибок по типам было
следующее:
Пропуск
Не правильный факт Не согласованность
Не однозначность
32%
49%
5%
13%
Команды по проверке требований
• Для выполнения такой работы обычно
создавались команды по анализу требований,
которые включали представителей заказчика и
пользователей.
Планирование управления
требованиями
• Figure 4.18 Requirements change management
Управления изменениями
требований
Requirements traceability
Выводы