Анализ документации

Часто на практике, разрабатываемое программное приложение предназначается для автоматизации деятельности некоторых бизнес процессов заказчика. В большинстве случаев, данные процессы уже задокументированы в различных регламентах, инструкциях, правилах и другой документации. В таком случае аналитику не требуется проводить интервью с заказчиком и требуется лишь изучить существующую документации и получить из нее необходимую информацию для дальнейшего формирования из нее требований к программному обеспечении.

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

Документирование требований

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

Проверка требований

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

Экспертная оценка

Экспертная оценка позволяет проектной команде получить требования, не противоречащие предметной области. Экспертная оценка приводит к получению требований, соответствующих критерию качества – правильность. Далее приведены некоторые рекомендации по выполнению экспертизы и на рисунке 3 представлен график зависимости количества ошибок на страницу спецификации от скорости проведения экспертизы.

Рисунок 3. Скорость проведения экспертной оценки

Правила проведения экспертизы:

• 1-2 страницы в час считается оптимальной скоростью для наиболее эффективного обнаружения ошибок в спецификации

• 2-4 страницы в час являются практически рекомендуемыми.

• Корректируйте норму экспертизы, основываясь на:

1) объеме текста на каждой странице,

2) сложности спецификации,

3) рисках, связанных с пропуском ошибок,

4) критичности материалов экспертизы для успешного завершения проекта,

5) квалификации человека, написавшего спецификацию требований.

• Начинайте экспертизу, когда спецификация требований готова на 10-20%.

Согласование документов

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

Уровень 2 – Организация требований

Целью второго уровня зрелости является получение набора требований, понятных заказчику и членам проектной команды. Требования должны понятно, непротиворечиво и однозначно описывать желаемое поведение разрабатываемой системы. Для того, чтобы получить требования с такими критериями качества, необходимо разработать шаблоны документов, собрать требования в единой базе данных и вести историю их изменений. Так как требования могут использоваться различными членами проектной команды и заказчиком, необходимо иметь возможность разграничения прав доступа к требованиям. Затраты, необходимые для достижения второго уровня зрелости связаны в основном с обучение проектной команды новым методам работы и дополнительными проверками требований и спецификаций. Однако эти затраты способствуют получению более качественных требований, что в итоге сократит стоимость и сроки разработки. Дополнительные затраты могут быть связаны с покупкой инструментального средства управления требованиями.

Далее рассмотрим ключевые процессы для данного уровня зрелости и их состав.