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

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

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

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

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

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

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

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 представлены различные типы моделей, которые применяются в трех различных областях промышленности.

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

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

Таблица 2.1 Примеры методов моделирования.

Авиастроение.

Аэродинамические модели Трехмерные пространственные модели Модели распределения нагрузки Симуляторы полетов Железнодорожный транспорт Симуляторы расписаний.

Модели безопасности, надежности и ремонтопригодности Автомобилестроение Модели дизайна Модели приборной панели Аэродинамические модели.

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

Рис. 2.12 Процесс анализа и моделирования.

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

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

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

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

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

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