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

• Вернитесь к проблемам с требованиями, которые вы определили, вы-
полняя задания раздела «Что теперь?» главы 1. Выберите описанные
в этой главе приемы, которые помогут вам решить все эти проблемы.
Сгруппируйте приемы по их влиянию на вашу организацию (силь-
ное, среднее и слабое). Определите, какие препятствия в организации
или культуре способны помешать вам воспользоваться тем или иным
приемом. Кто поможет вам устранить эти препятствия? Можете ли вы
выбрать одно действие, чтобы работать эффективнее, чем раньше?
• Определите, как бы вы оценивали приемы, которые считаете наиболее
ценными. Позволят ли они уменьшить число некорректных требова-
ний, выявляемых на поздних стадиях работы над проектом, умень-
шить объем ненужных доработок, точнее следовать графику проекта
или предоставят какие-то другие преимущества?
• Перечислите все приемы формулирования требований, определенные
на первом этапе. Укажите, насколько члены вашей команды овладели
на сегодняшний момент тем или иным приемом: эксперты, опытные
специалисты, новички или не знакомые с данным приемом. Если ква-
лификация членов команды ниже, чем опытных специалистов, попро-
сите одного из них изучить данный прием и поделиться полученными
знаниями с остальными членами команды

Пересмотр обязательств по проекту при изменении требований Команда
проекта принимает обязательство предоставить определенные наборы требова-
ний в рамках определенного бюджета и за определенное время. Добавляя в про-
ект новые требования, оцените, удается ли выполнить текущие обязательства с
имеющимися ресурсами. Если нет, обсудите реалии проекта с менеджерами и
согласуйте новые, более реалистичные обязательства (Wiegers, 2007; Fisher, Ury
и Patton, 2011). Может также потребоваться повторно согласовывать обязатель-
ства по мере того, как требования будут развиваться от состояния неопределен-
ности при начальной оценке до ясных и четких проверенных требований

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

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

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