O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Формирование требований из хотелок заказчика

1.335 visualizações

Publicada em

Презентация Руфина Сарваровой на SQA Days-16
14-15 ноября 2014, Санкт-Петербург, Россия
www.sqadays.com

Publicada em: Educação
  • Seja o primeiro a comentar

Формирование требований из хотелок заказчика

  1. 1. Формирование требований из хотелок заказчика Сарварова Руфина ICL Services, Казань
  2. 2. Требования не были плохими.. Их просто не так поняли • 75% - наш проект "обречен с самого начала." • 80% - переделываем работу больше половины времени • 78% - бизнес-заинтересованные стороны должны принимать более активное участие • 55% - бизнес-цели проекта ясны • < 20% - требования проекта соответствуют потребностям бизнеса • 23% довольны по завершению проекта
  3. 3. Что такое требования? • Требования определяют цель • Требования определяют потребности (проблемы) • Требования определяют решение • Требования определяют ограничения связанные с решением или проектом по его реализации
  4. 4. Идеальные требования Для аналитика Для программиста Для тестировщика
  5. 5. Роль требований «Анализируйте требования для определения риска связанного с тем, что конечный продукт не будет работать правильно в его предполагаемой среде использования» – CMMI, Guidelines for Process Integration and Product Improvement, Chrissis, Konrad, Shrum. 04.07.2010
  6. 6. Cynefin framework
  7. 7. Мы, не испытываем головной боли, мы только её переносчики Область проблем - Пользовательские требования Область решений - Системные требования
  8. 8. Область проблем и решений  недостаточное понимание существующих проблем  невозможность определить границы  доминирование разработчиков и исполнителей в дискуссиях о системе,  ограничения свободы в выборе решения.
  9. 9. Ошибки  Недостаточно четко определенные группы пользователей продукта  Не выделены представители, заинтересованные в продукте  Излишняя детализация
  10. 10. Систематизация заинтересованных сторон Власть 5 4 Легитимность Срочность/ Интерес 1 7 3 2 6
  11. 11. Высокий уровень абстракции Потребности Возможности Функции системы Язык заказчика
  12. 12. Сформулировать требования 1. Определить ключевые заинтересованные лица 2. Сформулировать проблему 3. Сформулировать возможности продукта 4. Документирование (описать в виде диаграмм, UC).
  13. 13. Оценка и проверка требований • Является ли требование полным? • Является ли требование ясным? • Является ли требование выполнимым? • Является ли план тестирования и тесты понятным и приемлемыми? • Требования могут быть измерены? • Требования могут быть протестированы? • Могут быть связаны с архитектурой системы?
  14. 14. Эволюция Дарвина
  15. 15. Кейс 1 требование1 от ЗЛ1 требование2 от ЗЛ2 требование3 от ЗЛ3
  16. 16. Кейс 2 “нужно чтобы отчёты открывались быстрей!” “нужно отрефакторить функционал Х” “почему у нас всё так медленно?” “алгоритм не работает!”
  17. 17. Заключение Хорошая работа над требованиями – это правильно, ПОНЯТНЕНЬКО!

×