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

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

Понятно, что эта дисциплина носит достаточно общий ха. рактер, и необходимо продемонстрировать определенную избирательность, чтобы приводимые сведения октзались полезными для членов кол>анды, разрабатывающей программное обеспечение. Поэтому основное внимание будет уделено процессу управления требованиями и соответствующим методам, которые можно непосредственно при. менять цри разраоотке зяачипмлы>мх я?>ог?>аммных >ф>ь>ежеля», относя>вихгя к яп»шз> ?~IТ,?б>' хэ я>ро > ммсис > аз>. Наш маршрут Так как пам предстоит э?>ямках олмедеяяого фока и бк>джепш 1>азГ>пбоя>ая>ь хг>хеся>эе»»ое ярофомжно> юбеслечениг, удоэлгя>во?>яю>эее?эгаль»ме яов>?>гбиос»гя клиентов, было оы полезно иметь "карту территории".

Задача достаточно сложная, если учесть, что на этом пути нам попадется множество людей, говорящих на самых разных языках. Может возникнуть множество вопросов. ° Это потребность или требование? ° Это то, что "хорошо бы иметь", или то, что "должно быть" ? ° Это постановка задачи или же речь идет о формулировке решения? ° Это — цель системы нли одно из условий контракта? ° Действительно ли нужно программировать ца языкеуача? И кто будет это делать? ° Коьп это не нравится наша новая система и где был этот человек, когда мы прихо. дили сюда раньше? Для успешного продвижения нам в любой момент времени необходимо четко понимать, где мы находимся, с какими людьми встречаемся, на каком языке они ~оворят и какая информация нам нужна от них для успешно~о завершения нашего путешествия.

Да. вайте начнем движение с территории под названием "проблема". Область проблемы Ншк>олсс успсшныс пуген>ествия в "стране т?>сбований" начинаются с а>масяпг в?я>бгсг>ьс Это — вот инга реальных пользователей и других за>ппсресованных лиц, чьи потребности мы должны удовлетворить, чтобы построить совер>венную систему.

Это вотчина людей, которым нужен "камень" — новая система ввода заказов нли система управления конфи>урацией, кот>ь рая позволит нм обойти конкурентов. В любом случае эти люди не похожи на нас. Их тсхни. Глава 2. Введение в управление требованиями 45 чсскис и экономические познания отлп внотся от папшх, оип говорят смеяшымп архаизм;вш, ходят на другие вечеринки и пьют др1тое пиво, опи пе падов>пот тепшккн, ндя па рябо>у, и их лютивацня кажется нам странной и непонятной. Иногда это ь>о>уг быть программисты, которым понадобилось новос ипструмспталь.

пое средство, илп разработчики системы, попросив>нис пас разработать пскук> се часть. В этих случаях данная часть нашего путе>поставя э<ел<ел> оказаться проще (по может ока. заться и сложнее!). Но, как правило, мы находимся во злю<опиях пользователя-чужестранца. У пол> зоватслсй есть внхиичггкие или б<зиегюдпчи, для решения которых пм нужна пшяа помощь. 'Гам>м обра.

зом, ишки задача состоит в том, чтобы г>опять пх проблсмь> в их предметной <яиянтп и пз их языке и построить системы, удовлетворяю>цие их потребности, Поскольку эта территория кажется пам несколько туманной, лпи будем изображать сс ., -~ ..'Ялф~ в виде <юлака. Это будет служить пам постоянным пшяжшпшшсм, чтооы мы пе забылн удостовсрптьсв, что правильно попили все аспекты предметной области. Обозе>ь проблемы В этой области л<ь> должны использовать ряд пРофеггпоипльиь>х ийиечап (Г<гпи >МП<), чтобы поили>ь иу>облему, хотоРил должиа бь»иь Рек<енп. Потребности заинтересованных лиц Мь> также должны понять потребности пользователей п других запп гсрссованных лиц, на чью жизнь повлияет наше ре>пеппе. Г1о мере выявления мы ооразуем из этих потребностей заиптсрьсоваппых лиц кластер, который будем представлять в виде небольшой пирамиды. Переход к области решения Путе>пествие по проблемной области пс всегда оудет сложпыч, а собр;пшьж там артефактов будет пс так уж иного.

Однако даже этого псболывого количества данных пам хватит для следу>ощсй ч;юти па>пего путешествия, к которой л<ы, пожалуй. подго'говлспы лучше, — решения поставленной задачи. В области решения мы уделяем основное шшмание определению решения проблемы клиента; это сфера компьютеров, программирования, операционных систел>, сетей п функциональных узлов, Здесь мы можем поп<>средственно применять свои профсссиопальпыс навыки. Функции системы Первым делом полезно сформулнровзт>..

что мы узнали в проблемной <я>ласти н как собираемся этого достичь посредством реп>синя. Это буд<т небольшой список. состоящий пз элементов следующего вида. ° "У автомоопля б> д<т автоматические стеклоподьсмппкп ° 'Яиаграь<мь> дшшмикн обнаружения неисправностей оудут гнябжспы вн.>ум>он<»- ми средствами оценки прогресс,>" ° "Необходимо предусмотреть возможность ввода заказов через 1п<с> пе<" ° уАвтоматпчсский цикл двойной сварки" 46 Введение Это просто описания на языке клиента, которые мы будем использовать в качестве ярлыков, чтобы пояснить заказчику, как нагла система ревзает его задачу. Они стануг ча.

ч стью нашего повседневного языка, и много сил будет потрачено на их оп» ределение, обсуждение и расстановку приоритетов. Эти описания мы назовем "Янкциями" (/еазигвз) создаваемой системы и определим их следующим образом. Функция- вто н)ггдоставллвмве системой обслуживание двя удвьывэмв)гения одной иви нескольких нвт(звеневшей заинте(гвсо ваннмхлиц Графически функции будут представляться как основание описанной ранее пирамиды потребностей. Требования к программному обеспечению После того как определен набор функций н достигнуто соглашение с клиентом, можно переходить к определению более конкретизированных требований, которым должно удовлетворять решение. Построив систему, удовлетворяющую этим требованиг я ям, люжно будет с уверенносп,ю утверждать, по она предоставит обе.

я г я щанные функции. В свою очередь, поскольку функции предназначены для удовлетворения одной иаи нескольких потребностей клиента, эти Ф потребности будут непосредственно удовлетворяться решением. Ю я г в Этими более конкретизированными требованиями являются яцзебования к нРогРаиинаиу вогснвчвнггю (зоЯтагв га)игтямигз).

Мы бчдем прелставлять их в внле части пирамиды аналогично представлению ~вйвф8иййые функций. Отметим, что они находятся в пирамиде гораздо ниже, и это означает, что нам придется проделать немалую работу, прежде чем мы достигнем этого уровня детализации. Понятие прецедентов Наконец, еще одной важной конструкцией, которая поможет нам в нашем путешест. вии, является гфгцедент (изе сазе). В простейшем случае прецедент описывает пвслгдвватгльнвсть действий, выполняемых агплемой, чтв6м п(мдвставить значимый результат пользователю. Другими словами, прецедент описыасвеианиеи вает серии взаимодействий пользователь/система, в результате кс» торых пользователь решает некие свои задачи. Мы будем изображать прецедент в виде простой овалыюй пиктограммы, содержащей его название. Например, если мы хотим описать прецедент, когда клиент использует компьютер просто для включения илп выключения света, его люжно назвать "Управление освещением" и поместить это название в овал.

Заключение Посмотрим теперь на составленную нами карту. Из рис. 2.1 видно, что в процессе обсуждения мы незаметно совершили очень важное продвижение в нашем понимании задачи. Мы перешли от представленной облаком области проблемы и выявленных нами Глава 2. Введение в управление требованиями потрсбцостсй клиентов к образующему область решения определению системы, представленному функциями системы и требованиями к нрограмлшому обеспечению, согласно которым будет выполняться проектирование и реализация системы. Более того, мы осуществили этот переход логично и постепенно, црсдваритсльио удостоверившись в том, что осознали проблему и потребности ноль:юватсля, и лишь затем иристлшв к рассмотрению и опрсдслсишо решения. Эту "карту территории" мы будем сщс нс раз использовать в данной кшщс.

ЯЪс. 3. 1. Харакягериоиииа обеаоии ироблеим и области реимния Глава 3 Команда разработчиков ")))юг)>езьвн)>сопл не хом яькнве)я< — гфе)>а дел нш< ьнотзн человека. )Во«яб<у>д )971) Основные положения ° Управление требованиями. хотя и по-разному, затрагивает каждого члена команды. ° Успешное управление трегюваниями может осуществлязь только хорошо организованная команда разработчиков программного <>бссцсчения. И ))дя управления требованиями команде необходимо овладеть професси<» нальными приемами в шести основных областях. 11рнчпны, по которым человек решает посвятить свою карьеру разработке программного обеспечения, ь<о<уг быть разлцчными.

11скоторыс на штзл>шь журналов "Роро)аг бг>спсс" и "1'орн1аг МесЬап)сз", увлеклись курсом программирования еще в старших классах школы, специализировались в инженерных днгцпплнпах нлп информатике в колледже и таким образом направилн свою жизнь по этому особому техническому пути. Для др)тнх это произошло само собой; наст)пил таком момент, когда возникла очевидная потребность в программном обеспечении, опи приняли участие в разрешении этой потребности и постенс<шо оказались <юлностью вовлеченными в работу в данной отрасли. В любом ел< <ас именно "очарование" технологии поддерживает горение пламени: лам н)ювялмл биты и балты, ояг)>внято<<<с сисяммы, база< данных, г)>едтяел )>яз)>обоз<хи, хо)ютхве недпляяоехи к языко я)юг)><а>ыо<)>ово»<о<.