Вигерс Карл. Разработка требований к программному обеспечению

Подождите немного. Документ загружается.

Таблица

В-1.

Руководство по поиску и решению проблем, связанных с требованиями

(продолжение)

Симптомы Возможные Возможные

решения

основные причины

Проблемы,

связанные с документированием

Клиенты или разра-

ботчики

предпола-

гают, что функцио-

нальность старой

системы будет про-

дублирована

но-

вой.

1 Требования для новой

системы указаны в виде

отличий от плохо докумен-

тированной существующей

системы.

Проведите инженерный анализ

существующей системы, чтобы

понять ее полные

возможности.

Составьте спецификацию

требований, включающую всю

желаемую функциональность

для новой системы.

Проблемы, связанные с документированием

Документация S

требований неточно

описывает

систему.

Изменения

не

вносятся

в документацию требований.

Следуйте процессу управления

изменениями,

включающему

обновление документации

требований при принятии

новых

требований.

Проводите все запросы на

изменения

через совет

по

управлению изменениями.

Встречайтесь с ключевыми

заинтересованными в проекте

лицами для проверки

измененной спецификации

требований.

Существуют раз-

личные, противо-

речащие друг другу

версии докумен-

тации требований,

Плохие приемы управления

версиями.

Наличие нескольких «глав-

ных» экземпляров докумен-

тации требований.

Определите и исполняйте

хорошие приемы контроля

версий для документации

требований.

Храните требования в базе дан-

ных инструментального сред-

ства управления требованиями.

Генерируйте документы, содер-

жащие требования, как отчеты

по содержанию базы данных

инструментального средства.

Назначьте менеджера по тре-

бованиям ответственным за

внесение изменений в специ-

фикацию.

Приложение В

487

Таблица

В-1.

Руководство

по поиску и решению проблем,

связанных

с требованиями

(продолжение)

Симптомы Возможные Возможные решения

основные причины

Проблемы,

связанные

с утверждением

i Продукт не отвечает !

бизнес

-целеям

или

ожиданиям

пользо-

вате

лей

1 Клиенты имеют

невысказанные,

предполагаемые

или скрытые

требования,

которые

не были

удовлетворены.

1 Атрибуты качества

и целевая произво-

дительность не

указаны.

Продукт не

достига-

ет

целевой

произ-

водительности или

не удовлетворяет

другим ожиданиям |

пользователей по

качеству.

Клиенты неточно выразили

свои

нужды.

Аналитик требований не по-

ставил нужных вопросов.

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

клиентов в разработке

требований.

Неверно представлены поль-

зователи, участвовавшие в

процессе,

например мене-

джеры, разработчики или

другие заместители реаль-

ных пользователей не выра-

жали их действительные

нужды.

\ Продукт -

оригинальный,

передовой, с неопределен-

ными требованиями, и руко-

водство по маркетингу или

по продукту не точно оцени-

ло нужды рынка.

Участники проекта сделали

неточные допущения.

i Целевая

производительное

гь

и атрибуты качества не

обсуждались во время

выявления требований.

Заинтересованные в

проеюе

лица не понимают нефунк-

циональных требований и их

важности.

Используемый шаблон

спе-

цификации

требований не

имеет разделов для нефунк-

циональных

требований.

Пользователи не выражают

своих предположений о про-

изводительности системы и

качественных характерис-

тиках.

Проведите исследование

рынка, чтобы понять

сегменты

рынка и их потребности.

Привлекайте сторонников

продукта,

представляющих

каждый основной класс

пользователей, к работе над

проектом от начала и до конца.

i Научите аналитиков ставить

правильные вопросы.

Разработайте варианты ис-

пользования, которые обеспе-

чат понимание бизнес-задач.

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

в проверках документации

требований,

начиная

с ранних

стадий процесса работы с тре-

бованиями.

! Создайте прототипы получите

их оценку пользователями.

i Попросите пользователей

создать проверочные тесты

и критерии приемлемости.

Расскажите аналитикам и

клиентам о нефункциональных

требованиях и о том, как их

определять.

Аналитики должны обсуждать

нефункциональные

требования

во время выявления

требований.

Используйте шаблон

специ-

фикации требований, вклю-

чающий разделы для нефунк-

циональных требований.

! Используйте

Planguage

для точного указания целевой

производительности

атрибутов качества.

488

Приложение Б

Таблица

В-1.

Руководство по поиску и решению проблем, связанных с требованиями

(продолжение)

Симптомы

Возможные

основные причины

Возможные

решения

Проблемы, связанные с управлением требованиями

Целевая производительность

и атрибуты качества не были

определены достаточно точ-

но, чтобы все заинтересо-

ванные в проекте

лица

понимали их одинаково.

Некоторые запла-

нированные требо-

вания

не были

реализованы.

Разработчики не следовали

спецификации требований.

Со спецификацией требова-

ний не были ознакомлены

все разработчики.

Спецификация требований

не обновлялась по мере

внесения изменений.

Об изменениях не сообща-

лось всем, кого это затра-

гивало.

Требования случайно

пропускались во

время

реалиации.

Обязанности по реализации

требований не были

детально расписаны.

Своевременно обновляйте

спецификацию требований и

обеспечивайте доступ к ней

всей команде.

Позаботьтесь, чтобы в про-

цесс управления изменениями

входил обмен информацией с

заинтересованными в проекте

лицами.

Храните требования в

инстру-

ментальном средстве управ-

ления требованиями.

Отслеживайте статус отдель-

ных требований.

Создайте и

применяйте

матрицу трассирования

требований.

Определите ясные роли и обя-

занности по реализации ПО.

Проблемы,

связанные с управлением изменениями

Требования часто

изменяются.

1 Многие изменения

вносятся в требо-

вания на поздних

стадиях процесса

разработки.

Клиенты не понимают,

что им нужно.

Бизнес-

процессы

или !

требования рынка часто

меняются.

Не все нужные люди участ-

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

проверке требований.

Требования с самого начала

недостаточно хорошо

определены.

Усовершенствуйте приемы

выявления требований.

Введите и исполняйте

технологический процесс

управления изменениями,

Создайте совет по управлению

изменениями для принятия

решений относительно

предлагаемых

изменений.

1 Проводите анализ послед-

ствий изменений до их

принятия.

Приложение В

489

Таблица

В-1.

Руководство

по поиску и решению проблем, связанных с требованиями

(продолжение)

Симптомы Возможные

основные причины

Возможные решения

Проблемы, связанные с управлением

изменениями

Часто добавляются

новые

требования.

Основная версия требований

не определена или несогла-

сована.

Изменились технологии,

Внешние

факторы, например

изменения, диктуемые госу-

дарственными органами.

Требования

содержали

мно-

го готовых решений, не удо-

влетворявших действи-

тельные

нужды.

Рыночные нужды не очень

хорошо поняты.

За изменениями стоят

политические поблемы.

Выявление требований

было

неполным.

Плохо понимается область

1рименения

приложения.

Заинтересованные в проекте

лица не понимают или не

ценят определение

масштабов проекта,

Объем

проекта растет

бесконтрольно.

Руководство, отдел

маркетинга или клиенты

требуют новых функций без

учета последствий этого для

проекта.

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

клиентов в разработке

требований.

Заинтересованные в проекте

лица должны проверять

требования прежде, чем

вносить их в основную версию.

Проектируйте ПО с максималь-

ными возможностями для вне-

сения и принятия изменений.

Включите

в график проекта

резервы на

случай

непредви-

денных

обстоятельств,

чтобы

иметь возможность вносить

некоторые изменения.

Используйте подходы инкре-

ментальной разработки, чтобы

быстро реагировать на изме-

няющиеся требования.

Узнайте о политической ситуа-

ции

в компании и старайтесь

предугадать

ее воздействие

на требования.

Усовершенствуйте приемы

выявления требований.

Определите и сообщите

всем

масштабы проекта.

Нужные люди должны

принимать точные бизнес-

решения об изменении объема

проекта.

Проведите анализ основных

причин того, откуда и почему

появляются новые требования.

Проанализируйте последствия

изменений до того, как при-

нимать новые требования, и

ознакомьте с результатами все

заинтересованные стороны.

Подключите руководство

к действиям по

выявлению

требований.

490

Приложение В

Таблица

В-1.

Руководство по поиску и решению проблем, связанных с требованиями

(продолжение)

Симптомы

Возможные

основные причины

Возможные решения

Проблемы, связанные с управлением изменениями

Обеспечьте вклад всех классов

пользователей.

Включите в график проекта

резервы на непредвиденные

обстоятельства, чтобы иметь

возможность вносить

некоторые дополнения,

Используйте подходы инкре-

ментальной

разработки,чтобы

быстро реагировать на

НОВЫЕ:

требования.

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

за границы

проекта.

Образ и границы неясно

определены.

Бизнес-цели нечетко

поняты.

Масштабы постоянно изме-

няются, возможно,

ответ

на переменчивые требова-

ния рынка.

Приоритеты требований

плохо

определены.

У членов совета по управле-

нию изменениями нет еди-

ного

мнения о масштабах

проекта.

Ясно определите бизнес-цели,

образ

и границы.

Используйте положение об

объеме проекта для принятия

решений о том, входят ли

предлагаемые изменения в е о

границы.

Записывайте объяснения,

касающиеся отклонений

предложенных требований.

Добейтесь,чтобы

совет

по управлению изменениями

имел единое мнение

об объеме проекта.

Проследите, чтобы совет

по

управлению

изменениями

имел должный состав

и полномочия.

Используйте методы инкре-

ментальной

разработки,чтобы

гибко учитывать

изменяющие-

ся границы проекта.

Приложение В

4 И

Таблица

В-1.

Руководство по поиску и решению проблем, связанных с требованиями

(продолжение)

Симптомы

Возможные

основные причины

Возможные решения

Проблемы, связанные с

управлением

изменениями

Объем работ изме-

няется после начала

разработки.

Плохо определенные, плохо

понимаемые или постоянно

меняющиеся бизнес-цели.

Недостаточное понимание

сегментов и потребностей

рынка.

Выпуск конкурирующих

продуктов.

Ключевые

заинтересован-

ные в проекте лица не про-

верили и не утвердили

требования.

Определите бизнес-требова-

ния и приведите образ и гра-

ницы

в соответствие с ними.

Определите заинтересованных

в проекте лиц, принимающих

решения

на уровне бизнес-

требований.

Лица, принимающие решения,

должны

проверить документа-

цию образа и границ.

Применяйте технологический

процесс управления изме-

нениями для

рализации

изменений.

Включите в график проекта

резервы на непредвиденные

обстоятельства, чтобы учесть

возможность

некоторого

роста

масштабов.

Заново определяйте сроки и

ресурсы при изменении на-

правления развития проекта.

Об изменениях

в требованиях не

сообщается всем

заинтересованным

в проекте лицам,

которых это

касается.

Документация требований не

обновляется

при изменении

требований.

Клиенты запрашивают

изменения непосредственно

разработчиков.

Не всем обеспечен легкий

доступ к документации

требований.

Неформальные, вербальные

пути передачи информации

исключают из процесса не-

которых

участников проекта.

Назначьте ответственного

для

каждого

требования.

Определите связи трассируе-

мости

между требованиями и

другими другими докумен-

тами.

При обмене информации

по требованиям учитывайте

все области, которые это

затрагивает.

Установите процесс управле-

ния изменениями, включаю-

щий механизмы обмена

информацией.

492

Приложение В

Таблица

В-1.

Руководство по поиску и решению проблем, связанных с требованиями

(продолжение)

Симптомы

Возможные

основные причины

Возможные решения

Проблемы, связанные с управлением изменениями

Предложения

об

изменениях

в требованиях

теряются.

Статус запросов

на изменения

не известен.

Неясно, кого нужно

инфор-

мировать об изменениях.

Отсутствие установленного

процесса управления

изменениями.

Не понятны

взаимосвязи

между требованиями.

Используйтеинструментальное

средство управления

требова-

ниями для

обеспечения

досту-

па

заинтересованных

проект

лиц к текущей версии требо-

ваний через Интернет.

Неэффективный процесс

управления изменениями.

Процесс управления изме-

нениями не соблюдается.

Заинтересованные

в проекте лица

обходят процесс

управления изме-

нениями,

Клиенты

запра-

шивают изменения

непосредственно

у разработчиков.

Процесс управления измене-

ниями

не практичен и не

эффективен.

Работа совета по управле-

нию изменениями не

эффективна.

Некоторые заинтересован-

ные в проекте лица не пони-

мают или не принимают про-

цесс управления измене-

ниями.

Руководство не требует

выполнения процесса

управления изменениями.

Примите практичный,

эффек-

тивный процесс управления

изменениями и научите заин-

тересованных в проекте лиц

следовать ему.

Распределите обязанности rai

выполнению этапов процессе

управления изменениями.

Позаботьтесь, чтобы процесс

управления

изменениями

выполнялся.

Используйте инструменталь-

ные средства управления

требованиями для учета

изменений и статуса

каждогс

требования.

Позаботьтесь, чтобы

процесс;

управления изменениями

бып

практичным,

эффективным,

действенным, понятным и

доступным для всех

заинтере-

сованных в проекте лиц.

Создайте работоспособный

совет по управлению

измене

ниями.

Заручитесь поддержкой

руке

•

водства

в исполнении

процес-

са управления измененями.

Установите политику, согласно

которой изменения

требований

выполняются только посред-

ством процесса

изменения

требований.

Приложение В

493

Таблица

В-1.

Руководство по поиску и решению проблем, связанных с требованиями

(продолжение)

Симптомы Возможные

основные причины

Возможные решения

Для изменения

тре-

бований необходи-

мо гораздо больше

усилий,чем

плани-

ровалось.

Изменения затра-

гивают больше

компонентов систе-

мы, чем ожидалось.

Изменения проти-

воречат другим

требованиям.

Изменения идут

в ущерб качеству

из-за

побочных

эффектов.

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

последствий предлагаемых

изменений в требованиях.

Решения по изменениям

принимаются поспешно.

Решения по изменениям

принимаются не уполномо-

ченными сотрудниками.

Члены команды

боятся

честно оценивать послед-

ствия

предлагаемых

изменений.

Утвердите процедуру и кон-

трольные таблицы анализа

последствий изменений.

Внесите анализ последствий

в процесс управления

изменениями.

Сообщайте об

изменениях

всем заинтересованным в

про-

екте лицам, которых это затра-

гивает.

Используйте

информацию

о трассировании для оценки

последствий

предлагаемых

изменений.

По мере необходимости

заново

определяйте

обязательства и

принимайте необходимые ком-

промиссы,

когда

предлагаются

изменения.

494

Приложение В

Примеры документации требований

В данном приложении на примере небольшого гипотетического

проек-

та под названием Cafeteria Ordering System (COS) проиллюстрированы

некоторые описанные в этой книге документы и диаграммы, необходи-

мые при разработке требований. К ним относятся:

1 документ об

образе

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

список вариантов использования и несколько описаний

вариантов

использования;

I часть спецификации требований к ПО;

1 некоторые модели анализа;

I часть словаря данных;

несколько бизнес-правил.

Поскольку это лишь пример, элементы документации требований

намеренно не приводятся в законченном виде. Я хочу здесь просто по-

казать в общих чертах, как различные типы информации, необходимой

при создании

требований,

относятся друг к другу и как можно запись -

вать содержание каждого раздела. Б небольшом проекте зачастую

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

доку-

менте, поэтому у вас может не оказаться отдельных

документов

образа и границ проекта, вариантов использования и спецификации

требований к ПО. Для структурирования данных в этих документах

предусмотрена масса способов. Ясность, полнота и простота исполь-

зования документации требований

—-

важнейшие задачи при ее

со-

ставлении.

Документы обычно строятся по шаблонам, описанным в предыду-

щих главах, но здесь из-за малых масштабов этого проекта шаблоны

несколько

упрощены.

В некоторых случаях несколько разделов объеди-

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

495

17-2437

необходимо учитывать, как адаптировать стандартные шаблоны орга-

низации, чтобы они лучше соответствовали объемам и сути проекта.

Документ об образе и границах проекта

Бизнес-требования

1.1.

Исходные данные, возможности бизнеса

и нужды клиентов

Большинство сотрудников Process Impact в настоящее время тратят в

среднем 60 минут в день, чтобы выбрать, оплатить и съесть обед в ка-

фетерии. Около 20 минут уходит на то, чтобы дойти до кафетерия и

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

кредитной картой. Таким образом, сотрудники проводят около 90

ми-

нут вне рабочих мест. Некоторые звонят в кафетерий заранее, чтобы

блюда были готовы к их приходу. Они не всегда

получаютто,

что заказа-

ли, потому что некоторые блюда заканчиваются до их прихода. Кафете-

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

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

утром и вечером, хотя гораздо меньше сотрудников завтракает и ужи-

нает, чем обедает.

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

тавляли в назначенное место в офисе компании в указанный день в

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

позволит получать те блюда, которые хотят клиенты. Это улучшит как

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

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

том, какие блюда хотят получить

клиенты, позволит уменьшить потери и увеличит эффективность рабо-

ты персонала кафетерия. Если сотрудники получат в будущем возмож-

ность заказывать доставку блюд из близлежащих ресторанов, то у них

появится больший выбор при меньшей цене, так как фирма сможет за-

ключать оптовые соглашения с ресторанами. А значит, кафетерию Pro-

cess Impact придется обслуживать только посетителей в обеденные

часы, тогда как рестораны решат вопросы с завтраками, ужинами,

обслуживанием особых событий и питанием по выходным дням.

496 Приложение Г