Введение в анализ требований

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

Жизненный цикл заказного ПО

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

Стадии в Rational Unified Process

Этапы анализа требований

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

Источники требований

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

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

Техническое задание

a) Видение, концепция (зачем это всё?)b) Статическая структура:

a) Бизнес-сущности (UML class diagram, Database Structure diagram),b) Компоненты системы (UML Component)c) XML Schema

c) Процессыa) Прецеденты использования (Use Cases)

a) UML Use Caseb) UML Activityc) UML State Machined) UML Sequencee) BPMN

d) Прототипы пользовательского интерфейсаe) Нефункциональные требования

Нефункциональные требования

• Runtimeavailability, reliability, durability, scalability, usability, security, configurability, performance, restrictions

• Design timereusability, extensibility, portability, interoperability, supportability, modularity, testability, localizability, compatibility

Диаграммы

• Облегчают и ускоряют восприятие документа, особенно при первом прочтении• Иногда эффективно заменяют большое количество текста

Хорошие диаграммы:1. Эстетичны, выполнены в едином стиле с документом2. Не загромождены (до 20 элементов)

UML Class Diagram

UML Components diagram

Use Case

Сценарий использования должен:• Описывать что именно система должна сделать, чтобы актер

достиг своей цели.• Не затрагивать деталей реализации.• Иметь достаточный уровень детализации.• Не описывать пользовательские интерфейсы и экраны. Это

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

UML Use Case diagram

UML Activity diagram

UML Sequence diagram

BPMN diagram

Прототипы и макеты пользовательского интерфейса• Понятны всем, воспринимаются значительно легче, чем текст• Выявляют проблемы уровня требований на раннем этапе

Проблемы:1. Отделить дизайн от функционала2. Дать понимание, что это лишь прототип, но не экземпляр системы

(как, у вас уже всё готово, за что вы просите столько денег?)

Где делать? Макеты: Visio, Balsamiq. Прототипы: Flair Builder

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