Управління ІТ-проектами / Література / Элизабет Халл. Разработка и управление требованиями

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

Рис. 2.10 Статус удовлетворения

Сразу же после предложения изменения статус удовлетворения переходит в состояние Удовлетворенность сомнительна, независимо от того, направлено ли предложенное изменение на требование верхнего или нижнего уровня. Этот статус сохраняется до тех пор, пока не произведен анализ предложенного изменения, и статус удовлетворения не переведен или в состояние Неудовлетворенно, или в состояние Удовлетворенно.

2.5.5 Внутренние связи информационной модели

Запросы на изменение связывает между собой статусы согласования, проверки и удовлетворения. Получение (регистрация) запроса на изменение меняет сразу же все три состояния (их статус) и приводит к необходимости проведения дополнительной работы: во- первых, - необходимо оценить возможное влияние предлагаемого изменения, а во-вторых, - если влияние существует, - необходимо правильно его адресовать, чтобы принять меры для его адаптации. Необходимо также учитывать, что статус удовлетворения может волнообразно «раскачиваться» вверх-вниз, поскольку все требования связанны между собой связями удовлетворения. Этот «волновой» эффект определяет потенциальные рамки любых побочных изменений, определяя, тем самым, степень «влияние» предложенного изменения.

Статус согласования для производных требований должен находиться в соответствии со статусом удовлетворения входящих требований, поскольку входящее требование не может стать удовлетворенным до тех пор, пока поставщик с нижнего уровня не согласует все

производные требования, удовлетворяющие это входящее требование.

2.6Подробнее об общем процессе

2.6.1Процесс согласования

Как показано на рис. 2.11, процесс согласования происходит между поставщиком нижнего уровня и заказчиком на уровень выше (см. п. 2.2).

Производные требования

и

Стратегия проверки

Запрос на изменение

Запрос на изменение

Анализ

и

Моделирование

Рис. 2.11 Процесс согласования

Прежде чем приступать к работе с входящими требованиями, необходимо оценить составляют ли они приемлемый «фундамент» для последующей работы.

Чтобы оценить приемлемость требований для работы, необходимо ответить на следующие вопросы:

∙Является ли требование полным?

∙Является ли требование ясным?

∙Является ли требование осуществимым?

∙Является ли план проверки требований понятным и приемлемым?

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

∙Отсутствие части информации – зачастую в документах встречаются места, умышленно пропущенные сейчас для заполнения в дальнейшем (так в документах, составленных на английском языке, часто встречаются специальные поля с пометкой типа:

TBA (to be agreed) – необходимо согласовать, TBC (to be complete) – необходимо завершить,

TBD (to be decided) – необходимо принять решение).

∙Недостаток ясности – неоднозначность, противоречивость, путаница и т.д.

∙Невозможность реализации – никто не знает то, как это сделать.

∙План проверки неприемлем.

Если в процессе оценки приемлемости требования, само требование и план его проверки признаются приемлемыми, то статус требования может стать «Согласованно». Если требование неприемлемо, то поставщик должен направить заказчику альтернативную формулировку требования. В этом случае ответственность («мяч») переходит к заказчику и статус согласования (см. рис. 2.8) переходит в состояние «Оценка заказчиком требования от поставщика». Если заказчик согласен с предлагаемой поставщиком формулировкой, то он может установить статус согласования требования в «Согласованно». В противном случае заказчик сам должен направить поставщику альтернативную формулировку требования. Статус согласования в этом случае переходит в состояние «Оценка поставщиком требования от заказчика», и ответственность («мяч») возвращается к поставщику.

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

Если в какой-то момент одна из сторон предлагает изменение для уже согласованного требования, то на стороне, получившей запрос на изменение, статус согласования переводится в супер-состояние «Оценка». Далее процесс переговоров продолжается, как описано выше, до тех пор, пока не будет достигнуто новое соглашение.

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

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

Другими словами, существует необходимость работать над требованиями параллельно на нескольких уровнях в одно и тоже время. Т.е. общий процесс должен выглядеть как последовательность параллельных подпроцессов согласований и подпроцессов принятия

решений. Это полностью разрушает парадигму «водопадного» процесса разработки, в котором все действия происходят в одном, строго заданном, порядке – сверху вниз.

И еще один нюанс. Часто бывает так, что команда, работающая над проектом, начинает задумываться о критериях приемки системы или планах проверки требований достаточно поздно (например, или только после того как все требования утверждены или же согласование приемочных испытаний заканчивается непосредственно перед началом тестирования и т.д.). Это плохая практика. Обычно она ведет к задержкам (и даже срывам) сроков окончания проекта из-за того, что уж согласованные требования приходиться менять на поздних этапах проекта для того, чтобы сделать их, наконец, пригодными для тестирования!

2.6.2 Анализ и моделирование

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

Моделирование – как часть общего процесса - также используется для понимания сущности и определения структуры производных требований. В большинстве случаев для понимания и структурирования пользовательских требований (stakeholder requirements) используются прецеденты (use cases) или пользовательские сценарии (users scenarios), которые помогают понять то, как люди будут использовать разрабатываемую систему.

Архитектурные модели обычно применяются для определения структуры требований в области решений. Такие модели описывают не только элементы решения, но и то, как они взаимодействуют между собой.

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

В основном, использование тех или иных моделей целиком зависит от характера конкретного проекта. Как ранее упоминалось, типы моделей очень сильно зависят от предметной области. Так, например, в области разработки программного обеспечения достаточно широко используются объектные модели. А для сравнения в таблице 2.1 представлены различные типы моделей, которые применяются в трех различных областях промышленности.

Основная цель создания разного рода моделей – это попытка понять суть входящих требований вместе с предлагаемой стратегией их проверки, а также последующие эксперименты с альтернативными вариантами реализации этих требований, которые (эксперименты) должны опережать разработку производных требований. Эта работа может рассматриваться еще и как возможная разработка стратегий проверки для производных

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

ВГлаве 3 рассматриваются некоторые распространенные методики моделирования, особенно те из них, которые применяются при разработке программного обеспечения.

ВГлаве 5 объясняется, как использовать модели прецедентов и пользовательские сценарии для улучшения понимания пользовательских требований.

ВГлаве 6 рассматриваются функциональные модели, которые помогают создавать базу для разработки системных требований.

2.6.3 Получение требований и стратегии проверки

Иллюстрацией этого процесса служит рис. 2.13.

Получение требований

Существует множество различных вариантов использования моделей в целях получения требований. Однако простейший случай, который можно рассматривать как базовый, - это получение требований к компонентам на основании архитектуры системы. В этом случае появляется возможность определить, какие именно требования должны быть удовлетворены каждым из компонентов системы. Некоторые из требований для компонентов системы могут совпадать с одним или более входящими требованиями; другие же могут быть получены из входящих требований таким образом, чтобы распределить выполнение входящих требований между несколькими компонентами системы. Другой набор требований может быть порождением ограничений, накладываемых архитектурой системы или самими входящими требованиями. Этими ограничениями могут быть ограничения конкретных интерфейсов, возможные физические ограничения, такие как масса, объем, потребляемая электрическая мощность, теплоотдача и т.д.

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

Следует отметить, что при получении требований для компонентов системы необходимо выполнить определенную дополнительную работу - установить связи типа «удовлетворяет/удовлетворяется» между входящими и производными требованиями. Такие связи показывают: какие входящие требования удовлетворяются какими производными требованиями, что может быть использовано для утверждения того, что:

∙все входящие требования удовлетворены;

∙все производные требования необходимы (т.е. они прямо или косвенно удовлетворяют одно или более входящих требований).

Рис. 2.13 Процесс получения требований и стратегии проверки

При этом абсолютно недостаточно убедиться лишь в самом факте наличия связей типа «удовлетворяет/удовлетворяется», например, при помощи матрицы связей.

Здесь важно, чтобы для каждой из этих связей заранее устанавливалось собственное обоснование – некий мотивирующий аргумент.

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

Получение стратегии проверки

Как обсуждалось выше, связи типа «удовлетворяет/удовлетворяется» отражают процесс получения производных требований из входящих требований – спецификацию системы. В

отличие от этого, стратегия проверки определяет план того, как каждое требование будет тестироваться на каждом уровне.

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

Каждое проверочное мероприятие должно подразумевать следующие аспекты:

∙тип мероприятия, который должен соответствовать требованию;

∙фаза, на которой должно проводиться мероприятие – чем раньше, тем лучше;

∙специальное оборудование, которое может понадобиться для проведения мероприятия;

∙описание того, что будет являться успешным результатом мероприятия.

План проверки может быть структурирован исходя либо из фазы (стадии проекта), либо из типа проверочных мероприятий.

Рис. 2.14 Проверка требований

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

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

Рассмотрим пример, приведенный на рис. 2.14.

Системные требования для корабля разделены на два требования для разных подсистем – для корпуса и силовой установки. Соответственно, два различных теста запланированы для требования на системном уровне, и два других - на уровне подсистем.

Следовательно, для полного понимания того, как требования будут проверяться, необходимо наличие связей «удовлетворяющего» типа и стратегии проверки.

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

2.7 Заключение

В этой главе мы рассмотрели общий процесс разработки требований, который одновременно применяется на каждом уровне разработки системы. Основным преимуществом общего процесса является то, что он определяет общие действия, характерные для каждого уровня:

∙согласование входящих требований с заказчиком;

∙анализ входящих требований для определения рисков и потенциальных проблем, связанных с удовлетворением требований;

∙создание одной или нескольких моделей для исследования возможных стратегий получения последующих требований;

∙формирование требований, полученных из входящих требований при помощи результатов анализа и моделирования;

∙согласование производных требований с командой (командами) сотрудников, ответственных за их реализацию;

∙установление связей «удовлетворяющего» типа между входящими и производными требованиями;

∙установление связей «проверяющего» типа между производными требованиями и соответствующей стратегией проверки.

Все эти действия приводят к организации информации таким образом, как она была описана в информационной модели общего процесса. Текущее состояние информации используется для измерения прогресса в работе, оценки влияния предлагаемых изменений и определения показателей выполнения проекта.

Например, состояние требования может характеризоваться его тремя атрибутами (свойствами):

∙согласование;

∙удовлетворение;

∙проверяемость.

Идеальное состояние любого требования в любой системе заключается в том, что это требование:

∙согласовано между заказчиком и исполнителем;

∙имеет согласованную стратегию его проверки;

∙удовлетворяется требованиями более низкого уровня (или спецификацией системы).

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