Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Разработка требований

.pdf
Скачиваний:
41
Добавлен:
01.05.2014
Размер:
214.35 Кб
Скачать

Санкт-Петербургский Государственный Электротехнический Университет (ЛЭТИ)

кафедра МО ЭВМ

Реферат

Разработка требований

Выполнил студент группы 1341, ФКТИ

Пухкал И.

Санкт-Петербург 2005

Содержание

2

Содержание

1

Вводная информация

3

2

Особые действия

4

 

2.1

Цель: Разработать требования заказчика . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

 

2.2

Цель: Разработать требования к продукту . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

 

2.3

Цель: Проанализировать и подтвердить . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

 

2.4

Требуемые процессом действия по модели CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

3

Ошибки при разработке требований

8

4

Языки описания требований

11

 

4.1

Problem Statement Language (PSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

 

4.2

Structured Analysis and Design Technique (SADT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

 

4.3

EDDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

 

4.4

Systematic Activity Modelling Method (SAMM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

 

4.5

Higher Order Software (HOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

 

4.6

Requirements Statement Language (RSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

5

Разработка требований к пользовательскому интерфейсу

16

1 Вводная информация

3

Цель: проанализировать требования заказчика, требования к продукту и его программным компонентам

исоздать их.

1.Вводная информация

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

Требования являются основанием для проектирования. Разработка требований включает в себя следующие действия:

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

сбор и координация потребностей организаторов;

разработка требований к жизненному циклу продукта;

установление требований заказчика;

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

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

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

Для того, чтобы понять, определить и выбрать требования из набора альтернатив на всех уровнях используется практики анализа. Среди них:

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

разработка концепции работы5;

определение требуемой функциональности.

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

2Организатор - группа или отдельный человек, который вовлечен, или каким-либо образом ответственен за результат работы. Организаторами могут быть члены команды, поставщики, заказчики, конечные пользователи и другие. Вовлеченный организатор

-организатор, участвующий в каком-либо действии; включен в план.

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

4Особое действие - ожидаемый компонент системы, который представляется важным в достижении особой цели. Особые действия описывают действия, которые, как ожидается, приведут к достижению особой цели.

5Концепция работы — общее описание того, как сущность используется или взаимодействует.

2 Особые действия

4

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

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

ограничения различных типов;

технологические пределы;

стоимость и причины за нее отвечающие;

временные ограничений и причины, ответственные за план;

риски;

рассмотрение желаемых, но не высказанных явно заказчиком или конечным пользователем, вопросов;

факторы, вызванные специфическими для разработчика вопросами, ограничениями и законами.

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

Связанные области процессов

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

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

Для большей информации о требованиях к взамодействию и управлению взаимодействием следует обратиться к процессу интеграции продукта.

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

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

Для большей информации об идентификации и управлении рисками, которые относятся к требованиям, следует обратиться к процессу управления рисками.

Для большей информации о гарантировании того, что ключевые рабочие продукты управляются и контролируются, следует обратиться к процессу управления конфигурацией.

2. Особые действия

2.1. Цель: Разработать требования заказчика

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

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

2 Особые действия

5

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

Собрать потребности организаторов

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

Установить потребности

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

постоянные обзоры проектов;

опросы и сценарии поведения конечных пользователей;

«мозговой штурм»;

прототипирование и моделирование;

исследования рынка;

«реверс-инжениринг» (где возможно);

бета-тестирование.

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

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

Артефакты на выходе:

требования заказчика;

ограничения заказчика на процесс верификации;

ограничения заказчика на процесс валидации.

2.2. Цель: Разработать требования к продукту

Требования заказчика перерабатываются и детально прорабатываются для того, чтобы разработать требования

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

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

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

2 Особые действия

6

Установить требования к продукту и его компонентам

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

Артефакты на выходе:

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

требования к продукту;

требование к компонентам продукта.

Связать требования с их компонентами

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

Артефакты на выходе:

листы связанных требований;

предварительные связанные требования;

ограничения проекта;

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

отношения между связанными требованиями.

Требования к определению взаимодействий

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

Артефакты на выходе:

• требования к взаимодействию;

2.3. Цель: Проанализировать и подтвердить

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

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

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

2 Особые действия

7

Установить рабочие концепции и сценарии

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

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

Артефакты на выходе:

рабочая концепция;

концепции инсталляции, работы, эксплуатации и поддержки;

концепция отчуждения;

варианты использования (use case);

временные сценарии;

новые требования;

Установить определение требуемой функциональности

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

Анализ функциональности — это не то же самое, что и структурный анализ в разработке программных изделий и не предлагает функционально-ориентированное проектирование. В объектно-ориентированном проектировании, он определяет «услуги». Определение функций, их построения и взаимодействия в согласии с требованиями называется «функциональной архитектурой».

Артефакты на выходе:

функциональная архитектура;

диаграммы действий и варианты использования;

концепция отчуждения;

объектно-ориентированный анализ с определенными «услугами»;

Анализ требований

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

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

Артефакты на выходе:

требования к отчетам о дефектах;

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

ключевые требования;

метрики технического процесса;

3 Ошибки при разработке требований

8

Валидация требований посредством всеобъемлющих методов

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

Артефакты на выходе:

• материалы по анализу и его результаты;

2.4. Требуемые процессом действия по модели CMMI

1)установить политику организации;

2)планировать процесс;

3)предоставить требуемые ресурсы;

4)распределить ответственность;

5)повышать квалификацию персонала;

6)управлять конфигурациями;

7)определить вовлеченных организаторов;

8)следить и контролировать процесс;

9)объективно определять строгость следования методике процесса;

10)сверять состояние процесса с более высокими уровнями управления;

3.Ошибки при разработке требований

Недостаточное участие заказчика

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

Решение проблемы: необходимо начать с определения классов пользователей продукта. Классы пользователей — это группы пользователей, которые различаются по (a) частоте использования продукта (b) набору используемых функций (c) их уровню доступа и так далее. Эффективным является использовании метода, так называемых «адвокатов продукта»6 — людей, представляющих различные пользовательские классы. Адвокаты продукта собирают информацию от остальных членов своего класса, формулируют требования пользователей и выносят заключение о достаточном уровне реализации функций и приоритетах их реализации.

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

Неопределенные и двусмысленные требования

Двусмысленность налицо, когда утверждение о требованиях может иметь несколько различных толкований, и не известно, какое из них верное. Не столь очевидная форма двусмысленности: разные читатели воспринимают смысл по разному. Каждый из читателей полагает, что именного его интерпретация и есть верная и двусмысленность остается нераспознанной до того момента, когда ее устранение обойдется слишком дорого.

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

6В оригинале — «product champions»

3 Ошибки при разработке требований

9

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

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

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

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

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

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

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

Еще один из симптомов (вариация предыдущего) — это то, что более 90% требований определены с высоким приоритетом. Разные люди могут понимать высокий приоритет по-разному, что может привести к несоответствию ожиданий по поводу того, что будет включено в очередной релиз. Зачастую пользователи не устанавливают приоритеты потому, что боятся того, что разработчики сфокусируются на более значимых требованиях, а менее значимые — никогда не будут реализованы.

Решение: важнейшим атрибутом всякого варианта использования (use case), возможности программы или функционального требования должна стать относительная важность реализации. Следует сопоставить варианты использования с бизнес-требованиями, чтобы знать, какая функциональность интересует заказчика прежде всего. Приоритет может основываться на: (a) частоте использования (b) удовлетворении наибольших классов пользователей (c) реализации ключевых бизнес-процессов (d) функциональность, требуемая управленческим персоналом.

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

Реализация никому не нужной функциональности

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

Решения: следует убедиться, что у всякого функционального требования можно найти его источник: конкретный вариант использования, требования более высокого уровня, промышленный стандарт или правительственное ограничение. Если источник требования неизвестен, то следует серьезно озаботиться: а надо ли оно вообще? Следует определить те группы пользователей, которые получат выгоду от каждой возможности программы.

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

«Вечный» анализ

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

3 Ошибки при разработке требований

10

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

Решение: Создать «вылизанную» спецификацию требований — это не цель процесса разработки требований. Эта цель в том, чтобы создать четко выраженные требования, которые позволяют с приемлемым риском перейти к процессу разработки. Если какие-то требования остаются неясными, то следует выбрать такую модель жизненного цикла, которая позволит пускать в ход недостающие части требований по мере того, как приходит их понимание. В таком случае следует помечать маркером «требует дальнейшего уточнения» те участки спецификации, информации по которым недостаточно и работа с ними является рискованным предприятием.

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

«Расползание рамок»

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

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

Решения: во все проекты следует закладывать возможность роста требований и планы должны включать места для возможного расширения. Как только на вход поступает новое требование, вариант использования или возможность программы, следует задать вопрос: «Это вписывается в рамки?».

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

Неверный процесс внесения изменений

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

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

Недостаточный анализ влияния изменений

Иногда разработчики или управляющие проектом соглашаются внести предложенные изменения без того, чтобы полностью поразмыслить о последствиях. Изменение может оказаться куда более сложным, чем казалось первоначально, может оказаться технически или экономически неприемлемо или может конфликтовать с другими требованиями. Подобного рода неудачные решения отражают недостаточность анализа влияния принятия предлагаемого изменения. Еще один из признаков того, что анализ проведен не полностью, является то, что разработчики продолжают «копаться» в более вовлеченных компонентах после того, как внесли изменения.

Решение: перед тем, как не глядя принимать решение, следует тщательно взвесить последствия каждого