Анализ требований к программному обеспечению

На этапе анализа требований проходит структуризация уже собранных ранее требований. Цель этапа — предоставить четкий список не дублируемых требований к системе, которые должны быть выделены из избыточных и частично дублирующихся сценариев и пользовательских историй, которые были полученных на предыдущем этапе. Правильно сгруппированные требования помогут обойтись минимальным количеством функционала для удовлетворения максимально большего количества целей [1].

Наиболее эффективным способом анализа требований является определение сценариев работы пользователей с будущим продуктом. Сценарий представляет совокупность всех процессов с их окружением, в которых продукт будет участвовать. Ценность сценария состоит в том, что он описывает способы взаимодействия с продуктом всех его пользователей одновременно на протяжении всего цикла эксплуатации продукта и, следовательно, гарантирует отсутствие к нему взаимоисключающих требований. Проверяют сценарий путем анализа его выполнения всеми заинтересованными лицами.

Каждый сценарий должен содержать: информацию обо всех типах пользователей, взаимодействующих с ним, описание процессов, которые будут затрагивать продукт, требования к дизайну(операционная система; приложения, с которыми интегрируется программный продукт, форматы ввода вывода) и приоритет.

Для приоритезации рекомендуется использовать метод MoSCoW [2].

В нем четыре оценки — Must, Should, Could и Won’t.

Элементы Must обязаны быть включенными в продукт.

Элементы Should также являются критическими для продукта, но, тем не менее, могут быть исключены из текущей версии продукта по объективным причинам.

Элементы Could являются некритичными, но способны увеличить пользовательскую удовлетворенность.

Элементы Won’t являются наименее критичными для продукта. Они могут считаться интересными и перспективными для будущих версий продукта, но точно не будут реализованы в текущей версии.