Лекция 8. Методы детализации функциональных требований

Лекция 8. Методы детализации функциональных требований.
Этап выявления и детализации требований.
Вариант исспользования (use case) как способ описания функциональных требований.
Этап анализа и детализации требований к ПП
Как вы помните первым (нулевым) этапом разработки ПП является Этап [предпроектного]
исследования сферы деятельности ПП (см. Лекцию 4). Следующим этапом в разработки ПО
является Этап анализа и детализации требований к ПП (соответствует второй половине стадии
Inception и первой половине стадии Elaboration по технологии RUP). Часто эти 2 этапа объединяют
в один и тогда он называется Этапом сбора требований к ПП.
На этапе анализа 1и детализации требований к ПП выявляются более детальные требования к
системе, выполняется анализ предметной области. Описанные на данном этапе требования
заказчика выражают предполагаемое взаимодействие ПП с заинтересованными лицами и
являются эталоном, по которому проверяется функциональность программного продукта и его
способность предоставлять услуги.
Результатами стадии анализа и детализации требований к ПП являются:
 Модель вариантов исспользования (use case diagram) завершенная по крайней мере на
80%, определяющая функциональные требования
 Перечень дополнительных требований, включая требования нефункционального
характера и требования не всязанные с конкретными вариантами исспользования (use
case)
 Модель предметной области (domain model, ER-diagram), которая отражает понимание
бизнеса и служит отправным пунктом для формирования основных классов предметной
области
 Модели пользовательского интерфейса (user interface prototype, use-case story board)
На основании этих результатов разработчик с участием заказчика разрабатывают SRS (Software
Requirements Specification), которое согласовывается с руководителями организаций
(подразделений), участвовавших в его разработке, и утверждается заказчиком. Разработка и SRS
может выполняться итерациями и утверждаться для каждой этапа итерации отдельно.
Вариант исспользования (use case) как способ описания функциональных
требований.
Use-Case описывает последовательность действий пользователя и системы, которые приносят
требуемые результаты для опеределенного актера системы.
Преимущества исспользования Use-Cases для детализации функциональных требований:
• Исспользуется естесственый язык => проще писать и читать
1
Ппроцесса анализа требований к ПО заключается в преобразовании требований
заинтересованного лица в техническое видение требуемого ПП.
1
•
•
•
•
заставляют разработчиков думать о дизайне системы с позиции пользователей
вовлекают пользователей в процесс сбора и анализа требований, помогая им понять
разрабатываемую систему и давая им способ взаимодействовать с программистами и
документировать поставленные задачи
описывают требования, давая возможность понять соответствуют ли они
сформулированным задачам
описывают последовательность действий
Каждый Use-Case состоит из шести обязательных элементов:
•
•
•
•
•
•
•
•
•
Имя Use-Case
Краткое описание/цель Use-Case
Актеры
Предусловие/постусловие (Pre-conditions/Post-conditions)
Удачный сценарий (Main Success Scenario)
Расширения (Extensions)
Список связанных Use-cases (не обязательно)
Список связанных данных(Work Items) (не обязательно)
Список раскадровок (не обязательно)
Имя Use-Case является уникальным идент-м для Use-Case. Оно должно быть написанио в формате
Глагол-Существительное, должно описывать достигаемую цель и должно быть достаточно для
понимания что должен выполнять этот Use-Case.
Краткое описание/цель Use-Case
Содержит краткое описание цели данного Use-Case-а.
Должно содержать не более 2-3 предложений написанных языком пользователя.
Например, для Use-Case 01: “Редактирование еженедельного расписания”
“Администратор расписания инициирует изменение еженедельного расписания, заполняет
необходимые поля по выбору Группы студентов, Преподавателя и Аудитории и сохраняет новые
настройки в систему. Аудитория – бронируется, время проведения занятия фиксируется в
календаре студентов и преподавателя, о чем они получают автоматические оповещения по
электронной почте”.
Актеры (Primary actors)
Актеры – кто-то или что-то, что взаимодействует с системой. С практической точки зрения
существует три основных типа актеров:
2
•
Пользователи
В данном случае в этом пункте перечисляется список ролей пользователей в системе, которые в
первую очередь заинтересованы в результате выполнения этого Use Case
•
Другие системы или приложения
•
Оборудование
Например, “Студент”, “Декан”, “Администратор расписания”
Предусловия (Pre-conditions)
Предусловия – это те условия, которые должны быть выполнены для того чтобы Use-Case начался.
Они обычно представляют состояние системы, которое должно быть достигнута перед
исспользованием Use-Case.
Например, для “Use-Case 01. Редактирование еженедельного расписания”:
“Актер аудентифицирован в системе и имеет права на выполнение операции. Актер инициирует
операцию:
•
Нажатием кнопки “Изменить расписание” в Main Menu
•
Нажатием кнопки “Изменить расписание” на странице просмотра расписания
•
Двойным щелчком мыши на свободную аудиторию на странице просмотра расписания
Постусловия (Post-conditions)
Постусловия описывают состояние системы после выполнения Use-Case. Оно обычно
представляется в виде данных, которые должны быть сохранены как результат выполнения UseCase.
Например, для “Use-Case 01. Редактирование еженедельного расписания”:
•
Изменения в расписании сохранены в системе
• Студенты и преподаватель (пользователи, для которых расписание было изменено)
получают уведомления по электронной почте.
Удачный сценарий выполнения (Main Success Scenario)
Удачный сценарий выполнения должен включать последовательность взаимодействий актера и
системы, которые необходимы для достижения цели Use-Case (обычно это наиболее вероятный
сценарий выполнения). Взаимодействия между пользователем и системой должны быть описаны
в форме простого нумерованного листа действий без условий.
Все возможные условия к сценарию должны быть описаны как Расширения к этому сценарию.
Например, для Use-Case 01: “Редактирование еженедельного расписания” удачный сценарий
выполнения будет выглядеть следующим образом:
1.
Актер выбирает время проведения занятия
1.1.
выбирает день недели
1.1.1. dropdown list box
1.1.2. по умолчанию: понедельник
1.1.3. возможные значения: понедельник - суббота
1.2.
выбирает время
1.2.1. два текстовых поля: с и по
1.2.2. маска заполнения HH:MM
2.
Актер выбирает группу/группы студентов
2.1.
выбирает факультет
3
2.1.1. dropdown list box
2.1.2. сортировка: по названию факультета
2.1.3. по умолчанию: первое значение в списке
2.
Актер выбирает группу/группы студентов (Продолжение)
2.2.
при выборе значения – список групп студентов и преподавателей обновляется на
тех, кто числится за данным факультетом
2.3.
выбирает студентов
2.3.1. выбирает одну группу
2.3.1.1. dropdown list box
2.3.1.2. сортировка: по имени группы
2.3.1.3. по умолчанию: первое значение в списке
2.3.2. выбирает несколько групп (Use-Case 02. “Назначение занятия нескольким
группам студентов”)
3.
Актер выбирает преподавателя
3.1.
...
3.2.
...
4.
Актер выбирает аудиторию (Use-case 03. Поиск свободной аудитории)
5.
Актер нажимат “Сохранить расписание”
6.
Актер переходит на страницу просмотра расписания
Расширения (Extensions)
Расширения представляют альтернативный сценарий/сценарии (дополнительное поведение) к
основному сценарию.
Также, в этом пункте указывают обработку исключений (exceptions) в процессе выполнения
основного сценария, таких как:
•
неудачном сохранении данных
•
ситуации (особенно актуальна для списков данных), когда back-end не возвращает ни
одной записи в таблицы.
•
информативные и подтверждающие сообщения
•
заполненность обязательных полей
•
др.
Альтернативный сценария обычно нумеруется как номер шага основного сценария плюс буква (a,
b, c, …) отдельного брэнча.
Например, для Use-Case 01: “Редактирование еженедельного расписания” альтернативный
сценарий выполнения будет выглядеть следующим образом:
1.a: Актер инициировал данный Use-Case двойным нажатием на свободную аудиторию в
рассписани
День недели и время должны быть заполнены в соответствии выбранной аудиторией
2.3.1.а:Выбранная группа студентов уже занята в выбранный день и время
Приложение генерирует сообщение об ошибке и предлагает Актеру выбрать другую группу
студентов. В сообщении содержится ссылка на pop-up страницу, где Актер может просмотреть
расписание данной группы
5.а:
5.b:
5.c:
Список связанных Use-Cases
4
Если данный Use-Case содержит ссылки на другие Use-Cases, то в данном пункте они должны быть
перечисленны.
Например, Use-Case 01: “Редактирование еженедельного расписания” исспользует следующие
Use-Cases:
•
Use-Case 02. Назначение занятия нескольким группам студентов
•
Use-Case 03. Поиск свободной аудитории
Список связанных сущностей (Work Items, Entities)
В этом пункте должен быть приведен список сущностей, которые исспользуются при прохождении
Use-Case.
Например, Use-Case 01: “Редактирование еженедельного расписания” работает со следующими
сущностями :
Entity 01: Классификатор факультетов
Entity 02: Группы
Entity 03: Преподаватели (может быть Работники с фильтром преподаватели)
Entity 04: Аудитории
Entity 05: Календарь групп
Entity 06: Календарь преподавателей
Entity 07: Календарь аудиторий
Список используемых прототипов UI
В этом пункте должен быть приведен список Прототипов интерфейса пользователя, которые
исспользуются в данном Use-Case.
Например, Use-Case 01: “Редактирование еженедельного расписания” исспользует следующие
прототипы:
GUI Prototype 1: Редактирование еженедельного расписания
GUI Prototype 2: Выбор нескольких групп студентов
GUI Prototype 3: Информационное сообщение по поводу занятости группы/преподавателя
Use-Case диаграмма
Use-Case диаграмма – это тип UML диаграммы, целью которой является графическое описание
функциональности системы (части системы).
Оснавные задачи:
• Определить общие границы и контекст моделируемой предметной области
•
Сформулировать общие требования к функциональному поведению
•
Структурировать предметную область
Use-Case диаграмма представляется с помощью:
•
Актеров
•
Их целей при работе с системой (в виде Use-Cases)
• Отношений между Use-Cases
Пример Use-Case диаграммы
5
uc Document feed
Univer - ApplicantInfo - Document feed
Check if already exist
Find the applicant
form
Check required fields
«include»
«include»
Fill applicant form
Applicant
(from Use Case)
«include»
Manage applicant
form
Export applicant form
data
Selection
committee
(from Use Case)
6