19.06.2017

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

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


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


Цель

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

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

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

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


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


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

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

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

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

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

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

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

Авторство

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


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


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


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

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


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

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

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

Вернуться в блог