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

° ПРотогггггггы иггпыРфп1са ггальзовамеел, ргарабатываелгые для получения реакции различных заинтересованных лиц. ° Рласаг)лт, который содержит опрелеления используемых в да гном ггроекте терминов В данном рабочем процессе у гаствуют следующие сотрудники. ° Заггггпге)гесавггнные лица, заказчак, конечныи пользователь; тот, кто играет для орга. низации-разработчика роль поставщика исходной информации для процесса разработки требований (ггаприыер, это может быть менеджер по маркетингу). 430 Приложения 'Типы" требований Потребнтсти пользователей онцепция 1 Требования кпротраммноыу обеспечению Запросы заинтвресова пиц Требования проектирования/ тестирования/ документирования и матязиалы Модель Модель юнвч ното попьзоввтеш, проектирования тестирошння а таска учебные материалы Рве.

Д.3. Рабочий «Рояесс разработки нт/мбоеаний ° Сисиидтттый аналитик, который осуществляет руководство и координацию действий по выявлению требований и моделированию прецедентов, определяя функции и очерчивая границы системы; например, он устанавливает, какие существуют акторы и прецеденты, как они взаимодействуют, а также задает нефункциональные требования и ограничения проектирования.

° Составитель тет/ификлций н~ецедентое, который составляет подробную спецификацию некой части функциональных возможностей системы, описывая аспект требований одного или нескольких прецедентов. ° //Роектттироеи/итс инвм/тр)айса яольтоеавмвл (Ш), который разрабатывает расиадровки прецедентоп и прототипы Ш и привлекает других участников к их оценке.

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

Принципы управления требованиями в йанопа1... 431 Анализ проблемы Как видно из рмс. Д.З, задача данного подпроцесса состоит в следующем. ° Создать документ-концепцию проекта ° Согласовать функции и цели Меюдичвспю Гюссарир Заизчж О Заинтересованное лицо Модель прецедентов Запросы (тальке акторы) эаинтврвсоавннык лиц Рыс. ДЗ. Анализ проблемы К данному подпроцессу можно несколько раз возвращаться в фазах качала и раннего исследования. По мере более четкопт понимания эатфосое заинтересованных лиц будут эволюционировать как решения, касающиеся бизнес-процессов, так и технические решения. Основная деятельность данного подпроцесса состоит в разработке дохумгттои.

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

4ЯЗ Приложения Понимание потребностей заинтересованных лиц Задача данного подпроцесса состоит в сборе информации от заинвефесоеаннмл лнц ироекпш (рис. Д.4). Собранные запросы заттнтересоеанных лин могут рассматриваться как "список пожеланий", который можно использовать в качестве исходной информации для определения зтадгли тт)ветведенжое, пртпвздентное и дополнинтгльттых сиетзификацттй. Как правило, этот подпроцесс выполняется только в итерациях фаз начала и ттссчедоеания. Методические Глоссарий Кон ечн попьзо Заинтере пи Запросы Методические Дополнительные Дтйибу™ заинтересованнык Указание спецификации требований пиц по моделированию (набросюй) прецедентов Рнс.

тз.4. Понимание иоифебнеояит зоинтересоеанныз.тик Главная деятельность заключается в выявлении запросое заттнтперссоваттттмз лнц. Основной результат — коллекция упорядоченных по приоритету затт)Вагап запнпм)оссоеанттыллнц, что дает возможность уточнить документ-контветттдттю, а также лучпте понять атрттбуты тп~ябоеаттттй. В рамках данного процесса можно также начать обсуждение системы, нс- ПриложениеД. Прянципы управления требованиями в Канопа(... 433 пользуя тфвведвиьчм и акюфы.

Еще одним важным результатом является обновленный глоссарий который служит общим терминологическим словарем членов команды. Определение системы Задача этого подпроцесса (рис. Д.б) заключается в следующем. ° Достичь единого понимания системы командой проекта ° Выполнить высокоуровневый анализ результатов сбора затфиив заинтнврвсова нных лив ° Более форьтально документировать результаты в виде моделей и документов Как правило, это выполняется только в итерациях фаз начала и исследования. Зеортхы Методнческне ((птьрпцне указентн Молельпрецеаентое Атрибуты ебоеа А нбуты 3 ьчний (уточненные) Дополнительные соецифнвацнн (неброскй] г рна (уточненный) модель орецелрнтое (уточненное) Рис Д.5. т)тфедеевиив атпаеиы Управление масштабом проекта Задача данного подпроцесса (рис. Д.б) состоит в следующем.

° Определить исходные данные для отбора афебований которые включаются в текущую итерацию Процессы анализа тфобвгмм н понимания поятРвбиостей заинтфесованнмх лик приве дят к созданию ранних итераций ключевых определений системы, я том числе дохулмть та-хонйепнтти, первого наброска модели юфвиедвттвюв, а также аафибутов требований При определении систеьты основное внимание уделяется более полному определению ахмо (Рави тфецедвниюв и разработке донолиипильных стмттттфикаций 434 Приложения ° Определить набор функций и тфвцвдвнтов (или сценариев), представляющих наиболее важные функциональные возможности ° Определить, какие апфибутм ифвбований и трасстфовки поддерживать Кинтвпин диюяипвлвныв О Звквзчлк Конечный пзльзоввтвл О Заинтересованное лицо (уточнвнныв) Метоаичеитв утз внии по атрибуты требований Звцхкы заинтврвсованнык лнц Атрибуты ззис.Д.б.

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

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

Принципы управления требованиями в Вас(опа)... 4$$ оказывать существенное влияние иа план итераций, так как элементы с самым высоким риском будут запланированы для ранних итераций. Друпкми важными результатами процесса управления масщтабом являются исходная итерация документа аРхипмхплуРы пРвгРаммного обеспечения и пересмотренный документ концепция, который отразтет более совершенное понимание сштемныи аналитиком и основными заинэмресованными лицами функциональных воэможностей системы и имеющихся ресурсов. Уточнение определения системы Задача данного подпроцесса (рис. Д.7) состоит в дзльнейщем уточнении тРвбований.

Для этого необходимо следующее. ° Подробно описать потоки событий пРецедвнтвв ° Детализировать двполнипмльные спвуифихауин ° Создать модели и прототипы интерфейсов пользователя Уточнение системы начинается со схематически определенных прецедентов, хотя бы кратко описанных ахтоРвв и нового понимания масщтаба проекта, отраженного в переопределенных приоритетах функций концепции, которые считаются достнзсимыми при практически неизменных сроках и бюджете. Результатом данного рабочего процесса является углубленное понимание функциональных возможностей системы, выраженное в детализированных прецедентах, исправленных и деталимфованных дополнительных спецификациях, а также элементах интерфейса пользователя. Обработка изменений требований Задача данного подпроцесса (рис.