Документирование требований Типовые решения требований

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

На сегодняшний день специалистами со всего мира описано большое количество типовых решений для применения в различных ситуациях [6], [7] и [8]. Наиболее популярными являются типовые решения для описания требований в виде вариантов использования [7].

Рассмотрим один из самых часто встречающихся типовых решений – CRUD. Типовое решение CRUD(Create,Read,Update,Delete) предназначается для описания ситуаций управления различной информацией. Под управлением информацией будем понимать ее запись в базу данных, обновление и чтение, а также удаление из базы данных. Управление информацией является пользовательским требованием, так как именно пользователь, например оператор, будет работать с информацией. На первый взгляд, кажется, что удобно было бы создать четыре отдельных варианта использования: «Записать информацию», «Обновить информацию», «Получить информацию» и «Удалить информацию». Однако каждый из приведенных выше вариантов использования, является атомарной операцией, выполняемой системой по действию пользователя. В случае большого количества разнородной информации, набор таких атомарных вариантов использования будет довольно большим, что приведет к усложнению модели и как следствие к невозможности ее структурирования и управления. Также, как показывает практика, все четыре приведенных варианта использования, должны реализовываться разработчиками одновременно, так как относятся к одной обрабатываемой информации. Именно для того чтобы упростить модель вариантов использования, сделать ее боле понятной и необходимо применение типового решения CRUD. В случае его применения, будет создан один вариант использования, например «Управление информацией». Различные же действия, для каждой конкретной операции (запись, чтение, удаление), можно оформить в виде отдельных сценариев одного варианта использования.

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

Уровень 5 – Комплексность требований

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

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