Требования от продукта
Требования являются отправной точкой для определения того, что команда будет проектировать, реализовывать и тестировать. Вне зависимости от того, какая модель разработки ПО используется на проекте, чем позже будет обнаружена проблема, тем сложнее и дороже будет ее решение. Если проблема в требованиях будет выяснена на начальной стадии, ее решение может свестись к исправлению пары слов в тексте, в то время как недоработка, вызванная пропущенной проблемой в требованиях и обнаруженная на стадии эксплуатации, может даже полностью уничтожить проект.
Источники и пути выявления требований
Требования начинают свою жизнь на стороне заказчика. Их сбор и выявление осуществляются с помощью следующих основных техник:
Интервью. Самый универсальный путь выявления требований, заключающийся в общении, как правило, бизнес-аналитика и представителя заказчика. Главное - ключевыми фигурами выступают двое - интервьюируемый и интервьюер.
Работа с фокусными группами. Может выступать как вариант «расширенного интервью», где источником информации является не одно лицо, а группа лиц, представляющих собой целевую аудиторию.
Анкетирование. Этот вариант спорный, т.к. при неверной реализации может привести к нулевому результату при объемных затратах. Однако, позволяет автоматически собрать и обработать огромное количество ответов от огромного количества респондентов.
Семинары и мозговой штурм. Семинары позволяют группе людей очень быстро обменяться информацией, а также хорошо сочетаются с интервью, анкетированием, прототипированием и моделированием - в том числе для обсуждения результатов и формирования выводов и решений.
Наблюдение. Может выражаться как в буквальном наблюдении за некими процессами, так и во включении бизнес-аналитики в эти процессы в качестве участника. Плюс: позволяет увидеть то, о чём могут умолчать интервьюируемые, анкетируемые и представители фокусных групп, Минус: отнимает очень много времени и чаще всего позволяет увидеть лишь часть процессов.
Прототипирование. Состоит в демонстрации и обсуждении промежуточных версий продукта. Это один из лучших путей поиска единого понимания и уточнения требований, однако он может привести к серьезным дополнительным затратам при отсутствии специальных инструментов. Пример - дизайн демонстрируемый картинками или кусочками, до верстки.
Анализ документов. Хорошо работает тогда, когда эксперты в предметной области (временно) недоступны, а также в предметных областях, имеющих общепринятую устоявшуюся регламентирующую документацию. Также к этой технике относится и просто изучение документов, регламентирующих бизнес-процессы в предметной области заказчика или в конкретной организации, что позволяет приобрести необходимые для лучшего понимания сути проекта знания.
