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

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

Глоссарий

Глоссарий (Glossary) представляет собой документ, описывающий все основные определения, встречающиеся в проекте. Сосредоточение определений в одном документе позволяет отслеживать изменения определений, добавление новых и удаление старых определений. Глоссарием могут пользоваться все участники проекта по разработке программного обеспечения: аналитики, разработчики, системные архитекторы, инженеры по тестированию и заказчики. В основном глоссарий содержит определения предметной области и дает участникам проекта возможность понимания предметной области. Также глоссарий позволяет участникам проекта разговаривать на «одном» языке. За ведение глоссария обычно отвечает системный аналитик.

Документ – концепция

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

Спецификация требований

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

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

Наличие спецификации требования, утвержденной заказчиком, позволяет снизить риски, связанные с разработкой, а именно:

• риск разного понимания требований разными участниками разработки;

• риск разработки программного обеспечения, не отвечающего потребностям заказчика;

• риск ошибочной оценки трудоемкости работ;

• риск смены команды разработчиков.

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

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

Для проверки требований рекомендуется также использовать руководства и контрольные списки, которые содержат рекомендации и критерии «хороших» требований.