Web Analytics Made Easy - StatCounter

Название

русский: Требования к продукту;
английский: Product Requirements Document;

Описание

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

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

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

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

Советы

  • описывайте каждое требование отдельно, либо разбейте их на логические группы: не нужно собирать все требования в одном пункте. Если они взаимосвязаны, сгруппируйте их, например, в соответствии с функционалом. Такое разделение облегчит восприятие и поможет правильно расставить приоритеты.
  • соблюдайте последовательность: у документа должна быть простая структура, чтобы его было легко читать. Если продукт разбит на модули, такие модули стоит расположить в логической последовательности: например, если продукт создается пользователем, то сначала нужен модуль пользователя, а потом уже модуль продукта.
  • давайте четкие указания: старайтесь избегать таких фраз, как «если необходимо», «по возможности».
  • исключите любые неясности: старайтесь избегать слов «примерно», «и так далее». Любые используемые определения должны иметь однозначное значение: например, слово «удобный» может означать разное для разных людей.
  • нужно рассуждать не о том, КАК сделать, а о том ЧТО нужно сделать.
  • храните все требования в одном месте (например, мы используем Trello): должна быть одна точка входа для требований, и все участники проекта должны знать о том, где их найти.
  • если над требованиями работают несколько человек, определите одного человека, который будет отвечать за согласование, иначе потеряется целостность.