Рабочий поток определения требований

Большая часть работы в процессе определения требований выполняется в фазах Начало и Уточнение в самом начале жизненного цикла проекта. Это и не удивительно, поскольку невозможно продвигаться вперед, за фазу Уточнение, до тех пор, пока не известно, хотя бы приблизительно, что предполагается разрабатывать!
До начала работы над ОО анализом и проектированием уже необходимо иметь некоторое представление о том, что должно получиться в результате. Именно в этом состоит цель рабочего потока определения требований. С точки зрения ОО аналитика или дизайнера его цель – это поиск и достижение соглашения о функциях системы, написанного на языке пользователей системы. Создание высокоуровневой спецификации того, что должна делать система, – это часть процесса выработки требований (requirements engineering).
У любой заданной системы может быть множество различных заинтересованных сторон: разные типы пользователей, специалисты по эксплуатации, штат по обслуживанию, продаже, управлению и т.д. Выработка требований состоит в выявлении и классификации требований, предъявляемых к системе заинтересованными сторонами. Это переговорный процесс, поскольку часто выдвигаются противоречивые требования, которые должны быть согласованы. Например, одной группе хочется добавлять большое количество пользователей, что может привести к нереальному трафику в существующей базе данных и инфраструктуре связи. В настоящее время это наиболее распространенный конфликт, поскольку все большее и большее число компаний открывают части разработанных ими систем громадной аудитории пользователей через Интернет.
Некоторые книги по UML (и конечно, учебные курсы) отмечают, что прецеденты UML являются единственным способом фиксирования требований. Но это утверждение оказывается неверным при более тщательном рассмотрении. Прецеденты могут отражать только функциональные требования, которые являются описанием того, что будет делать система. Однако есть и другие требования, не относящиеся к функциональности, которые являются описаниями ограничений, накладываемых на систему (производительность, надежность и т. п.), и не могут быть представлены в виде прецедентов. Поэтому на сайте предлагается надежный подход к выработке требований, иллюстрирующий дополнительные эффективные способы выявления обоих видов требований.

Запись опубликована в рубрике Компьютеры и интернет с метками . Добавьте в закладки постоянную ссылку.

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

code