Проблемы — это условия, которые ведут к негативным последствиям для вашего продукта. Начните анализ основных причин с одного из симптомов какого-либо полученного вами в прошлом нежелательного результата и нарисуйте диаграмму причин и следствий, чтобы понять основные вопросы и оценить их решение. Вот некоторые типичные симптомы, проистекающие из проблем с требованиями:
· нарушение графика и перерасход бюджета;
· продукт не удовлетворяет нужд пользователей или не соответствует их ожиданиям;
· продукт требует исправлений и «заплат» сразу после выпуска;
· разочарование членов команды, деморализация, утрата мотивации
· и текучка кадров;
· масса переделок;
· дублирование действий;
· упущенный сектор рынка или задержанное преимущество в бизнесе;
· потеря доли на рынке или доходов;
· возврат продукта или неприятие продукта рынком;
· выпуск продукта с уменьшенным набором функций; ПО, не поддающееся тестированию.
Общие препятствия для реализации решений
Любая попытка изменить способы работы отдельных людей или организаций встречает сопротивление. Определив, как исправить основные причины ваших проблем с требованиями, подумайте также о препятствиях, которые могут затруднить реализацию этих действий, и о возможных путях их обхода. Вот некоторые типичные препятствия реализации изменений в требованиях:
· нехватка времени (все и так слишком заняты); давление рынка, диктующее быстрейший выпуск продукта;
· недостаточная заинтересованность руководства в процессе конструирования требований и непонимание необходимых инвестиций;
· общее сопротивление изменениям;
· скептицизм относительно ценности конструирования требований;
|
|
· нежелание принимать новый или более упорядоченный процесс;
· трения между заинтересованными в проекте лицами;
· политика и устоявшаяся корпоративная культура;
· недостаточная подготовка и обучение персонала;
· неясное распределение ролей и обязанностей в проекте;
· недостаточное число ответственных лиц и плохая отчетность за действия, связанные с требованиями;
· недоступность квалифицированных сторонников продуктов;
· недостаточное признание или понимание проблем, вызываемых текущими приемами работы с требованиями.
Обратите внимание, что эти вопросы связаны с людьми или передачей информации, а не технические препятствия. Большинство препятствий такого рода не удается преодолеть легко и быстро, но первый шаг — признать их наличие.
Таблица В-1. Руководство по поиску и решению проблем, связанных с требованиями.
| Симптомы | Возможные основные причины | Возможные решения |
| Проблемы, связанные с процессами | ||
| · Процессы работы с требованиями и шаблоны документов в различных проектах несовместимы между собой. · Используемые процессы работы с требованиями неэффективны. | · Отсутствие общего понимания процессов работы с требованиями. · Отсутствие у руководства заинтересованности в наличии эффективных процессов работы с требованиями. · Отсутствие механизма совместного использования шаблонов и документации процессов. · Отсутствие хороших примеров шаблонов и документации требований. | · Документируйте текущий процесс работы с требованиями и создайте описание-предложение желаемого процесса. · Обучите всех членов команды конструированию требовании, · Примите один или несколько стандартных шаблонов документа образа и границ проекта, примеров использования и спецификации требований к ПО. Обеспечьте помощь для необходимой подгонки шаблонов к конкретному проекту. · Соберите и обеспечьте доступ к хорошим примерам документации требований. · Используйте метрику исправления дефектов, чтобы помочь команде понять цену плохих требований. · Используйте ретроспективу проектов, чтобы зафиксировать примеры текущих проблем и их последствий. |
| · Люди, исполняющие роли аналитиков, не знают, как делать это хорошо. | · Недостаток знаний о конструировании требований и роли аналитика требований, · Руководство считает, что любой разработчик автоматически может стать хорошим аналитиком. | · Обучите будущих аналитиков как конструированию требований, так и соответствующим особенностям работы с ПО. · Напишите должностную инструкцию и список необходимых навыков для аналитиков требований. · Организуйте программу обучения новых аналитиков. |
| · Инструментальные средства управления требованиями используются недостаточно. | · Недопонимание возможностей инструментального средства. · Процессы и культура работы не изменены для извлечения полной выгоды из инструментальных средств. · Нет ответственных за внедрение инструментального средства, | · Отправьте нескольких аналитиков на тренинг, организованный производителем инструментального средства. · Определите сторонника инструментального средства для обеспечения его внедрения и помощи другим Пользователям. · Выявите и измените особенности процессов и культуры, препятствующие использованию инструментального средства в полной мере. |
|
|
|
|
Таблица В-1. Руководство по поиску и решению проблем, связанных с требованиями (продолжение)
| Симптомы | Возможные основные причины | Возможные решения |
| Проблемы, связанные с продуктами | ||
| · Недовольные клиенты. · Клиенты отвергают продукт, как только увидели его. · Плохой анализ продукта. · Низкие продажи, потеря доли рынка. | · Недостаточное вовлечение пользователей в разработку требований. · Нереалистичные ожидания клиентов. · Разработчики создавали продукт на основе своих догадок о желаниях клиентов. · Клиент не знает о возможностях и ограничениях разработчиков и технологий. · Несоответствие между пониманием требований клиентами и разработчиками. · Недостаточное исследование рынка. | · Соберите фокус-группы. · Определите классы пользователей. · Определите сторонников продукта. · Приведите ожидания клиентов в соответствие с бизнес-целями. · Создавайте прототипы и просите пользователей оценивать их. · Используйте совместные семинары для выявления требований. · Привлеките представителей 'клиентов к участию в экспертизе документации требований. |
| Симптомы | Возможные основные причины | Возможные решения |
| Проблемы, связанные с планированием | ||
| · Требования не полны, · Требования недостаточно детализированы. · Конструирование следующего выпуска начинается до того, как требования для него поняты в достаточной мере. | · Недостаточное вовлечение пользователей в разработку требований. · Разработке требований уделено недостаточное время, · Установка даты выпуска версии до определения требований, возможно, в связи со спешкой, вызванной юридическими причинами или реалиями рынка. · Маркетологи или бизнесмены, заинтересованные в продукте, не вовлечены в процесс работы над требованиями. · Аналитики не обладают достаточными навыками и опытом. · Команда думает, что начать программировать более продуктивно, чем понять требования. · Руководство или клиенты не понимают необходимости в требованиях. · У аналитиков и разработчиков нет единого мнения о содержании требований. | · Не принимайте решений о сроках выпуска до того, как требования станут понятными в достаточной мере. · На ранних стадиях проекта привлеките технический персонал, чтобы он понимал требования. · Тщательно определите образ и границы продукта. · Объясните заинтересованным в проекте лицам риски, связанные с поспешным конструированием. · До6ивайтесь сотрудничества между аналитиками, разработчиками и бизнес-партнерами, чтобы те ставили реалистичные цели. · Усильте полномочия аналитика требований в команде. · Используйте метрику исправления дефектов, чтобы помочь команде понять цену плохих требований. · Используйте подходы инкрементального моделирования, чтобы быстро начать выпускать продукт, имеющий ценность для клиента. · Разработчики должны оценивать качество требований прежде, чем реализовать их. |
Таблица В-1. Руководство по поиску и решению проблем, связанных с требованиями (продолжение)
| Симптомы | Возможные основные причины | Возможные решения |
| Проблемы, связанные с планированием | ||
| · Серьезные изменения в сроках после начала проекта, но без сокращения масштабов. | · Заинтересованные в проекте лица не понимают влияния сокращения сроков на реализацию проекта в полном объеме. | · Стройте взаимоотношения сотрудничества между аналитиками, разработчиками и бизнес-партнерами, чтобы ставить реалистичные цели. · Договаривайтесь о компромиссах при изменении ограничений проекта. |
| · Пробелы в работе над требованиями. · Несколько человек совершают одни и те же манипуляции над требованиями. | · Нечеткое определение ролей и обязанностей при конструировании требований. · Нет ответственного за управление требованиями. | · Определите роли и распределите обязанности по разработке требований и управлению ими в каждом проекте. · Выделите необходимый персонал для эффективной разработки и управления требованиями. · Вносите действия, связанные с требованиями, в планы и графики работы по проектам. |
| · Планируется больше требований, чем позволяют сроки и ресурсы. | · График устанавливается до того, как определены требования. · Плохо определены масштабы проекта. · Неконтролируемый рост масштабов проекта. · Не учитывается кривая обучения при обучении незнакомым технологиям или при работе с новыми инструментальными средствами. Для участия в проекте недостаточно персонала. · Требованиям не назначены приоритеты. · Факторы риска превратились в проблемы. · Обязательства по проекту приняты до проведения точной оценки масштабов. · Энтузиазм по поводу замечательных новых технологий или возможностей берет верх над реалистичными оценками возможностей. | · Прежде чем принимать обязательства по проекту, документируйте образ и границы продукта в соответствии с бизнес-целями. · График разработки составляйте на основе требований, возможно, на стадии первоначального исследования требований, · Включите время на подготовку и кривую обучения в график работы. · Отделите исследование технологий и продукта от разработки продукта. · Определите приоритеты требований. · Используйте инициативное управление риском. · Динамически изменяйте масштабы проекта, насколько этого требует ситуация с проектов |
| · Недокументированный или плохо определенный объем. | · Недостаток управления финансовой поддержкой проекта. · Спешка с началом конструирования. · Отсутствие понимания важности определения объема проекта. · Отсутствие единства мнений у заинтересованных лиц об объеме проекта. · Изменчивые условия рынка или быстро изменяющиеся бизнес-нужды. | · Расскажите менеджерам об объеме и финансовой поддержке проекта. · Задокументируйте образ и границы проекта и согласуйте их с ключевыми заинтересованными в проекте лицами. · He начинайте проект с плохо определенным объемом. · Отменяйте проект, если не определена финансовая поддержка и объем проекта. |
Таблица В-1, Руководство по поиску и решению проблем, связанных с требованиями (продолжение)
| Симптомы | Возможные основные причины | Возможные решения |
| Проблемы, связанные с взаимодействием | ||
| · Проблемы, связанные с взаимодействием; дублирование действий, когда несколько человек занимаются одними и теми же требованиями. | · Обязанности по реализации требований не расписаны подробно. · Недостаточная коммуникация между подгруппами, работающими над частями проекта. · Географическое разделение групп разработчиков или разработчиков и клиентов. | · Определите ясные роли и обязанности для реализации ПО. · Обеспечьте видимый контроль статуса каждого требования |
| · Пересмотр принятых ранее решений. | · Отсутствие ясного признания и наделения полномочиями людей, принимающих соответствующие решения. | · Определите, кто должен принимать решения по требованиям к данному проекту процедуру принятия решений. Определите сторонников продукта. · Запишите, почему в прошлом решения отвергались, откладывались или отменялись. |
| · Участники проекта используют разную терминологию. | · Предположение, что толкуют ключевые термины одинаково и верно. | · Определите значения терминов в словаре. · Определите термины, касающиеся данных, в словаре. · Организуйте обучение команды разработчиков особенностям соответствующей области бизнеса. · Обучите представителей пользователей конструированию требований. |
| · Недостаточное вовлечение клиентов. · (Разработчики делают большое, количество допущений о реализуемых функциях). | · У представителей клиентов недостаточно времени для участия в разработке требований. · Клиенты не понимают необходимости своего участия. · Клиенты не знают, что аналитикам от них нужно. · Клиенты не заинтересованы в проекте. · Клиенты считают, что разработчики и так знают, что нужно клиентам. · Аналитики не знают, свою клиентскую аудиторию. · У аналитиков нет доступа к действительным клиентам, · Аналитики не знают, как сотрудничать с клиентами. · Сопротивление выполнению процесса разработки требований | · Объясните клиентам и менеджерам особенностям разработки требований и объясните необходимость их участия. · Опишите клиентам и менеджерам факторы риска недостаточного вовлечения пользователей. · Создайте атмосферу сотрудничества между разработчиками и деловыми партнерами. · Определите классы пользователей или сегменты рынка. · Определите сторонников продукта (пользователей или подходящих заместителей). · Готовьте квалифицированных аналитиков требований. · Заинтересуйте руководителей разработчиков и клиентов в эффективности процесса разработки требований |
Таблица В-1. Руководство по поиску и решению проблем, связанных с требованиями (продолжение)
| Симптомы | Возможные основные причины | Возможные решения | ||
| Проблемы, связанные с выявлением требований | ||||
| · Недостаточное вовлечение клиентов. · Разработчики делают большое, количество допущений о реализуемых функциях. | · У представителей клиентов недостаточно времени для участия в разработке требований. · Клиенты не понимают необходимости своего участия. · Клиенты не знают, что аналитикам от них нужно. · Клиенты не заинтересованы в проекте. · Клиенты считают, что разработчики и так знают, что нужно клиентам. · Аналитики не знают, свою клиентскую аудиторию. · У аналитиков нет доступа к действительным клиентам, · Аналитики не знают, как сотрудничать с клиентами. · Сопротивление выполнению процесса разработки требований | · Объясните клиентам и менеджерам особенностям разработки требований и объясните необходимость их участия. · Опишите клиентам и менеджерам факторы риска недостаточного вовлечения пользователей. · Создайте атмосферу сотрудничества между разработчиками и деловыми партнерами. · Определите классы пользователей или сегменты рынка. · Определите сторонников продукта (пользователей или подходящих заместителей). · Готовьте квалифицированных аналитиков требований. · Заинтересуйте руководителей разработчиков и клиентов в эффективности процесса разработки требований | ||
| · Вовлечены не те представители пользователей. | · Менеджеры, маркетологи, или другие лица пытаются говорить за конечных пользователей. · Менеджеры не обеспечили доступность пользователей аналитикам. | · Определите классы пользователей. · Определите сторонников продукта. · Привлеките других заинтересованных в проекте лиц, помимо непосредственных пользователей. | ||
| · Пользователи не уверены в своих потребностях. | · Пользователи не понимают или не могут хорошо описать бизнес-процессы. · Система создается для поддержки нового, не полностью определенного бизнес-процесса. · Пользователи не заинтересованы в проекте, может быть, боятся его. · Ожидается, что новая система будет использоваться для разработки нового бизнес-процесса. | · Проясните, какие результаты ожидают заинтересованные в проекте лица, которых это затрагивает, в случае успеха проекта. · Постройте модель бизнес-процесса пользователя. Выявите сторонников продукта. · Разработайте варианты использования. · Создайте прототипы и передайте пользователям для оценки. · Используйте инкрементальный подход к разработке, чтобы прояснять требования понемногу за раз. | ||
| · Разработчики не знают, кто их пользователи. | · Плохо определен образ продукта. · Плохо поняты потребности рынка. | · Документируйте образ проекта. · Проведите исследование рынка. · Определите пользователей текущих или конкурирующих продуктов. · Создайте фокус-группы. | ||
| · Слишком много людей вовлечено в выявление требований. | · Каждая группа хочет быть представлена по политическим причинам. · Нечетко определены классы пользователей. · Недостаток представителей пользователей конкретных групп. · Действительно большое количество классов пользователей. | · Определите классы пользователей. · Определите сторонников продукта. · Определите полномочия лиц, принимающих решения, связанные с требованиями. · Отделите политические приоритеты от деловых и технических. · Ориентируйте проект на удовлетворение нужд привилегированных классов пользователей. | ||
| · Решения представляются как нужды, и требования приходится получать на основе анализа представленных решений. | · Клиенты запрашивают решения, с которыми уже знакомы. · Требования содержат конструктивные ограничения. | · Несколько раз спросите «почему?», чтобы понять действительные нужды пользователей, скрывающиеся за представленными требованиями, и обоснование конструктивных ограничений. | ||
| · Реализованные требования не удовлетворяют нужды пользователей. · Требования слишком ограничены. | · Новое ПО должно соответствовать существующим стандартам для приложений и пользовательского интерфейса. · Клиенты не знают, какая информация должна входить в требования. · Основное внимание при обсуждении требований уделяется дизайну пользовательского интерфейса. | · Разработайте варианты использования на основном уровне, прежде чем обсуждать детали пользовательского интерфейса. · Подготовьте квалифицированных аналитиков, которые умеют ставить правильные вопросы. · Обучите клиентов особенностям конструирования требований. | ||
Таблица В- 1. Руководство по поиску и решению проблем, связанных с требованиями (продолжение)
| Симптомы | Возможные основные причины | Возможные решения |
| Проблемы, связанные с выявлением требований | ||
| · Отсутствуют необходимые требования. | · Пользователи не знают, что им нужно. · Аналитик требований не поставил правильные вопросы. · На выявление требований выделено недостаточно времени. · Некоторые классы пользователей не представлены. · Нужные, знающие представители пользователей не участвовали в выявлении требований. · Аналитики, разработчики и клиенты делают неверные предположения или не видят несоответствий в документации требований. · Недостаточный обмен информацией между разработчиками и клиентами. | · Определите классы пользователей. · Определите сторонников продукта. · Подготовьте квалифицированных аналитиков, которые умеют ставить правильные вопросы. · Разработайте варианты использования. · Представьте требования в скольких видах (таких, как модели анализа). · Проверьте документацию требований. Используйте множество пошаговых проверок. · Обучите клиентов основам конструирования требований. · Проанализируйте требовании, используя матрицу CRUD. · Создайте прототипы и передайте их пользователям для оценки. · Используйте инкрементальный подход к созданию продукте, чтобы пропущенные требования удалось включить в следующую версию продукта. |
| · Указанные требования неверны или не подходят. · Требования навязаны вышестоящим руководством или внешним источником. | · Вовлечение не тех представителей пользователей или лиц, их заменяющих. · Представители пользователей выражают свои точки зрения, а не позиции групп, которые они представляют. · Аналитики слишком много общаются с менеджерами и слишком мало с пользователями. · Менеджеры не предоставляют доступ к представителям пользователей, · Недостаток подотчетности или незаинтересованность внешнего источника требований. | · Определите, что именно было неверно в требованиях и почему они были указаны, · Определите классы пользователей, · Определите соответствующих сторонников продукта, обучите их и наделите полномочиями. · Проведите проверку документации требований многофункциональной командой. · Сообщите о факторах риске, связанных с неточными требованиями, заинтересованным в проекте лицам, обладающим полномочиями. |
Таблица В-1, Руководство по поиску и решению проблем, связанных с требованиями
(продолжение)
| Симптомы | Возможные основные причины | Возможные решения | |
| Проблемы, связанные с анализом | |||
| · Указаны ненужные требования («золочение»). · Вовремя тестирования обнаруживаются неожиданные функции. · Функции определяются и реализуются, но не используются. | · Отсутствие контроля за утверждением требований. · Разработчики включают функции без консультаций с пользователями. · Пользователи запрашивают сложные решения, а не выражают бизнес-нужды. · Выявление требований больше сконцентрировано на функциях системы, чем на целях пользователей. · Разработчики и клиенты по-разному трактуют требования. | · Записывайте источник и обоснование каждого требования. · Применяйте варианты использования, чтобы раскрыть бизнес-цели пользователей, а не функции системы. Выводите функциональные требования на основе анализа вариантов использования. · Определяйте приоритеты требований, чтобы реализовать особенно ценные функции на ранних стадиях проекта. · Передайте документацию требований многофункциональной команде для проверки. | |
| · Требования недостаточно ясны, чтобы составить варианты тестирования. | · Требования двусмысленные, не полные или недостаточно детальные. | · Тестировщики или инженеры отдела поддержки качества должны проверить требования на возможность тестирования. | |
| · Требованиям не назначены приоритеты. Все требования кажутся одинаково важными. · Все требования имеют первостепенный приоритет. · Аналитики не могут принимать обоснованные решения о компромиссах, когда появляются новые требования. · Только клиенты занимаются назначением приоритетов. | · Опасения, что требования с низким приоритетом никогда не будут реализованы. · Недостаток знаний о бизнесе и его нуждах, · Информация о ценности и стоимости реализации каждого требования не известна, не сообщается или не обсуждается. · Продукт не пригоден к использованию, пока не реализован большой набор физических функций. · Неразумные ожидания клиентов или разработчиков. | · Разработайте совместный процесс определения приоритетов требований. · Определяйте приоритеты требований на ранних стадиях. Разработайте детальные спецификации требований с высоким приоритетом. · Используйте инкрементальный подход к разработке или пошаговые версии продукта, чтобы реализовать максимум ценных функций продукта как можно раньше. · Осознавайте, что приоритеты могут радикально измениться после выпуска первых версий продукта. | |
Таблица В-1. Руководство по поиску и решению проблем, связанных с требованиями
(продолжение)
| Симптомы | Возможные основные причины | Возможные решения |
| Проблемы, связанные с анализом | ||
| · Изменяющиеся приоритеты требований. | · Люди, принимающие решения, не назначены или не уполномочены это делать. · Микроцели конфликтуют с макроцелями. · Внутренняя политическая борьба. · Неясные бизнес-цели, отсутствие единства мнений относительно бизнес-целей. · Внешние силы, такие, как постановления правительства или законодательная база. · Требования и их приоритеты не утверждены и не внесены в основную версию уполномоченными сотрудниками. | · Документируйте масштабы, цели и приоритеты проекта, · Определите сотрудников, принимающих решения, связанные с требованиями. · Обеспечьте ясную оценку стоимости принятия изменений. · Ведите учет последствий изменений в области расходов, доходов и переноса сроков. · Обеспечивайте соответствие требований бизнес-целям. |
| · Нет единого мнения относительно приоритетов требований между заинтересованными в проекте лицами. | · У различных классов пользователей разные нужды. · Недостаток дисциплины, необходимой, чтобы придерживаться первоначального образа продукта. · Неясные бизнес-цели или отсутствие единства мнений о них. · Неясно, кто принимает решения, связанные с требованиями. | · Еще раз проанализируйте рынок. · Выявите привилегированные классы пользователей или области рынка. · Используйте сторонников продукта для представительства различных классов пользователей. · Определяйте приоритеты на образе, масштабах и бизнес-целях. · Определите, кто принимает решения, связанные с требованиями. |
| · Быстрое сокращение объема на поздних стадиях проекта. | · Нереалистичный оптимизм относительно производительности труда разработчиков. · Слишком раннее и недостаточно периодичное определение приоритетов. · Нет доверия приоритетам при определении последовательности реализации и внесения контролируемых изменений объема. | · Определите приоритеты на ранних стадиях проекта. На основе приоритетов решайте, над чем работать сейчас, а что отложить. · Корректируйте приоритеты, когда вносите новые требования. · Решения о том, чтобы отложить реализацию некоторых функций, принимайте периодически, а не только на поздних стадиях проекта. |
Таблица В-1. Руководство по поиску и решению проблем, связанных с требованиями (продолжение)
| Симптомы | Возможные основные причины | Возможные решения |
| Проблемы, связанные с анализом | ||
| · Разработчики считают требования расплывчатыми и двусмысленными. · Разработчикам приходится искать упущенную информацию. · Разработчики неверно толкуют требования, и им приходится переделывать работу. | · Аналитики и клиенты не понимают, какой уровень детализации требований нужен разработчикам. · Клиенты не знают, что им нужно, или не могут ясно это выразить. · На выявление требований отведено недостаточно времени. · Бизнес-правила не определены, не переданы или не понятны. · Формулировки требований содержат много расплывчатых и неоднозначных слов. · Заинтересованные в проекте лица толкуют термины, концепции и определения данных по-разному. · Клиенты предполагают, что разработчики уже знают достаточно об их области бизнеса и нуждах. · Аналитики боятся показаться несведущими в данной области бизнеса и поэтому не просят помощи у представителей пользователей. | · Учите аналитиков составлять хорошие требования. Избегайте использования субъективных, двусмысленных терминов в спецификации. · На ранних стадиях проекта разработчики должны просмотреть требования, чтобы выяснить, достаточно ли те ясны и детализированы. · Моделируйте требования, что бы обнаружить пропущенные требования и информацию. · Создайте прототипы и передайте пользователям для оценки. · Уточняйте требования с возрастающим уровнем детализации. · Документируйте бизнес-правила. · Определите термины в словаре. · Определите элементы данных в словаре. · Поддерживайте эффективное взаимодействие между всеми участниками проекта. · Используйте знания той области бизнеса, которой владеют представители пользователей. |
| · Некоторые требования технически неосуществимы. | · Требования не анализируются должным образом. · Клиенты не принимают результаты анализа осуществимости. · На оценку осуществимости выделено недостаточно времени, · Непонимание новых инструментальных средств и технологий, а также их ограничений. | · Проведите анализ осуществимости или вертикальное прототипирование. · Проведите отдельное исследование или исследовательский мини-проект для оценки осуществимости. |
Таблица В-1. Руководство по поиску и решению проблем, связанных с требованиями (продолжение)
| Симптомы | Возможные основные причины | Возможные решения |
| Проблемы, связанные с анализом | ||
| · Требования из различных источников или от различных классов пользователей конфликтуют друг с другом. · Трудно достичь соглашения заинтересованных в проекте лиц относительно требований. | · Нет единого образа продукта, о котором руководство сообщает всем заинтересованным в проекте лицам, · Не определены сотрудники, принимающие решения о требованиях. · В разных отделах технологические процессы понимают по-разному. · Политика играет большую роль в определении требований. · У различных групп пользователей или сегментов рынка различные нужды, ожидания и бизнес-цели. · Продукт недостаточно ориентирован на конкретный сегмент рынка. · Некоторые группы пользователей уже применяют систему, к которой они привязаны, несмотря на ее недостатки. | · Разработайте, утвердите и распространите документ о едином образе и границах проекта. · Изучите сегменты целевого рынка и классы пользователей · Определите главные классы пользователей, чтобы избежать конфликтов. · Определите сторонников продукта, чтобы разрешать конфликты внутри каждого класса пользователей. · Определите лиц, принимающих решения о требованиях. · Стремитесь достичь общих бизнес-интересов, а не защищать эмоциональные и политические позиции. |
| · Требования содержат неясности и информационные пробелы. | · Не назначен ответственный за разрешение неясностей до того, как требования передаются разработчикам. · Нет времени на разрешение неясностей до начала реализации. | · Исследуйте требования для выявления информационных пробелов. · Назначьте ответственных за разрешение каждой неясности. · Отслеживайте каждую неясность вплоть до ее разрешения. |
Таблица В-1. Руководство по поиску и решению проблем, связанных с требованиями
(продолжение)
| Симптомы | Возможные основные причины | Возможные решения |
| Проблемы, связанные с документированием | ||
| · Требования не документированы. · Разработчики создают требования для клиентов или отдела маркетинга. · Клиенты сообщают требования разработчикам устно или через неформальные каналы. · Разработчики пишут много пробного кода, пытаясь понять, чего хотят клиенты. | · Никто не знает, что именно нужно создать. · На выявление и документирование требований выделено мало времени. · Бытует мнение, что документирование требований замедляет проект. · Неясно определено, кто отвечает за документацию, или эти люди недостаточно заинтересованы. · Люди, исполняющие функции аналитиков, на знают, что им делать. · He определен технологический процесс разработки требований или шаблоны. · Те, кто управляет разработкой, не понимают, не ценят и не ожидают разработки требований. · Слишком самоуверенные разработчики думают, что знают нужды клиентов. | · Определите и выполняйте технологический процесс разработки требований. · Определите и утвердите у руководства распределение ролей в команде и заинтересуйте людей. · Подготовьте аналитиков требований. · Проведите обучение членов команды и клиентов в области технологических процессов, связанных с требованиями. · Опишите усилия для разработки требований, ресурсы и задачи в соответствующие планы и графики работы. |
| · Клиенты или разработчики предполагают, что функциональность старой системы будет продублирована в новой. | · Требования для новой системы указаны в виде отличий от плохо документированной существующей системы. | · Проведите инженерный анализ существующей системы, чтобы понять ее полные возможности. · Составьте спецификацию требований, включающую всю желаемую функциональность для новой системы. |
| · Документация требований неточно описывает систему. | · Изменения не вносятся в документацию требований. | · Следуйте процессу управления изменениями, включающему обновление документации требований при принятии новых требований. · Проводите все запросы на изменения через совет ГО управлению изменениями. · Встречайтесь с ключевыми заинтересованными в проекте лицами для проверки измененной спецификации требований. |
| · Существуют различные, противоречащие друг другу версии документации требований, | · Плохие приемы управления версиями. · Наличие нескольких «главных» экземпляров документации требований. | · Определите и исполняйте хорошие приемы контроля версий для документации требований. · Храните требования в базе данных инструментального средства управления требованиями. Генерируйте документы, содержащие требования, как отчеты по содержанию базы данных инструментального средства. · Назначьте менеджера по требованиям ответственным за внесение изменений в спецификацию. |
Таблица В-1. Руководство по поиску и решению проблем, связанных с требованиями (продолжение)