Принципы работы с требованиями к ПО. Леффингуэлл (2002) (Принципы работы с требованиями к ПО. Леффингуэлл (2002).djvu), страница 88

В некоторых случаях пакет Мог(сгп 5Ю может прслставлять собой один или несколько документов, для которых даиная схема служит ото правиой точкой. В других с.ту ~аях ои является логической конструкцией, которая может состоять из единственного физического документа со ссылками иа другие, основав пые иа моделях и инструментальных средствах (()М(=модели, прецеденты, архивы спсциальиых средств работы с требованиями и лр.), физические представления данных. Название компании Название подразделения (если нужно) Название проекта Номер документа спецификации требований к программному обеспечению (если нужно) © 1999 Название компании История изменеиий Дата Описание Автор ерсия игсло/кгссгщ/ток 1!ьщ автора Исхолпая вс)к вя 412 Приложения Содержание 1.

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

Мася<таб Данный раздел содержит краткое описание программного приложения (функций илн подсистем, на которые разбита система), для которого создается спецификация; кроме того, описывается, с какой моделью (моделями) прецедентов оно связано, а также вес остальное, на что ом<зываст влияние данный документ. 1.3. Ссылки Список ссылок или прилагаемых документов, связанных с данным проектом. 1.4. Предположения и зависимости В данном разделе описывается техническая достнжимость, доступность подсистем или колшонснтов и др)тие предположения, от которых может зависеть жизнеспособность описываемого данной ЯРВ программного обеспечения.

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

(Здесь следует поместить диаграмму людели прецедентов а целом.) 3. Характеристика акторов Здесь описываются вес упомянутые в характеристике модели прецедентов акторы. Для каждого актора следует указать след)ющее. ° Имя ° Краткое описание 4. Требования 4.1. Функцию<альные требования В данном разделе описываются функциональные требования к системе, выражс<ниле на естественном языке, Для многих приложений это достаточно объемная инфорт<ация, и следует продумать, как организовать данный раздел.

Как правило, его оргапиз)лот по функциям, но можно применять и другие методы, например по пользоаателял< илн подсистсмач. Приложение В. Образец пакета Мойегп $В8 Рас)сабе 413 При использовании для сбора функций вспомогательных средств разработки приложений (инструментзльных средств разработки требований, средств моделирования и т.д.) данный раздел документа будет содержать ссылки иа зти дщгные и указывать местоположение и название применяемого для сбора данных инструментального средства. Нефункциональные требования Болыная часть нефункциональных требований обычно записывается на есте.

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

° Требования соответствия общепринятым стандартам практично. сти, таким как С()А 1ВМ или опубликованные компанией М)сгозой стандарты СО)для системы )ч')пдопз 98. Более подробная информация содержится в "Билле о правах пользователя" в главе 23. 4.2.2. Надежность В данном разделе указываются требования к надежности системы. ° Доетунноснгь Указывается, какой процент времени система доступна (хх.хх%), определяются часы использования и дост)па для абслужиыния, операции при ухудшении параметров системы и т.д, ° С?идите в)эемя мели)у оожозами (теин бте беивееп~аИигеь МТ1)г). Обычно выражается в часах, но может )хазываться в днях, месяцах и годах. ° Среднее врача восснюновлениа (теин бте Ю гфниг, М?Т??):.

Сколько време. ни система может находиться в нерабочем состоянии после сбоя. ° Точность. С поьющью некоего известного стандарта указывается требуемая точность (рюревгающая способность) выводимой системой информации. ° Монгол~илько допустимый ковффициензг ожибон и дефектов. Как правило, выра'кается как число ошибок, приходящееся на КЕО8 (тысячу строк кода), нли число ошибок, приходящихся на отдельную функцию. ° Доля ошибок или дефекнюв ?наличных тинов. Обычно ошибки разбиваются па следующие категории: незначительные, серьезные и критические. Требования должны определять, что понимается под "критической" ошибкой (такой, как полная потеря данных или ие- 414 Приложения возможность испольэовать определенную часть функциональных возможностей системы).

4.2.3. Производительность Здесь описываются характеристики производительности систелгьг. Следует указать время ответа для различных ситуаций. Если требуется. указываются названия соответствующих прецедентов. ° Время ответа для транзакции (среднее, максимальное) ° Пропускная способность (транзакций в секунду) ° Емкость (число пользователей или транзакций, которые может об. служить система) ° Режимы снижения производительности (допустимые режимы работы при ухудшении параметров системы) ° Использование ресурсов (память, диск, каналы связи) 4.2.4.

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

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

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

8.1. Интерфейсы пользователя Описываются интерфейсы пользователя, которые должны быть реализованы програмлгным обеспечением. Приложение В. Образец пакета Мобегп Бйб Расаабе 415 8.2. Аппаратные интерфейсы Определяются все аппаратные интерфейсы, поддержку которых должно осуществлять программное обеспечение, в том числе логическая структура, физические адреса и ожидаемое поведение. 8.3. Интерфейсы программного обеспечения Описываются программные интерфейсы с другими компонсптамн системы программного обеспечения. Это могут быть закупаемые компоненты, повторно используемые компоненты другого приложения или компоненты, разработанные для подсистем, не описываемых данной БЙ5, по с которыми данное программное приложение должно взаимодействовать. 8.4. Коммуникационные интерфейсы Описываются все коммуникационные интерфейсы с др)тими снстемамп или устройствами, такими как локальные сети или удаленные последовательные порты.

9. Требования лицензнроваввя Определяются все требования лицензирования или другие ограпичнвакнпне использование требования, которые оказывают влияние на програмзпюе обеспечение. 1О. Замечания, касакнцнеся законности, авторских прав н т.д. Описываются все необходимые гарантии, все отказы от ответственности, отметки оо авторском праве, торговой марке или вопросы соответствия логотипу для программногообеспечения. 11. Првменяемые стандарты Посредством ссылок ухэзываются все стандарты (а также конкретные их разделы), конт рые примеюпотся к описываемой системе.

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

Глоссарий Здесь описываются все термины данного приложения, а также все определения н принятые в проекте или компании сокращения, которые необходимы для понимания данного документа и приложения. Приложения В данный раздел следует включить все необходимые приложения. Ниже представлен образец приложения, который демонстрирует, как записывать прецеденты. Вы можете включать столько приложений, сколько сочтете нужным. Приложенве. Спецификации прецедентов Лапное приложение содержит подробное описание прецедентов систелпа. Предлагаемый ниже образец может служить отправной точкой. 416 Прнлолсения История изменений Описание Автор Дата ерсия 1.0 число/месяц/год Игхолная версия Имя автора Отметим, что история изменений приводится для каждого прецедента, включенного в приложение.

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