Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 34
Текст из файла (страница 34)
° В сложных системах созда»ется спсцификаци»» требований для каждой подсистемы. Требования необходимо записывать и документировать. Если вы в одипочлу разрабатываете систему, в которой будете сдипствеппыл» пользователем и ответственным за с»ь провов»денис, можно попытаться приступить к ее проектированию и кодированию непо.
средственно после выявления своих потребностей. Однако разработка систем редко бывает столь простой. Как правило, разработчики не являются пользователями, а в процесс разработки вовлечены заинтересованные лица, пользователи, разработчики, аналитики, специалисты по архитектуре и другие члены команды. Все участники должны прийти к соглашению о том, какая система должна быть создана.
Реалии бюджета и графика таковы, что в конкретной версии вряд лн возмоааю удовлетво. рить все потребности пользователей. В любой деятельности, в которой участвует много лю. дей, неизбежно возникают проблемы взаимодействия. Поэтому необходимо создать документ, с которым мо»ут сверяться и на который могут ссылаться все участники. Такой документ называется спецификацией требований. С»»ецифихац»»я в»Ребоепни»» к системе (ил»» приложению) описывает се внев»нее поведение. Замечание. Следуя исторической традиции, мы будем использовать в данном разделе термин докул»е»»я», по требования могут храниться в виде документа, базы данных, мо. дели прецедентов, архива требований или комбинации этик элементов, Как будет показано далее, для хранения данной информации можно использовать "пакет требовании к программному обеспечению".
Существует ряд причин, из-за которых требования редко удается определить с помощью единого однородного документа. 170 Часть В. Определение системы ° Система может быть очень сложной. ° Потребности заказчиков люгут быть документироваиы до того, как производится документирование подробных требований. ° Система может быть членом семейства родственных продуктов.
° Создаваемая система может удовлетворять только некоторое подмыожество всех выявленных требований. ° Цели маркетинга и бизнеса следует отделить от подробных требований к продукту. В любой из зтнх ситуаций приходится вести множество документов. Рассмотрим но сколько специальных случаев. ° Некий "родительский" документ определяет требования ко всей системе в целом: к аппаратному и программному обеспечеыию, персоналу и процедурам; а другой документ — только к програмлтному обеспечению. Первый документ называется стмци. фвсацией тфебоеаний к аизпеме (зузитп ждшгепмти фесфсайоп), а второй — спецификацией ттфебоеаний к глрофоммнозеуобжпечению(юяшатептуштетегафеаЯагютк ЯБЛ ° Один документ содержит общие определения функций системы, а другой — более коыкретыые.
Первый документ часто называется документом. концепцией ()тшоп Иопапеп1), а второй — спецификацией т(тебований к п~юфаммному обеспечению (зоутшаге теди (тетепт треп)1сагтоп). ° Один документ содержит полный набор требований к семейству продуктов, а в др)том представлены требования к коыкретному приложению и конкретной вер. сии. Первый из них именуется документом «фебооокий х семейсюеу тфодукмое (ртобистуапи(у гедитгеюептз), или концепцией сеиейсттюа п)юдуклчое (рюдисс )аюйу (гиюп боситепт), а второй — спецификацией требований к п)тофаммному обеспечению (зо)(шаге тедийептепй фест((сараи) определенной реализации ыекоего коыкретного приложения из семейства продуктов.
° Один документ описывает общие бизнес-требования и бизнес. окружение, в коттт ром будет существовать система, а другой определяет ее внешнее поведение. Первый называется документом бизнес-ю(тебоеаний ((чм(гшзз теди(гетептз т(оситпепс), или докуменмом пфебоеангзй мтфкетпинга (ппгйатпе тедистепшпп Иосипитц), а второй — стмцнфикацией тфебоеаний к тфофаммному обеспечению (зоЯшате теди (тетепт фесцкапоп). В следующих разделах описывается, что делать в каждом случае. Эти случаи можно комбинироватлх например, некий докумеит может наряду с бизнес-требованиями содержать полный набор требований, из которого отбираются подмножества и используются для конкретных версий.
Организация требований к сложным аппаратным и программным системам Хотя данная книга посвящеыа, в основном, требованиям к программыому обеспечению, важно понимать, что они являются только подмножеством процесса управления требованиями при разработке большинства систем. Как уже описывалось в главе б, некоторые системы настолько сложны, что единственным разумным способом их визуализации н создания является представленые в виде систем, состоящых из подсистем, которые Глава 16. Организация информации о требованиях 171 в свою очередь также являются системами подсистем, и т,д., как показано на рис, 16.1, В экстремальном случае, когда система представляет собой, лгаприлсер, авианосец, она мсл жег состоять из сотен подсистелц каждая из которых в свою очередь имеет компоненты аппаратного и программного обеспечения.
Вес. 1б.1. Система, сеааеллзае ие ведсистем В таких случаях создается спецификация требований системного уровня, которая описывает вневзнее поведение системы в целом (без учета ее разбиения на подсистемы), такое как запас топлива или скорость набора высоты. Как уже отмечалось в главе 6, после согласования требований к системе в рамках систелшой инженерии производится разбиение системы на подсистемы, подробно описываются интерфейсы между ними, и каждое требование системного уровня размещается в одной или нескольких подсистемах. Полученнал в результате системная архитектура описывает зто разбиение и интерфейсы между пол) лениылзи подсистемами.
Процесс проектирования систелзла салз по себе создает новые классы требований. Затем разрабатываются спецификации требований для каждой нз подсистем. Этн спецификации должны полностью описывать внешнее поведение подсистем (без зчета нх разбиения на подсистемы следующего уровня). Данный процесс приводит к возникновению нового класса требований — производных требований. Требования этого повози типа описывают уже внепшее поведение не системы (разве что в агрегированном виде), а иаетс подсистемы. Таким образом, процесс цроектнрования системы создает новые требования для подсистем, из которых состоит система. В частности, интерфейсы между этими подсистемами становятся ключевымн требованиями: они представляют собой, по сути, контракты между подсистемами илн обеи1ания функционировать так, как условлено.
После того как эти требования согласованы, люжно при необходимости продолжить проектирование системы путем разбиения каждой из подсистем на подсистемы след)ющего уровня и разработки спецификаций требований для каждой из пнх. В результате полз лается иерархия спецификаций, представленная на рнс. 16.2. На каждом уровне требования предыдущего уровня размещаются в соответствующих спецификациях более низкого уровня.
(Например, требование, касающееся запаса топлива, размещается в подсистемах управления топливом и хранения топлива.) Также выявляются и соответствующим образом описываются новыс требования. 172 Часть 3. Определение системы Спецификация требовании ксистеме в цвлом Спецификация Спецификация Спецификация сисгемныхгребоеаний сисгемныкгребований системныхгребоааний для подсистемы А для подсистемы В для подсисгеыы С Спецификация Спецификация Спецификация сисгемныхгрвбоеаний сисгемныхгребований сисгемныхгребований для ПодсисгемыА-2 для подсисгемы С-1 лля Псдсисгемы С-2 Спецификация системныхграбований для подсистемы А-1 Рис.
16.2. Иейайхнл снемификоций, полученная е уса)ы втоте нйосюииуоеанил смсгленм Спецификация грабований ксистеме в целом Спецификация Спецификация сисгемныкгребований сисгемныхгребований для подсисгемыд для пцдсисгемы В Спецификация системныхтребований для подсистемы С Спецификация Спецификация Спецификация Спецификация сисгемных требований сисгемных гребований сисгемныкгребований сисгемныхгребований для подсистемы А-1 для подсистемы А-2 для подсистемы С-1 для подсистемы С.2 Спецификация Спецификация гребованнй каппарацгре программныкгребаваний для подсистемы А-2 дгн подсистемы А-2 Рис.
16.3. Иеуо)гнил Рсеулнянйугочйих спецификаций, и иом числе аппаратного н нрогралачнахо уровней Как показано на рис. 16.3, спецификации, которые в свою очередь уточняются до. полпитсльпымп спецификациями подсистем, называются сггснификаииллггг сисиимггмх ггргбоепгггггг (или спецификациями требований системного уровня).
Спецификации самого пнжнсго уровня — тс, которые нс подвергаются дальнсйгпей декомпозиции, — как правило, соответствуют только аппаратным или программным подсистемам и называются пийгг31ггкпгггнкнгг трсбоеанггй к ппппрлюнлму или ггрок)вамнному обетечеггию соотвстствсн. по. 11о лгсрс того как становятся более понятны детали, каждая из приведенных иа ргю. 16.3 спецификаций может подвергаться эволюционным процессам. Глава 16. Организация информации о требованиях 173 Организация требований к семействам продуктов Во многих отраслях разрабатываются семейства продуктов, имеющих много общих функциональных возможностей.
Но каждый из них обладает и некоторыми уникальными свойствами. Примерами таких семейств могут служить системы управления складами, автоответчики, противоугонные системы и т.д. При создании набора программных продуктов, которые имеют пскпс общие функциональные возможности и потребность в совместном использовании данных или в обмене информацией друг с другом в процессе работы, можно попытаться использовать следующий подход. ° Разработать документтонцепцию семейства продуктов, который описывает спосо.
бы совместной работы продуктов и их общие совместно используемые функции. ° Для более полного понимания модели совместного непользования можно также разработать набор нугвцедвнпюе, показывающих, как пользователи будут взаиыодсйствовать с различными совместно выполняемыми приложениями. ° Разработать спецификацию тРебвепнпй и обп1ему нрозранмпаму обеспечению, определяющую конкретные требования к общим функциональным возможностям, таким как структуры меню и коммуникационные протоколы. ° Для каждого продукта семейства разработать документ-концепцию, спецификацию т~ебованпй к нУюгфальлпо.иу абвс~и мнпю и зшдсвь пфвцедептов, определяющие его конкретпыс функциональные возможности.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
