Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 35
Текст из файла (страница 35)
Полученная в результате организапия требований представлена на рис. 16.4. Рис. 1б.4. ОРганизацив тРвбввапий длв семвйппва пРовРшанпьт пдвд1ттвв 174 Часть 3. Определение системы Спецификации требований для отдельных членов мокнут содержать ссылки (соязи ияи тРосси,ковки) на документы семейства нли могут воспроизводип все требования данного дщ кумента. Преимущество использования ссылок состоит в том, что изменения в требования, относящиеся ко всем членам семейства, можно вносить в одном месте. Но для управления этими эависнмостяии понадобится некое автоматическое средство управления требованиями; в противном случае каждый рэз при изменении родительского документа вам придется само.
стоятельно анализировать все документы требований отде тьных членов семейства. "Будущие" требования При разработке мы крайне редко имеем дело с постоянным набором требований или можем построить систему, удовлетворяющую вселю известным требования«« В любом процессе выявления будут возникать требования, которые окажутся неприемлемыми для разрабатываемой в данный момент версии создаваемого продукта.
Было бы неправильно включать такие требования в спецификации требований (не должно быть никаких сомнений относительно того, какие требования должны быть реализованы, а какие — нет). С другой стороны, неправильно было бы отбрасывать их, так как они представлякзт собой полезные рабочие продукты; мы сможем использовать их при создании последующих версий. Еще более важно то, что проектировщики могут иначе разработать проект системы, зная, что в будущем возможны требования определенного типа. Лучше всего записывать оба типа требовэний в документ, но необходимо четко выделять ае кз кок, кото(зые планируется реализовать в ямкущей версии.
Оличие бизнес-требований и требований маркетинга от требований к продукту Планирование нового продукта не производится в чисто технической среде беэ учета бизнес. соображений. Необходимо подумать о целевых рынках, оформлении продукта, каналзх распределения, функциональных возьюжностях, затратах на маркетинг, доступности ресурсов, прибьсаи, возможности возмещения затрат путем продажи большого количества копий и т.д.
Эти соображения следует задокументнроватгк но они не являются частью спецификаций требований. Некоторые организации используют докулмко~ треооеанай лгаркежиига (тогйейля гег(к(гемен~ доситеиб МЯВ), чтобы упростить общение между ру«оводством, службой маркетинга и разработчиками и помочь в принятии разумных бизнес-решений, в том числе самого важного решения "делать, не делать".
М«Ш также предоставляет за. казчикам н разработчикам воэможность очень ранней верификации взаимодействия, что способствует пониманию продукта в его наиболее общем виде и определению общего масштаба продукта. МИз отвечает на следующие вопросы. ° Кто является закаэчиком? ° Кто является пользователем? ° На каких рынках предполагается продавать продукт? ° Как поделены эти рынки? ° Различаются ли требования пользователей в различных сегментах рынка? Глава 10.
Организация ииформацми о требованиях 175 ° Какие классы пользователей существуют? ° Какие потребности удовлетворяет продукт? ° Что это эа продукт? ° В чем заключаются основные преимущества продукта; почему его будут покупать? ° Что собой представляют конкуренты? ° Что отличает продукт от конкурирукнцих продуктов? ° В какой среде будет использоваться система? ° Какими будут затраты на разработку? ° По какой цене предполагается продавать продукт? ° Как будет осуществляться инсталляция, дистрибуция и сопровождение продукта? Рабочий пример Докумвнг-концепция системы Н005 2000 Модель прецедентов системного уровня НОНЯ 2000 Спацификюции аппцмтного обвспвнвння подсистемы Управление енночвнием ценльтльныя блок управления Пк-программатор ктгс.
165. Организации ингуергпак ни о требоеаннлл к снонвне НОйвБ В главе б мы провели некие действия по разбиению системы НО1.Б (системы автоматического домашнего освещения) на подсистемы. К настоящему моменту мы не так уж много знаем о НО1.Б, но все же этого, вероятно, достаточно, чтобы предпринять первую попытку оргмпьтовать имеющуюся информацию о требованиях. На рис. 1б.э показано, что команда при описании требований к системе НО1.Б использует следующие элементы. !76 Часть 3. Определение системы ° Докуменггг-конйгггйгггл, который содержит краткосрочные и долгосрочные концепции Н01.15, в том числе основные требования системного уровня и предлагаемые функции. ° Модсгь гг)ггйсдеклгов снекма<ного )угооня, которая содержит прецеденты, с помощью которых различньлс акторы системы взаимодействуют с НО1.15.
° После некоторых дебатов команда приняла решение документировать требования к аппаратным компонентам (разгяер, вес, мощность, упаковка) всех трех подсистем системы НОВ15 в единой след!ии т)ггбооаяий к алло)гатному обгшичению. ° Так как в каждой из подсистем НО!.15 достаточно много программного обеспечения, комацда решила разработать для каждой из трех подсистем отдельную сленифпкадию ог)ггбооакгш к ггрограммкому обеспечению, а также модель ггредедентов, отражшоньую, как каждая подсистема взаилюдсйствуст с различными акторами. Дальнейшую разработку данных артефактов требований можно будет наблюдать при продолжении изучения рабочего примера в последующих главах.
Их образцы приводятся в приложении А. Заключение В этой главе мы рассмотрели разнообразные документы требований для систем разной сложности. Но в большинстве случаев разработка требований производится для отлсльноп подсистемы программного обеспечения, упакованного программного продукта илп отдельного приложения. Это может быть программный продукт, разработанный независимым производителем программного обеспечения, такой как М!сгозой Ехе1, Кайопа! С!еагСазе, нли система управления освещением НО!.15. В следующих нескольких главах мы подробно рассмотрим процесс определения требований лля отдельного программного приложения и таким образом продемонстрируем, как пс практике осуществляется процесс управления требованиями.
Глава 17 Документ-концепция Основные положения 1 ° Документ-концепция (Ъгтк(оп босшпепк) описывает приложение в целокт, включая описания целевьпк рьпшов, пользователей системы и футтюгий приложения. ° Документ-концепция определяет на наивысвтем уровне абстракции как 'проблему, так и решение. ° Практически все программные проекты выигрюот от наличия документа- концепции. И Документ 1)е!та ЪЪ(оп акцентирует внимитие на том, что изменилось.
Данная глава посвящена рассмотрению документа-концепции. Наш коллега Филипп Крачтен (Р)т11!Рре КпксЫеп) как-то сказал: "Если бы мне разрешили разработать только один документ, модель или другой артефакт для поддержки программного проекта, я бы выбрал краткий, хорошо сформулированный документ-концепцию". Документ-концепцил сочетает в себе некоторые основные элементы дону мента маркетинговых требований и документа требований к продукту.
Нам необходимо разработать этот конкретный документ по двум причипаък. 1. Каждому проекту нужен документ-концепция, 2. Это поможет нам в демонстрации процесса работы с требованиями поскольку некоторые ключевые элементы данного процесса будут за писаны в этом документе. Доктмеит. коицепцип моего проекта Документ-концепция описывает приложение в общих чертах, а также содержит описания целевых рынков, пользователей системы и функций приложения.
Мы неоднократно имели возможность убедиться в его полезности, и у пас стало уже хорошей традицией разрабатывать его при определении любого программного приложения. Компоненты документа-концепции Документ-концепция — это важттейший документ программного проекта, который фиксирует потребности пользователя, функции системы и другие общие требования к проекту. Сфера действия документа-концепции распространяется на два верхних уровня пирамиды требований. Таким образом, он описывает на высоком уровне абстракции как проблему, так и рептение. 178 Часть 3. Определение системы Мэселеб документе.концепции Сфе)за диаяммя Йитуменяизкенкяяянн Документ концепция программного продукта также служит основой для достижения с<и гласия между тремя основными внутренними сообществами заинтересованных лиц проекта. 1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
