02-Requirements

Анализ требований
Copyright © Мухортов В. В., Няньчук-Татарский Н. А., 2001-2004
Copyright © ООО «Интекс», 2003-2004
Процесс разработки ПО
Анализ требований и предметной области
Системный анализ
Проектирование и реализация
Сопровождение и развитие
О важности анализа требований
•31% проектов – остановлены до завершения
•53% проектов стоили 189% от первоначальной
оценки
•В крупных компаниях 9% проектов выполнено в
срок и без превышения бюджетов.
•В мелких компаниях 16% проектов выполнено в срок
и без превышения бюджетов.
- Отчет Standish Group, 1994, (проанализировано 8000 проектов)
Источники ошибок

Недостаточное количество информации
от пользователей
- 12,8%

Неполные спецификации - 12,3%

Изменения требований
- 11.8 %
Отчет Standish Group, 1994, (проанализировано 8000 проектов)
Проекты US Air Force
Источники ошибок








Требования
Проектирование
Данные
Интерфейс
Окружение
Человеческий фактор
Документация
Остальные
- 41%
- 28%
- 6%
- 6%
- 5%
- 5%
- 2%
- 7%
Sheldon F., “Reliability Measurement from Theory to Practice”, 1992
Стоимость ошибок в требованиях
Относительная стоимость исправления ошибок
(по фазам)
• Инициирование проекта
• Проектирование
• Кодирование
• Компонентное тестирование
• Тестирование в момент приемки
• Использование и поддержка
- 0,1 – 0,2
- 0,5
-1
-2
-5
- 20
- Davis A., “Software Requirements – Objects, Functions and States”, 1993
Документирование требований


Основным средством документирования
требований является текст на
естественном языке.
Проблемы:


Неоднозначность интерпретации
Слабое структурирование информации
Варианты использования (use cases)


Вариант использования (use-case) есть
средство структурирования
требований,
Вариант использования описывает
соглашение между заинтересованными
сторонами (stakeholders) о поведении
системы.
(По Alistair Cockburn, Writing the effective Use-Cases)
Заинтересованные стороны

Заинтересованные стороны:




Пользователи системы
Другие системы
Заинтересованные стороны называются
актерами или актантами (Actor)
Актер не является конкретным
человеком, а определяет набор ролей в
системе.
Варианты использования


Actor – внешнее по отношению к системе
действующее лицо, некто (или нечто),
взаимодействующее с системой.
Use case – некая последовательность действий
системы, представляющая ценность для Actor-а,
вариант использования системы (Ivar Jacobson). Usecase описывает, что делает система, но не указывает
как.
<<stereotype>>
Actor
use case
Пример: Экзамен
Student
exam
Teacher принимает экзамен у Student.
Teacher
Вариант использования



Имеет название
Определяет четкие цели, которые
достигаются актерами в результате
выполнения этого варианта
использования.
Определяет последовательность
событий и действий, необходимых
для достижения данных целей.
Диаграммы вариантов
использования



Варианты использования
Актеры
Отношения между актерами и
вариантами использования
Включаемые use-cases



Stereotype: <<include>>
Различные use-cases могут иметь общие части
Абстрактный use-case не активируется actor-ами
<<include>>
pass an exam
User
identify user
<<include>>
Braibench
change personal data
Семантика отношения включения
Генерализация actor-ов
Различные actors могут играть одну и ту-же общую роль
в некотором use-case
Citizen
Student
pay taxes
Teacher
Расширение use-cases
Stereotype: <<extend>>
Некоторые use-cases могут вызываться в контексте
других только при некоторых условиях
User
login
<<extend>>
password expired
Семантика отношения расширения
Генерализация вариантов
использования

Иногда два use-case-а могут иметь некоторую общую
последовательность действий. Для того, чтобы
показать эту общность используется генерализация
use-case-ов.
Заказать через Internet
Internet-клиент
Сделать заказ
Заказать по телефону
Кпиент телефонной
службы
Семантика генерализации
вариантов использования
Документирование use-cases






Имя
Основная цель (Goal in context)
Основной(-ые) актер(ы) (Primary actor(s))
Предусловие (Precondition)
Условие начала действия (Trigger condition)
Сценарии достижения цели



Основной сценарий (main success scenario)
Альтернативный сценарий №1 (alternative
scenario)
…
Замечания



Use-case должен описывать ЧТО
делает система, но НЕ КАК
=> Глубокие иерархии use-cases чаще
всего бесполезны и ведут к
функциональной декомпозиции
=> Большое количество мелких usecase не прибавят понимания того, что
делает система
Типичные ошибки
документирования




Большое количество информации о
пользовательском интерфейсе
Отсутствует основной actor
Слишком высокая детализация
Не описаны действия системы
Диаграммы состояний







Описывают состояния объекта и переходы между
состояниями
State – некое состояние объекта
Event – событие, вызывающее переход
Transition – переход в новое состояние
Condition – условие перехода (true|false)
Action – мгновенное непрерываемое действие,
сопровождающее переход
Activity – деятельность, связанная с состоянием
Пример: сдача экзамена
допуск проверен[ не сдан зачет ]
Начало экзамена
Проверка
допуска
Свободен!
допуск проверен[ зачет сдан ] / получить билет
Подготовка
entry/ достать шпаргалки
do/ списать ответы
exit/ спрятать шпаргалки
готов[ препод занят ]
Ожидание
вызвал преподаватель
вызвал преподаватель
сдача
экзамена
конец сдачи[ хорошо ответил ]
Сдал
готов сдавать[ преподаватель
свободен ] / поднять руку
конец сдачи[ плохо ответил ] /
договориться о пересдаче
Не сдал
Пример: вложенные состояния
Применение: группировка состояний и упрощение диаграммы
Имеют не более одного начального и конечного состояний
готов
start
подготовка 2
что делать
?
ответ
доп вопросы
написание ответов
на вопросы
решение
задач
вызвал преподаватель
Пример: состояния с историей
ответ 2
получение
вопроса
H
вернулся
обдумыва
ние
ожидание
entry/ спросить подсказку
ответ
препод вышел
Н – недавнее историческое состояние
Н* - глубокое историческое состояние
Диаграммы деятельностей

Описывают последовательности действий







используются для описания операций и вариантов
использования
Activity - деятельность
Transition – переходы между деятельностями
Guard condition – условие перехода
Decision – блок принятия решения
Concurrent threads – параллельные деятельности
Synchronization bar – линейка синхронизации
параллельных деятельностей
Пример: банкомат