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

1. Анализ требований
Антон Труханёнок, системный аналитик
antonxt@gmail.com

2. Жизненный цикл заказного ПО
1.
2.
3.
4.
5.
6.
7.
8.
Pre-sale (proposal, vision, scope)
Анализ требований (requirements document)
Разработка (functional specification)
Тестирование (test cases)
Приёмка (акт приёмки)
Внедрение (user manual, обучающие курсы, очное обучение)
Поддержка
Терминация, миграция на новую систему

3. Стадии в Rational Unified Process

4. Этапы анализа требований
1.
2.
3.
4.
Выявление заинтересованных лиц и источников требований
Сбор требований
Анализ, составление ТЗ
Согласование ТЗ

5. Источники требований
• Интервью, опросы, анкетирование
• Мозговой штурм, семинар
• Нормативная документация, стандарты
• Конкурентные продукты
• Предыдущая версия системы
• Google и Wikipedia

6. Качественный набор требований должен
• Полнота
• Понятость
• Реализуемость
• Непротиворечивость
• Недвусмысленость
• Выполнимость
• Отслеживаемость
• Последовательность

7. Техническое задание
a) Видение, концепция (зачем это всё?)
b) Статическая структура:
a)
b)
c)
Бизнес-сущности (UML class diagram, Database Structure diagram),
Компоненты системы (UML Component)
XML Schema
c) Процессы
a)
Прецеденты использования (Use Cases)
a)
b)
c)
d)
e)
UML Use Case
UML Activity
UML State Machine
UML Sequence
BPMN
d) Прототипы пользовательского интерфейса
e) Нефункциональные требования

8. Нефункциональные требования
• Runtime
availability, reliability, durability, scalability, usability, security,
configurability, performance, restrictions
• Design time
reusability, extensibility, portability, interoperability,
supportability, modularity, testability, localizability,
compatibility

9. Диаграммы
• Облегчают и ускоряют восприятие документа, особенно при
первом прочтении
• Иногда эффективно заменяют большое количество текста
Хорошие диаграммы:
1. Эстетичны, выполнены в едином стиле с документом
2. Не загромождены (до 20 элементов)

10. UML Class Diagram

11. UML Components diagram

12. Use Case
Сценарий использования должен:
• Описывать что именно система должна сделать, чтобы актер
достиг своей цели.
• Не затрагивать деталей реализации.
• Иметь достаточный уровень детализации.
• Не описывать пользовательские интерфейсы и экраны. Это
делается во время дизайна пользовательского интерфейса.

13. UML Use Case diagram

14. UML Activity diagram

15. UML Sequence diagram

16. BPMN diagram

17. Прототипы и макеты пользовательского
интерфейса
• Понятны всем, воспринимаются значительно легче, чем текст
• Выявляют проблемы уровня требований на раннем этапе
Проблемы:
1. Отделить дизайн от функционала
2. Дать понимание, что это лишь прототип, но не экземпляр системы
(как, у вас уже всё готово, за что вы просите столько денег?)
Где делать? Макеты: Visio, Balsamiq. Прототипы: Flair Builder

18. Спасибо за внимание