Требования — ключ к успешному проекту

Представьте, что в требованиях к автомобилю забыли указать одну из важных для вас характеристик — развиваемую скорость 350 км/ч. В итоге с конвейера сойдет рабочая машина, но выиграть в гонках на ней уже не получится — не хватит мощности. И проще создать еще одну, чем переделать ее в автомобиль для трека. И, напротив, забыв указать клиренс — победите в ралли, но не доедете до дачи.

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

Цель

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

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

Содержание документа

В требования должны входить сама формулировка, приоритетность (обратите внимание: критичными может быть не более 30% требований, а не все), версия или этап проекта, для которого работает данный пункт. А также степень проработанности документа и каждого утверждения в отдельности.

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

Требования к… требованиям

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

• решение должно обеспечивать возможность создания, редактирования или удаления записи о сотруднике (при этом реализация в виде файла с записями требованию соответствует);
• одного топливного бака автомобиля должно хватить на 500 километров.

А вот, для сравнения, плохие:

• решение должно быть переносимо на другие операционные системы (Какие? В какой срок? Какими силами?);
• быстродействие системы (1, 10, 100 или 1000 мсек?).

Небольшой чек-лист для проверки требований на соответствие ИТ-стандартам, принятым у разработчиков:

• Полнота. Должны быть описаны все существенные свойства системы.
• Не избыточность. Не стоит описывать то, что неважно или АБСОЛЮТНО очевидно.
• Проверяемость. Каждое требование можно проверить в режиме здесь и сейчас, а не с помощью длительного создания особых условий.
• Однозначность и непротиворечивость. Формулировка не должна допускать разночтений.
• Отчуждаемость. Об этом мы уже писали в блоге. Важно составлять документы так, будто по ним будет работать другой исполнитель.

Авторство

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

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

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

Как быть убедительным при ревью требований?

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

Команда Digital Zone с радостью делится несколькими лайфхаками:

• красочные презентации;
• скетчи интерфейсов и прочая графика;
• разбивка верификации на части и поручение задачи разным сотрудникам. Именно тем, кто будет
• ответственным за конкретную подсистему.

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