Введение в анализ требований
-
Upload
anton-trukhanyonok -
Category
Technology
-
view
391 -
download
2
description
Transcript of Введение в анализ требований
Анализ требованийАнтон Труханёнок, системный аналитик[email protected]
Жизненный цикл заказного ПО
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
Спасибо за внимание