Пример документа описания требований

Лабораторная работа №10

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

Цель работы:научитьсясоставлять документ описания требований к разрабатываемой ИСсогласно шаблону.

Теоретические сведения

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

Ядро документа описания требований состоит из формулировок(изложения) требований. Требования могут быть сгруппированы в видеформулировок сервисов (зачастую называемых функциональнымитребованиями) и формулировок ограничений. Формулировки сутисервисов могут быть затем разделены на требования к функциям (functionrequirements) итребованиякданным(datarequirements). (В литературетермин «функциональные требования» (functionalrequirements) вшироком и в узком смысле используется как взаимозаменяемый.Прииспользовании в узком смысле он соответствует тому, что мы называемтребованиями к функциям).

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

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

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

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

На рисунке 1 показано типичное оглавление документа описаниятребований. Последующие разделы включают объяснение к приведенномуоглавлению.

Рисунок 1 – Содержание документа описаний требований

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

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

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

Необходимо обозначить участников проекта системы. Важно, чтобызаказчик выступал не в виде безликого подразделения или офиса – необходимо привести конкретные имена. К концу дня человек долженбыть в состоянии решить, приемлемо ли поставляемое программноеобеспечение (ПО) для организации.

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

Особый интерес представляют готовые решения. Всегда неплохорассмотреть вариант приобретения готового продукта вместо егоразработки «с нуля».

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

Приобретение готового решения изменяетпроцесс разработки, однако это не избавляет от необходимостипроведения анализа требований и проектирования системы!!!!

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

Системные сервисы.

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

Рамки системы можно моделировать с помощью диаграммыконтекста. В пояснениях к диаграмме контекста должны быть четкоопределены рамки системы. Без подобного определения проект не можетбыть застрахован от попыток «растянуть» его рамки.

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

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

Системные ограничения.

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

1) требования к интерфейсу;

2) требования к производительности;

3) требования к безопасности;

4) эксплуатационные требования;

5) политические и юридические требования.

Требования к интерфейсу определяют, как система взаимодействуетс пользователями. В документе описания требований определяется только«впечатление и ощущение» от GUI-интерфейса.

Начальное проектирование (закрашивание экрана) GUI-интерфейсапроводится во время спецификации требований и позже во времясистемного проектирования.

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

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

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

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

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

Значение выработки недвусмысленных определений для системныхограничений трудно переоценить. Существует немало примеров проектов,которые провалились из-за упущенных или неверно понятыхограничений. Эта проблема в равной мере относится как к заказчикам, таки к разработчикам. Недобросовестные или нерассудительныеразработчики могут разыграть «карту системных ограничений», чтобыполучить преимущество в своем стремлении уклониться отответственности.

Проектные вопросы.

Заключительная часть документа описания требований обращается кдругим проектным вопросам. Один из важных разделов этой частиназывается «Открытые вопросы».

Здесь поднимаются все вопросы, которые могут сказаться на успехепроекта и которые не рассматривались в других разделах документа.

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

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

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

Приложения.

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

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

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

Пример документа описания требований