Анализ качества требований Павел Кравченко, Ciklum

Предварительные условия «семь раз отмерь, один раз отрежь» Затраты на конструирование иногда составляют аж 65% Иногда это придодится делать не один раз ;) Тестирование не позволяет обнаружить такие ошибки, как создание не того приложения или создание нужного приложения не тем образом

Риск неудачная выработка требований плохое планирование проекта

Причины плохой подготовки Нет опыта (делать много такой работы нет смысла) Хочется быстрее педалить Менеджеры хотят видеть результат

В результате Можно созадать не ту систему Не тем способом Потратить больше усилий (больше времени) Исправлять ошибки проектирования в конце разработки в раз дороже

Подходы Итеративный Последовательный

Требования стабильны Проект прост и понятен Разработчики знакомы с предметной областью Проект не связан с особым риском

Итеративный Требования непонятны Могут меняться Проект сложен или не ясен Разработчики не знакомы с предметной областью Проект сопряжен с высоким риском Затраты на изменение проекта будут низкими

Определение проблемы Определение проблемы (на языке пользователя!) Выработка требований Проектирование архитектуры Конструирование Тестирование Будущие улучшения

Зачем нужны требования? Гарантируют, что функциональность определяется пользователем Помогают избегать споров Требования во время реализации изменяются на 25%

Изменение требований Оцените качество требований Убедитесь, что всем известна цена изменений Используйте подходы, которые адаптируются к изменениям Оставьте проект ;) Помните о бизнес-модели проекта