Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

866 views

Published on

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

Published in: Technology
  • Be the first to comment

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

  1. 1. Анализ требований Антон Труханёнок, системный аналитик antonxt@gmail.com
  2. 2. Жизненный цикл заказного ПО 1. 2. 3. 4. 5. 6. 7. 8. Pre-sale (proposal, vision, scope) Анализ требований (requirements document) Разработка (functional specification) Тестирование (test cases) Приёмка (акт приёмки) Внедрение (user manual, обучающие курсы, очное обучение) Поддержка Терминация, миграция на новую систему
  3. 3. Стадии в Rational Unified Process
  4. 4. Этапы анализа требований 1. 2. 3. 4. Выявление заинтересованных лиц и источников требований Сбор требований Анализ, составление ТЗ Согласование ТЗ
  5. 5. Источники требований • Интервью, опросы, анкетирование • Мозговой штурм, семинар • Нормативная документация, стандарты • Конкурентные продукты • Предыдущая версия системы • Google и Wikipedia
  6. 6. Качественный набор требований должен • Полнота • Понятость • Реализуемость • Непротиворечивость • Недвусмысленость • Выполнимость • Отслеживаемость • Последовательность
  7. 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. 8. Нефункциональные требования • Runtime availability, reliability, durability, scalability, usability, security, configurability, performance, restrictions • Design time reusability, extensibility, portability, interoperability, supportability, modularity, testability, localizability, compatibility
  9. 9. Диаграммы • Облегчают и ускоряют восприятие документа, особенно при первом прочтении • Иногда эффективно заменяют большое количество текста Хорошие диаграммы: 1. Эстетичны, выполнены в едином стиле с документом 2. Не загромождены (до 20 элементов)
  10. 10. UML Class Diagram
  11. 11. UML Components diagram
  12. 12. Use Case Сценарий использования должен: • Описывать что именно система должна сделать, чтобы актер достиг своей цели. • Не затрагивать деталей реализации. • Иметь достаточный уровень детализации. • Не описывать пользовательские интерфейсы и экраны. Это делается во время дизайна пользовательского интерфейса.
  13. 13. UML Use Case diagram
  14. 14. UML Activity diagram
  15. 15. UML Sequence diagram
  16. 16. BPMN diagram
  17. 17. Прототипы и макеты пользовательского интерфейса • Понятны всем, воспринимаются значительно легче, чем текст • Выявляют проблемы уровня требований на раннем этапе Проблемы: 1. Отделить дизайн от функционала 2. Дать понимание, что это лишь прототип, но не экземпляр системы (как, у вас уже всё готово, за что вы просите столько денег?) Где делать? Макеты: Visio, Balsamiq. Прототипы: Flair Builder
  18. 18. Спасибо за внимание

×