Если различные клиенты вашего продукта не достигли соглашения относительно того, что именно вы должны разрабатывать, кто-то их них останется недоволен результатом. Определите основных клиентов и используйте сторонников продукта для получения адекватного представительства и вовлечения клиентов. Удостоверьтесь, что вы полагаетесь на правильно выбранных людей, которые имеют полномочия для принятия решений.
Не сформулированные требования. У клиентов часто есть скрытые ожидания, о которых они не сообщают, и потому те не документируются. Постарайтесь выявить любые допущения, которые может делать клиент. Используйте вопросы в свободной форме, чтобы поощрить клиентов больше делиться своими мыслями, пожеланиями, идеями, информацией и сомнениями.
Использование существующего продукта в качестве базовой версии. Разработка требований считается не важной в проектах следующего поколения или при переделке предыдущих проектов. Разработчикам иногда рекомендуют использовать существующий продукт в качестве источника требований, со списком изменений и дополнений. Это вынуждает их собирать требования ч;рез инженерный анализ текущего проекта. Однако это не эффективный и не полный способ выявления требований, поэтому не удивляетесь, если у новой системы проявятся некоторые недостатки исходной системы. Документируйте требования, извлекаемые таким способом, и просите клиентов проверить их, чтобы убедиться, что они верны и до сих пор актуальны.
Решения, предлагаемые в качестве потребностей. Предлагаемые пользователями решения могут скрывать их действительные нужды, вести к повтору неэффективных бизнес-процессов и заставлять разработчиков принимать плохие конструкторские решения. Задача аналитика — докопаться до потребности клиента, скрытой предлагаемым решением,
Анализ требований
Определение приоритетов требований. Удостоверьтесь, что каждое функциональное требование, функция или вариант использования получило приоритет и приписано к конкретной версии или итерации системы. Оцените приоритет каждого нового требования по отношению к объему оставшейся работы, чтобы иметь возможность принимать разумные решения о компромиссах.
Технически сложные функции. Оцените осуществимость каждого требования, чтобы определить те из них, реализация которых может занять больше времени, чем ожидается. Нам всегда кажется, что успех — рядом, за углом, поэтому трассируйте статус проекта, чтобы следить за требованиями, реализация которых отстает от графика. Старайтесь исправлять ситуацию как можно раньше.
Незнакомые технологии, методы, языки, инструменты или аппаратное обеспечение. Не нужно недооценивать кривую обучения работе с новыми методами, необходимыми для удовлетворения некоторых требований. Выявляйте эти рискованные требования в начале проекта и выделяйте достаточное время на фальстарты, обучение, эксперименты и прототипирование.
Спецификация требований
Понимание требований. Различия в интерпретации требований разработчиками и клиентами ведут к расхождениям в ожиданиях, когда произведенный продукт не способен удовлетворить нужды клиентов. Формальная экспертиза документации требований разработчиками, тестировщиками и клиентами уменьшают этот риск. Подготовленные. опытные аналитики требований могут задать клиентам верные вопросы и составить высококачественные спецификации. Модели и прототипы, представляющие требования с разных точек зрения, также позволяют выявить неясные, неопределенные требования.
Спешка, заставляющая пропускать пометки «TBD». Полезно выделять области спецификации требований, которые требуют доработки специальными пометками, например «TBD», но рискованно начинать конструирование, пока они не сняты. Записывайте имя человека, отвечающего за разрешение каждой неясности и планируемые сроки разрешения.
Неоднозначная терминология. Создайте словарь для определения бизнес- или технических терминов, которые могут быть истолкованы разными читателями по-разному. В частности, определите любые термины, имеющие как общее, так и техническое или узкоспециальное значения. Создайте словарь данных, где определяются элементы и структуры данных. Экспертиза спецификации требований поможет участникам выработать общее понимание ключевых терминов и концепций.
Включение дизайна в требования. Описание дизайна в спецификации требований налагает ненужные ограничения на возможности, доступные разработчикам. А те сдерживают создание оптимальных конструкций. Удостоверьтесь, что требования описывают, что необходимо сделать для решения бизнес-проблемы, а не то, как это должно быть сделано.
Утверждение требований
Неутвержденные требования. Перспектива утверждения длинной спецификации требований пугает, как и мысль о написании вариантов тестирования в самом начале процесса разработки. Тем не менее, если вы подтвердите корректность и качество требований до начала конструирования, то сможете избежать значительной и дорогой переделки на более поздних стадиях проекта. Выделите время и ресурсы на эти действия в план проекта. Обяжите представителей клиентов участвовать в проверке требований, потому что только они могут судить, удовлетворят ли сформулированные требования их нужды. Также проводите пошаговые, неформальные экспертизы, чтобы выявлять проблемы как можно раньше и дешевле.
Качество проверки. Если проверяющие не знают, как проводить экспертизу документации требований и какие действия эффективны при проверке, они могут упустить серьезные дефекты. Обучайте всех членов команды, которые будут участвовать в экспертизе. Пригласите человека с опытом проверки из вашей или сторонней организации для наблюдения и, возможно, координации ваших первых опытов, чтобы тренировать участников.
Управление требованиями
Изменение требований. Вы можете уменьшить расползание границ проекта, используя документ о его образе и границах в качестве контрольных точек для утверждения изменений. Объединение выявления требований с существенным участием пользователей может сократить расползание требований примерно вполовину (Jones 1996а). Методы контроля качества, определяющие ошибки в требованиях на ранних стадиях, сокращают количество последующих модификаций. Чтобы уменьшить влияние изменения требований, отложите реализацию тех из них, которые, скорее всего, изменятся, пока они не будут определены, а также проектируйте систему, закладывая возможность легкой модернизации.
Процесс изменения требований. Риск, связанный с тем, как происходит изменение требований, зависит и от отсутствия определенного процесса изменений, использования неэффективных механизмов изменений и внесения коррективов без учета этого процесса. Развитие культуры и дисциплины управления изменениями требует времени. Очень важно, чтобы при изменении требований применялся анализ воздействия предлагаемых изменений, решения принимал совет по управлению изменениями, и использовалось инструментальное средство для поддержки определенной процедуры.
Нереализованные требования. Матрица трассируемости требований помогает избежать пропуска каких-либо требований во время проектирования, конструирования или тестирования.
Увеличение объема проекта. Если требования изначально плохо определены, дальнейшее их выявление может увеличить объем проект! Реализация нечетко определенных областей продукта потребует больше усилий, чем ожидалось. Ресурсы проекта, распределенные в соответствии с начальными неполными требованиями, могут оказаться недостаточными для удовлетворения полного спектра нужд пользователя. Для смягчения этого риска планируйте жизненный цикл, состоящий из поэтапных или разработанных средствами инкрементального моделирования версий. Реализуйте базовую функциональность в первом выпуске и наращивайте способности системы далее.