Какие бывают требования к продукту


Виды требований к программному продукту

01.03.2018 18:48

Текстовая расшифровка третьего видеоурока курса Введение в профессию аналитика.

Давайте более подробно рассмотрим виды требований, и будем при этом пользоваться классификацией Вигерса. Возможно, многие из вас уже с этой классификацией знакомы. Я для каждого вида требований приведу пример.

Вот эта картинка Вигерса, о которой я уже говорил, и на которой он перечислил различные виды требований. Эти названия уже, пожалуй, общеприняты. Большинство аналитиков их понимает, но иногда всё-таки путаются. Давайте мы по ним пройдёмся.

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

Самый первый вид требований: бизнес-требования. Что это такое, обобщённо? Описание высокоуровневых целей организации или заказчика, достигаемых посредством разрабатываемой системы.

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

Что дает описание бизнес требований? Описывает бизнес-идею, без реализации которой продукт не будет нужен потребителю. Это описание тех самых проблем и возможностей, для решения или реализации которых создается продукт.

Например, если мы разрабатываем сайт поиска авиабилетов, мы можем описать в бизнес-требованиях, какие возможности он предоставляет.

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

Авиакомпаниям дает возможность использовать дополнительный канал продаж авиабилетов. Владельцу сайта дополнительно может дать возможность продавать на сайте что-то ещё. Например, дополнительные услуги для путешественников — бронирование машин, заказ гостиниц, заказ такси и так далее.

Вполне можно включить такой перечень возможностей в Концепцию, и эти бизнес-требования будут определять образ нашего продукта в целом и влиять на способ его разработки.

Тут я должен сделать оговорку, и я её сделаю ещё не раз в этом модуле, что те примеры, которые я привожу, достаточно искусственны в том смысле, что они не похожи на реальные формулировки требований в реальных документах. Но мы будем изучать собственно методы разработки бизнес-требований, и там мы поймем, что за этими формулировками стоит перечень заинтересованных лиц (в данном случае вот они перечислены: посетитель сайта, авиакомпания, владелец сайта — это всё заинтересованные лица), перечень предоставляемых возможностей, а за этими возможностями стоят какие-то проблемы, которые решает сайт.

В конечном итоге при описании требований они будут выглядеть несколько иначе. Но для того, чтобы понять, что стоит за этим видом требований, я привел такой пример. В данном случае этот перечень возможностей — бизнес-требования к сайту поиска авиабилетов.

Часто бизнес-требования путают с бизнес-правилами, потому что они начинаются со слова «бизнес». Что понимается под бизнес-правилом? Положение, определяющее или ограничивающее какие-либо стороны бизнеса. Я не буду перечитывать то, что написано у Вигерса, а лучше сразу покажу на примерах, что за этим стоит.

За этим стоят, во-первых, какие-то документы, регламентирующие на уровне законов или отраслевых стандартов (или ещё каких-то стандартов) то, как должен работать наш продукт. Если, например, мы разрабатываем банковскую систему, то там есть огромное количество правил, которые генерируют Центробанки. Если говорить о России, то это наш Центральный Банк, который выпускает различные инструкции, и банковская система должны обязательно им следовать.

Это законы. Сейчас это становится более актуальным для интернет-проектов в нашей стране, потому что выпускается всё больше законов, регулирующих эту отрасль.

Это могут быть ещё какие-то общепринятые или стандартные функции и алгоритмы, которые должны быть реализованы в системе. Ну, первое что приходит в голову, — например, алгоритм расчёта НДС, который тоже является бизнес-правилом.

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

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

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

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

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

Следующий вид требований: пользовательские требования.

Это большой класс требований. Я его, наверное, достаточно подробно описал, когда говорил о втором — пользовательском — уровне требований. Описывает конкретный способ использования продукта конечным пользователем.

Как я уже сказал, основная масса существующих методов разработки требований относится именно к этому уровню. Use Cases, User Stories, «персоны» и ещё некоторые методы, не так часто используемые. Лучше всего проработанные, концептуально завершенные, они как раз относятся к уровню взаимодействия людей с продуктом. Но это естественно, потому что продукты, в основном, до сих пор создаются для людей.

Здесь может быть очень много разных примеров. Я даже не стал их детализировать.

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

Мы можем описать требования в виде набора user stories, например, для интернет-магазина. Если я хочу выполнить покупку на сайте интернет-магазина, то мне нужно будет реализовать user stories для сравнения товаров, для добавления в корзину, для управления корзиной и оформления заказа, для онлайн-оплаты. Каждая user story имеет определенный формат, который не представлен на этом слайде.

Каждая user story — это такой единичный кусок, unit при разработке требований, обладающий своими собственными характеристиками, и разработанный по определённому методу.

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

Атрибуты качества. Более детально мы атрибуты качества рассмотрим ещё сегодня на этом вебинаре.

Что за этим стоит? Свойство продукта, выраженное через описание характеристик, важных для пользователей или разработчиков. Тоже несколько суконное определение.

Есть понятие качества программного обеспечения или качества программного продукта. Для него есть стандарты, там есть своя теория, есть методы определения качества, его оценки, обеспечения качества. И за этим стоит множество разных точек зрения на то, как должен работать программный продукт.

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

Я снова делаю оговорку: то, что здесь написано, это не сами атрибуты качества, а то, как могут выглядеть требования, которые эти атрибуты качества представляют по отношению к создаваемому продукту.

Например, время загрузки главной страницы и карточки товара не должно превышать 3 секунд при нагрузке до 20 посетителей в минуту. Это требование отражает атрибуты качества «производительность» и «надёжность». Производительность — это время загрузки страницы, а надёжность — это какую нагрузку должен держать сайт.

База данных сайта должна устанавливаться на сервера mysql или MS SQL Server или Oracle без необходимости внесения изменений в установочные скрипты. Это, опять же, конкретное представление требования, которое отражает такой атрибут качества как «переносимость». Мы можем наш разработанный сайт устанавливать в разном окружении, и при этом должны быть реализованы эти требования, чтобы мы могли использовать разные системы баз данных.

Сайт должен быть адаптирован для мобильных устройств. Это может вам показаться спорным, но это требования тоже отражают атрибут качества. Удобство использования тоже является атрибутом качества. Сейчас он больше известен под словом «юзабилити», которое в стандарте последнем так и переведено: «удобство использования».

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

Я должен сказать, что книга Вигерса уже выдержала три издания, и он в каждом издании эту картинку немножко меняет. Он перемещает отдельные виды требований между разными уровнями, он иногда меняет зависимости между ними. Это нормально, и это отражает тот факт, что в общем-то все требования на самом деле связаны друг с другом. Почему я об этом вспомнил: потому что раньше бизнес-правила у него находились на втором уровне, а сейчас он их поднял наверх, на уровень бизнес-требований.

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

Мы лучше всего знаем, наверное, ограничения технические, которые часто отражаются в ТЗ, исходя из имеющихся возможностей заказчика или разработчика.

Например: сервер приложений сайта должен разрабатываться на языке Java. Почему? А потому что, например, у заказчика есть множество специалистов, которые могут эту джаву сопровождать, и все другие его сервера приложений тоже работают в этом окружении.

Или похожий пример: сайт должен устанавливаться на определенную версию операционной системы.

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

Внешние интерфейсы. Описание интерфейса между системой и пользователем, другой системой или оборудованием.

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

Ну например, что это может быть.

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

Спецификации взаимодействия с платежным агрегатором для оплаты на сайте — тоже распространённый внешний интерфейс. Если вы принимаете оплату в любом интернет-магазине, то должен быть реализован такой интерфейс взаимодействия с платежным агрегатором. Это определенная спецификация передачи данных, и она собой представляет описание внешнего интерфейса.

Ещё пример: протокол взаимодействия с сервером транспортной компании для резервирования и оплаты билетов. Уже приведенный пример для авиакомпаний: единая точка для возможности сравнить и купить билеты разных авиакомпаний. Для такого сервиса очень важными тоже являются внешние интерфейсы взаимодействия с разными внешними сервисами резервирования и оплаты билетов.

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

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

Я знаю, что во многих компаниях термин «системные требования» используется для всего третьего уровня требований. Практически все знают, что такое бизнес-требования, что такое пользовательские требования тоже все прекрасно понимают. А вот на этом (третьем) уровне я предлагаю использовать термин «требования к реализации», Вигерс предлагает использовать термин «функциональные требования», но я знаю несколько компаний, где для обозначения этого всего использовуют термин «системные требования».

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

Доступ к операциям со счётом (речь идет об интернет-банке) должен обеспечиваться через единый сервер приложений, с которым взаимодействуют клиентские приложения, три разных: интернет-банк в браузере пользователя, либо интернет-банк в мобильном приложении на телефоне, либо интернет-банк в отдельном Java-приложении, которое запускается на компьютере пользователя (обычно это обеспечивает более высокую защиту с использованием каких-то ключей, и поэтому даёт больше возможностей в управлении своим счётом). В данном случае это требование описывает систему в целом, и нам становится понятно, что у нас есть разные варианты клиентской части приложения, но все эти варианты должны работать с единым сервером.

Функциональные требования. Я говорил, что мне не нравится называть так целый уровень требований именно потому, что в этом случае он перемешивается вот с этим видом требований, и получается некоторая путаница.

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

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

Давайте пока просто на примеры посмотрим. Но эти примеры, наверное, не отражают и на пять процентов (а может быть, и на один процент) всё разнообразие методов представления этих требований, потому что они очень сильно зависят от разрабатываемой системы.

Например, на сайте должен быть реализован поиск статей по ключевым словам и по проставляемым тегам. Это дает нам требования к поиску или, собственно, к функции «поиск» — что должно быть реализовано на сайте.

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

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

Давайте мы на этом закончим обзор видов требований. Это такой очень верхнеуровневый обзор, который даёт только, собственно, определения. Так, чтобы в рамках курса, когда мы будем говорить о бизнес-правилах, вы их не путали с бизнес-требованиями, или чтобы вы понимали, чем пользовательские требования отличается до внешних интерфейсов. В общем, эта часть просто задаёт определенную терминологию.

 


Предыдущий урок: Уровни требований к программному продукту

Следующий урок: Функциональная и нефункциональная стороны программного продукта

Каковы требования к продукту? - Requirements.com

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

Компании, которые периодически представляют новые продукты, имеют больше шансов добиться успеха на сегодняшнем конкурентном рынке. Компании тратят миллиарды долларов на разработку новых продуктов, и в то же время от 40 до 90 процентов (в зависимости от категории) новых продуктов терпят неудачу (Harvard Business Review, 2011).

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

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

Пользователь определяется как: «Тот, кто потребляет или использует товар или услугу для получения выгоды или решения проблемы, и который может быть или не может быть покупателем товара». Клиент определяется как: «Сторона, которая получает или потребляет продукты и имеет возможность выбирать между различными продуктами и поставщиками» (Business Dictionary, 2017).

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

Требования Атрибуты (функции)

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

Для общих требований к продукту - требуемые атрибуты включают следующее:

  • Понятно - требование однозначно определено.
  • Complete - все, что нужно - состоит в требовании.
  • Достоверно - требование должно быть технически возможным.
  • Согласовано - требование не противоречит другим требованиям.
  • Проверяемый - требование должно быть проверено и подтверждено (поэтому оно должно быть выражено в физических единицах и измеримых атрибутах).
  • Необходимое - если какое-то требование приносит очевидную пользу для бизнеса - оно может рассматриваться как более необходимое, чем другие требования, которые «приятно иметь» (например,г. цвет продукта).

Жизненный цикл требований к продукту

Жизненный цикл требований к продукту включает следующие фазы:

  • Сбор требований,
  • Анализ требований,
  • Проверка / подтверждение требований,
  • Управление и отслеживание требований,
  • Техническое задание (документация).

Теперь мы кратко опишем каждую из этих фаз.

Сбор требований к продукции

На этом этапе мы должны определить источники требований к продукту и подход к их обработке и управлению. Важно указать все источники:

  • Цели, также известные как «деловые вопросы» или «критические факторы успеха», представляют собой всеобъемлющую цель продукта. Особое внимание следует уделить стоимости достижения цели (через технико-экономическое обоснование).
  • Знание предметной области - инженер-технолог должен знать предметную область применения продукта и быть впереди других; разрешать конфликты в требованиях и быть посредником между всеми участниками.
  • Заинтересованные стороны - некоторые продукты могут оказаться неудовлетворительными из-за различных точек зрения заинтересованных сторон. Инженеру по продукту необходимо определить правильное представление и управлять этими ситуациями (разные культуры и политики).
  • Операционная среда - требования к продукту исходят из среды, в которой продукт используется ежедневно.
  • Организационная среда - продукт должен поддерживать бизнес-среду и процессы (условия), при которых он будет ее использовать. Новый продукт не должен приносить незапланированных изменений, поэтому он требует тщательного анализа со стороны создателей продукта перед принятием окончательного решения.

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

Необходимо подготовить сценарии для выявления требований:

  • Предоставление основы для определения вопросов: Что, если...? Как это делается ..? пр.
  • Использование техники, известной как концептуальное моделирование, т.е. моделирование случаев и диаграммы.

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

Анализ требований

После процесса сбора требований - необходим процесс их анализа.Анализ требований относится к процессам, необходимым для:

  • Выявление и устранение конфликтов между требованиями к продукту;
  • Обнаружение характеристик продукта и его поведения в реальных условиях;
  • Разработка требований к продукту в процессе разработки продукта.

Традиционный взгляд на анализ требует использования концептуального моделирования и других методов анализа, таких как метод структурированного анализа и проектирования (SADT).

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

Анализ требований включает:

1. Классификация требований;

2. Концептуальное моделирование;

3. Архитектурное проектирование и распределение требований.

4. Разрешение конфликтов (согласование требований).

Проверка и подтверждение требований

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

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

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

• Четко ли сформулированы требования? Могут ли они быть неверно истолкованы?

• Охвачены ли все аспекты эксплуатации (функционирования) продукта?

• Определен ли источник запроса (например,г. лицо, положение, документ)? Была ли подтверждена окончательная форма требования из первоисточника?

• Определено ли требование количественно?

• Какие еще требования связаны с этим требованием? Ясно ли они указаны с использованием справочной матрицы или другого механизма?

• Влияет ли требование на ограничения домена?

• Можно ли протестировать требование? Если можно, можем ли мы определить тесты (так называемые критерии валидации) для проверки требований?

• Можно ли отслеживать требование в любом создаваемом продукте?

Управление и отслеживание требований к продукции

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

Управление требованиями начинается с идентификации. Каждому требованию присваивается уникальный идентификатор следующего вида:

<тип требования> <идентификатор требования>

, где <тип требования> может принимать следующие возможные значения: F = функциональное требование, B = поведенческое требование, I = входное требование, O = выходное требование и т. Д.Таким образом, требование, обозначенное F09, обозначает функциональное требование номер 9.

После определения требований составляются таблицы мониторинга (отслеживания). Каждая таблица отслеживания связывает определенные требования с одним или несколькими аспектами продукта или среды. Вот некоторые из многих графиков отслеживания:

  • Таблица отслеживания свойств - показывает, как требования соотносятся с видимыми функциями продукта.
  • Таблица отслеживания источника (причины) - определяет источник каждого требования.
  • Таблица отслеживания зависимостей - показывает, как требования связаны друг с другом.
  • Subsystem Tracking Table - классифицирует требования в соответствии с подсистемами, к которым они принадлежат.

Документация по требованиям к продукции

После сбора и анализа требований к продукту аналитик продукта и команда проекта должны определить все требования к продукту. По техническому заданию - должно быть составление (оформление) Документации требований к продукции (ПРД).

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

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

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

Типы требований к продукции

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

Функциональность

Каждый продукт разрабатывается со своими основными целями (задачами). Например - автомобили предназначены для того, чтобы доставить нас к месту назначения на автомобиле, с определенными техническими характеристиками, внешними и внутренними особенностями и т. Д.Функциональные требования к продукту должны включать все технические детали, чтобы обеспечить его бесперебойную работу.

Качество

Качество - это любой элемент (характеристика), измеримый или нет, который придает вещам ценности, выходящие за рамки их функциональности и свойств. Типичные требования к качеству включают: надежность продукта, согласованность, долговечность, доступность, качество обслуживания клиентов, внешний вид, производительность, ремонтопригодность, материалы / ингредиенты и т. Д.

Удобство использования

Требования к удобству использования созданы, чтобы гарантировать простоту использования продукта. Юзабилити - это широкое понятие, но его можно разделить на более элементарные, например, интуитивно понятные и простые в освоении, чтобы пользователи могли выполнять задачи, не прерываясь. Также - они должны повысить продуктивность и производительность пользователя при использовании продукта.

Надежность

Надежность - одно из важнейших нефункциональных требований (качества).Надежность измеряется как наработка до отказа, вероятность отказа и безотказная работа. Он также определяет среднее время ремонта и между ремонтами, коэффициент готовности и недоступности, частоту отказов и т. Д.

Безопасность

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

Упаковка

Требования к упаковке относятся к упаковке продукта, и его цель - защитить продукт от повреждений при транспортировке, а также в маркетинговых (дизайнерских) целях. Требования к упаковке регулируются правилами всех стран мира. Например, Европейский Союз ввел Директиву о правилах упаковки в 1998 году, и ее необходимо соблюдать во всех странах ЕС. Он начинается с массивных контейнеров, опасных материалов, химикатов, а также включает продукты питания и небольшие пакеты.

Список литературы

  1. С. Робертсон и Дж. Робертсон, Освоение процесса требований, Аддисон-Уэсли, 2012 г.
  2. Ян Ф. Александер, Л. Беус-Джукич, Требования к обнаружению: как указать продукты и услуги, Wiley, 2009.
  3. И. Соммервилл и П. Сойер, Разработка требований: руководство по передовой практике, John Wiley & Sons, 1997.
  4. Р. Х. Тайер и М. Дорфман, ред., Разработка требований к продукции, IEEE Computer Society Press, 1997, стр.176-205, 389-404.
  5. Р. Р. Янг, Эффективные практики требований, Аддисон-Уэсли, 2001.
2019-11-11 Requirements.com Все о требованиях 2020-09-20 Морган Мастерс Каковы требования к продукту? .

Определение требований к продукту - ваша Европа

Последняя проверка: 16.04.2020

Коронавирус, медикаменты и средства защиты

Комиссия опубликовала информацию на (только на английском языке):

Для получения дополнительной информации вы также можете связаться с национальными контактными пунктами по вопросам медицинского оборудования.

Европейские органы по стандартизации бесплатно предоставили ряд стандартов на медицинские устройства и средства индивидуальной защиты:

Общеевропейские стандарты и технические спецификации существуют для ряда категорий продуктов.Вы должны убедиться, что ваши продукты соответствуют любым соответствующим правилам ЕС, прежде чем они смогут свободно продаваться в ЕС.

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

Какие требования к продукту?

Закон ЕС устанавливает основных требований для обеспечения того, чтобы товары, продаваемые в ЕС, соответствовали высоким стандартам в области здравоохранения, безопасности и окружающей среды.

Требования могут покрывать:

  • сам продукт: например, воспламеняемость, электрические свойства или гигиена

  • процесс изготовления продукта

  • производительность продукта: например, его энергоэффективность.

В большинстве случаев закон определяет результаты, которые должны быть достигнуты, или опасности, которые необходимо устранить, но не определяет технические решения.

Иногда гармонизированные стандарты могут помочь вам продемонстрировать соответствие закону.

Где найти требования к продукции ЕС

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

Вы можете проверить требования к вашему продукту в базе данных Trade Helpdesk.

База данных Trade Helpdesk предлагает информацию о:

  • правила и нормы для вашего продукта

  • компетентные органы, с которыми можно связаться по вопросам особых требований к продукту

  • Ставки НДС и акциза, применяемые к вашему товару в стране сбыта ЕС

База данных Trade Helpdesk построена на основе пользовательских кодов: чтобы просмотреть требования к вашему продукту, вам сначала нужно будет указать его таможенный код.Если вы не знаете таможенный код, вы можете найти его по названию вашего продукта с помощью встроенной поисковой системы.

Где найти национальные требования к продукту

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

Если ваши продукты соответствуют этим требованиям в вашей стране ЕС, другие страны ЕС не могут:

  • запретить продажу вашей продукции

  • обязывают вас изменить их

  • заставит вас пройти дополнительное тестирование

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

Если вы столкнулись с проблемой, связанной с несовместимостью правил продукта в другой стране ЕС с принципом взаимного признания, вы можете обратиться за помощью в SOLVIT.

Национальные правила

Правительства стран ЕС обязаны публиковать свои национальные правила. Вы можете узнать больше о национальных правилах и принципе «взаимного признания» в базе данных TRIS для негармонизированных правил продуктов.

В частности, требования национальных правил могут отличаться для:

  • размер / размеры

  • вес

  • состав

  • маркировка

  • упаковка

  • тестирование

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

Ограничения, основанные на национальных правилах

Если ваши продукты представляют риск для общественных интересов , в соответствии с законами других стран ЕС, которые влияют на:

  • Здоровье и жизнь людей, животных или растений

  • охрана окружающей среды

  • общественная безопасность или общественная мораль

Вам может быть отказано в их свободном экспорте.

Ваши продукты могут быть запрещены , если страна ЕС, в которую вы хотите экспортировать, может доказать, что ее собственные технические требования являются существенными или обязательными , и ваши продукты не эквивалентны с точки зрения требуемого уровня безопасности.

Чтобы узнать, какие национальные правила применяются к конкретным продуктам в каждой стране ЕС или подробные сведения о компетентных органах в этой стране, вы можете связаться с контактными лицами по продуктам.

.

Управление процессом определения требований к продукту

Введение

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

Целью этого документа является четкое представление преимуществ формализованного подхода PRD путем обрисовки последовательности действий, введения примеров компонентов шаблона и обсуждения важности вопросов управления, таких как управление изменениями, стратегии управления рисками и управление знаниями.

Компоненты процесса определения требований к продукту

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

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

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

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

4. Составьте карту воздействия на бизнес, включая конкретные проблемы управления изменениями и приоритеты воздействия, которые, по вашему мнению, ускорят или затруднят внедрение предлагаемого продукта.

5. Определите стратегии управления рисками для обеспечения успеха инициативы продукта.

6. Задокументируйте ключевые этапы плана внедрения продукта.

7. Получите одобрение всех сторон Документации с определением требований к продукции.

8. Определите команду по передаче знаний.

Процесс требований и спецификации

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

Бизнес-пример и требования

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

Приложение 1. Процесс определения объема

Приложение 2

Шаблон бизнес-модели

Элемент № 1: Что должна выполнять программа?

1. Опишите общую бизнес-цель или задачу, решить которую поможет решение.

2. Повлияет ли предлагаемая разработка на вашу бизнес-модель? Если да, то как?

3.Какие организации будут участвовать в вашем решении с «деловой» точки зрения, например, торговые партнеры, бизнес-партнеры и т. Д.? Опишите отношения и деловые отношения между вашей компанией и этими партнерами.

4. Каково ваше видение деловых отношений с конечными пользователями?

5. Кого вы видите в качестве различных «типов пользователей» вашей системы? Кто конечные пользователи? Кто такие системные администраторы? Как они вписываются в бизнес-модель и какова роль каждого в решении?

6.Каковы ожидаемые сроки завершения?

7. Перечислите ключевые этапы внедрения этой системы.

8. Какие общие требования вы предполагаете в своем решении?

Элемент № 2: Кто сделает это, и готова ли организация к изменениям?

Примечание. Следующие вопросы касаются среды изменений в организации с упором на роли, обязанности и влияние программы. Заинтересованные стороны - это люди или группы, которые «заинтересованы» в успехе или неудаче программы.Ставка может заключаться в ответственности или подотчетности за успех программы, участие в дублирующей или связанной программе или участие в определении, развертывании или использовании программы.

1. Кто принимает основные решения? (идти / нет, бюджет, ответственность за успех)

• Имя (необязательно)

• Должность / должность

• Отдел / функция

2. Какова роль лица, принимающего решения? (Отметьте все, что подходит.)

• Задайте направление

• Отслеживайте прогресс

• Сообщайте результаты руководству

• Отвечает за успех программы

• Отвечает за бюджетные решения и переговоры

• Отвечает за обеспечение спонсорской поддержки в организации

• Сообщите направление организации

• Реализуйте особенности программы / продукта

• Другое (просьба указать)

3.Кто будет отвечать за успешное определение и реализацию продукта?

4. Какие ресурсные роли будут включены в команду проекта?

5. Кто должен «спонсировать» проект, чтобы он был успешным через организацию (например, заинтересованные стороны в руководстве, потенциальные препятствия в руководстве, другие внутренние / внешние партнеры)? Проверить все, что относится.

• Генеральный директор / президент

• ИТ-директор / ИТ-группа

• Главный операционный директор

• Группа исполнительного руководства

• Конкретные руководители (укажите функцию)

• Ключевой персонал в организации (e.g., активные сторонники / «противники»)

• Ключевые клиенты (внутренние или внешние)

• Внешние партнеры (например, консультанты, стратегические партнерства)

• Другое (укажите, например, слияния, независимые бизнес-единицы , внутренняя консультационная группа и т. д.)

6. Кто ваши защитники - кто в вашей организации будет активными сторонниками проекта вместе со своими коллегами? Кто может возразить против того, что вы можете привлечь к проекту (потенциальных новообращенных)? Кто будет вашими опытными пользователями? Сколько у вас будет пользователей? Каков технический уровень ваших групп пользователей?

7.Какие стратегии вы планируете использовать, чтобы получить поддержку и привлечь новых клиентов? (Выберите все подходящие варианты.)

• Планирование коммуникаций

• Семинары

• Создание спонсорского комитета

• Группы пользователей

• Пилотное тестирование

• Изменить программу

• Другое (укажите)

7. Что «Партнеры» внутри и вне организации будут затронуты этим проектом (например, новые процессы, информационные ссылки / обмен)? Рассмотрим поставщиков, инструкторов, человеческие ресурсы, ИТ, поставщиков, клиентов, сторонние услуги и т. Д.

8. Пожалуйста, проверьте характеристики, применимые к этой программе (см. Приложение 2):

Элемент № 3: Как вы это делаете сегодня - какова ваша текущая бизнес-среда по сравнению с запланированной?

Следующие вопросы касаются текущей бизнес-среды организации в сравнении с «желаемым будущим состоянием». Именно здесь выявляются и исследуются влияние продукта и взаимозависимости в бизнесе.

10. Перечислите конкретные воздействия, которые эта программа, как ожидается, окажет на:

• Процессы (рабочие процессы и процессы поддержки - учитывайте изменения и взаимозависимости)

• Политики (продвижение по службе, найм, развитие, обучение и т. Д.))

• Другие проекты / программы (взаимозависимости, дублирование, временные вопросы, ресурсы)

• Клиенты (интерфейсы, ценности клиентов и влияние на поведение)

• Поставщики (интерфейсы, зависимости, изменения, уровни обязательств)

• Бизнес-подразделения внутри Организации (интерфейсы, зависимости, изменения, уровни обязательств)

• Другое

11. При каких ограничениях вы будете работать? (Финансовый, график, технологический, ресурсный)

Элемент № 4: Есть ли у вас технологическая среда для поддержки программы?

12.Каково видение технологической платформы?

13. Каковы текущие стандарты оборудования вашей рабочей станции?

14. Каковы текущие стандарты программного обеспечения рабочих станций?

15. Какое обновление программного обеспечения вашей рабочей станции будет следующим и когда вы планируете это сделать?

16. Как бы вы описали свою технологическую среду? Централизованный, децентрализованный, оба или ни один (объясните).

17. Какие базы данных вы в настоящее время используете для хранения данных организации?

18.Какие сетевые платформы и операционные системы вы используете?

19. Опишите процесс и ресурсы технической поддержки.

Элемент 5: как узнать, что программа была успешной?

Эти вопросы должны помочь определить степень и соответствующие метрики для измерения результатов / воздействия этого продукта на организацию.

20. На каком уровне организация намеревается измерять рентабельность инвестиций?

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

Требования к продукту

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

Можно использовать шаблон для PRD, который будет описывать такие элементы, как:

• Аудитория пользователей программного продукта, который будет разработан

• Услуги, которые должен предоставлять продукт

• Операционные и производственные цели для программного обеспечения product

Заявления, сделанные в PRD, должны быть сопоставлены с заявлениями в Экономическом обосновании.Ниже приведен образец схемы для использования при разработке шаблона PRD.

Образец шаблона определения требований к продукту (PRD)

Титульная страница

Содержание

1.0 Введение

1.1 Цель документа

1.2 Область применения

1.3 Определения, сокращения и сокращения

1.4 Обзор возможностей

2.0 Общее описание продукта

2.1 Описание продукта

2.2 Функции и характеристики продукта

2.3 Характеристики пользователя

2.4 Общие ограничения

2.5 Допущения и зависимости

3.0 Требования к внешнему интерфейсу

4.0 Требования к рабочим характеристикам

Приложения (по мере необходимости)

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

Модель пользовательского интерфейса и навигации JAD

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

Сеанс совместной разработки приложений (JAD) очень продуктивен для этого шага общего процесса определения требований к продукту. В JAD представители конечных пользователей, владельцев систем, разработчиков и других заинтересованных сторон работают на интенсивных встречах, чтобы определить детали системы.Этот шаг процесса, как и предыдущие, должен быть сосредоточен на бизнес-проблеме, которую решает система, а не на технических деталях. Серии пользовательских сценариев часто чрезвычайно полезны для руководства командой JAD на этом этапе процесса. Ожидаемые результаты этого процесса JAD - детальный дизайн пользовательского интерфейса, основанный на стандартных возможностях системы, схема базы данных для нестандартных таблиц и полей, а также список системных функций и связанных с ними бизнес-потребностей.Это также должно привести к модели интерактивной экранной навигации и стандартам графического дизайна. Сессия JAD предоставляет еще одну возможность использования стандартных инструментов в виде шаблонов руководств для проведения сеанса JAD.

Документ о функциональных требованиях

На основе предыдущих шагов процесса, на этом шаге будет разработано и задокументировано более подробное описание системы, подходящей для разработки программного обеспечения. Документ функциональных требований (FRD) вместе с Документом требований к продукту (PRD) более высокого уровня служит спецификацией контракта для последующей фазы разработки проекта.В отличие от предыдущих документов требований, FRD должен быть написан для разработчиков программного обеспечения, а не для пользователей, менеджеров и руководителей. Для каждой из функций, определенных в сеансе JAD пользовательского интерфейса / модели навигации, должны быть разработаны подробные спецификации производительности системы. Шаблон структуры FRD может использоваться для обеспечения стандартизации.

Завершение решений и получение одобрения от спонсора

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

Важные вопросы управления процессом определения требований к продукту

Планирование управления изменениями

Новые технологии и их преобразованные бизнес-процессы могут быть оспорены некоторыми в организации.При управлении PRD критически важно интегрировать методы управления изменениями, ориентированные на ландшафт организации. Это достигается путем определения карты влияния на бизнес, включая конкретные задачи управления изменениями и приоритеты воздействия, которые могут ускорить или затруднить внедрение нового продукта и дополнительных методов ведения бизнеса. При использовании блок-схем процессов во время сеансов JAD пользовательского интерфейса и навигационной модели (раздел 1.3) области воздействия, вероятно, уже были определены.Расширяя эти карты, можно будет выявить дополнительные точки воздействия, которым можно будет определить приоритетность для разработки плана действий по управлению изменениями. Некоторые виды деятельности, которые следует учитывать: проведение сессий по ознакомлению с новыми технологиями, разработка плана внутренней и внешней коммуникации, определение пробелов в компетенциях, связанных с внедрением нового продукта и процессов, оценка решений для поддержки после запуска и сбора знаний конечных пользователей и перевод.

Стратегии управления рисками

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

Управление знаниями

Чтобы помочь свести на нет один из рисков процесса PRD - доступность и удержание ресурсов с необходимыми компетенциями, - благоразумно признать необходимость в плане передачи знаний и команде фасилитаторов. Этот план и группа поддержки помогут: найти соответствующие ресурсы знаний, внутренние и внешние по отношению к организации, обобщить знания и управлять ими, применить знания организации к бизнес-задачам, выявленным в результате инициативы по продукту, определить потенциальные средства сбора знаний, облегчить «извлеченные уроки» »И помогают интегрировать подход к управлению знаниями в текущие и будущие мероприятия PRD с помощью шаблонов и повторяемых процессов.

Заключение

Определение требований к продукту (PRD) Управление определяет компоненты продукта и их необходимую успешную интеграцию. Эти усилия являются наиболее важной фазой продукта, поскольку они закладывают основу для всех последующих фаз жизненного цикла продукта. Используя основы управления проектами, этот подход обеспечивает четкие цели, согласованные ожидания, учет организационного воздействия, определение стратегии управления рисками и облегчение передачи знаний между ресурсами для продвижения и продления жизненного цикла продукта.

Этот материал воспроизведен с разрешения правообладателя. Несанкционированное копирование этого материала строго запрещено. Чтобы получить разрешение на воспроизведение этого материала, свяжитесь с PMI или любым указанным автором.

Протоколы ежегодных семинаров и симпозиумов Института управления проектами
7–16 сентября 2000 г. • Хьюстон, Техас, США

.Документ с требованиями к продукту

- Как написать хороший PRD?

Допустим, вы придумали отличную идею, вы хотите создать программный продукт, но не знаете, что делать дальше. Как превратить свою идею в конкретный документ? Вы не можете просто иметь представление, вам нужно дать более четкое определение. Это цель, функции, требования и т. Д.

Это не только поможет воплотить вашу идею в жизнь, но и поможет другим людям лучше понять ваш продукт, особенно тем, кто должен вложить в него усилия и создать его.Этот документ представляет собой не что иное, как то, что широко известно как PRD, то есть документ с требованиями к продукту.

Документ требований к продукту (PRD) - это исходный документ, описывающий основные функции продукта до разработки. PRD также определяет порядок и любые условия задач проекта.

Он должен быть отправной точкой вашего продукта, описывая его цель, объем работы, кто ваши целевые клиенты, будут ли они взаимодействовать с вашим продуктом и как измерить производительность вашего продукта.Это важный предшественник дизайна и разработки.

Кто пишет документ с требованиями к продукту?

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

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

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

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

Четыре «W» для создания вашего PRD:

Что вы хотите построить?

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

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

Почему вы хотите его построить?

Высокоуровневая цель того, почему вы создаете определенный продукт, должна всегда сопровождать аспект того, что вы создаете. Далее это объясняется подробными целями и задачами, которые мы скоро обсудим в статье.

Для кого это? - Кто ваша целевая аудитория?

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

и так далее…

Когда это нужно?

Технически построение PRD должно быть первым шагом к разработке продукта.

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

Время, затрачиваемое на составление PRD, помогает каждому лучше понять срочность и свои роли. Никогда не следует уклоняться от предварительной даты запуска вашего продукта, и PRD - это единственное место, где он должен быть первым.

Компоненты документа с требованиями к продукции (PRD):

Цели / задачи

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

Важно убедиться, что вы не составляете исчерпывающий список целей и возможностей. Мечтать о большом - это здорово, но необходимо свести его к минимально жизнеспособному продукту (MVP).MVP - это продукт с наименьшим набором функций, который по-прежнему удовлетворяет потребности пользователей и создает правильный пользовательский интерфейс.

Вы должны решить дилемму «обязательное» и «хорошее». Придерживайтесь того, что необходимо.

  • При написании этого раздела задайте себе следующие вопросы:
  • Для чего предназначен этот продукт?
  • Какие проблемы решит?
  • Как это улучшит текущий процесс или облегчит новый процесс?
  • Каково видение продуктов?

Рассмотрим пример приложения поставщика услуг такси

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

Персоны пользователей / Целевые пользователи

Этот раздел поможет вам создать гипотетических личностей, соответствующих вашей желаемой аудитории.Это поможет вам определить, кто ваш пользователь. Создание персонажей или определение целевой аудитории помогает вам понять, что они могут делать с вашим продуктом, когда они могут его использовать и как они могут получить к нему доступ.

Создаваемые вами образы пользователей не обязательно должны быть очень подробными, они должны быть достаточно подробными, чтобы вы могли понять, как они видят продукт. Используйте Google Analytics для создания этих персонажей. Google Analytics предоставляет важную информацию, такую ​​как демографические данные ваших пользователей, откуда они пришли, ключевые слова, которые они использовали, и поведение, которое они демонстрируют в Интернете.

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

.

Данные пользователя
Имя: Рахул Менон (случайный)

Возраст: 22-35 лет

Род занятий: частная служба

Живет в метро из-за возможности трудоустройства

Ожидаемая заработная плата> 8 лаков в год


Деловая информация
Проблемы, связанные с поездками на работу -
1.Он молод в своей профессиональной жизни и пока не может позволить себе личный автомобиль или

  1. Есть личный автомобиль, но добираться на работу долго, а вождение в пробке - проблема или
  2. Коммутационные работы в офис отсортированы, но мы хотим воспользоваться услугами для менее частых поездок по городу или аэропорта / железнодорожного вокзала.

Интересы

- Активен в Facebook и Twitter около 10 часов в неделю в сумме

- Имеет активный интерес к текущим городским мероприятиям, таким как фильмы, концерты и т. Д.

- Читает одно из четырех основных английских изданий (ET, TOI, The Hindu, Hindustan Times).

- Посещает публикации новостей в Интернете напрямую или через ссылки в социальных сетях (Yourstory, Inc42, Livemint и т. Д.)

- Тема интересов: технологии, стартапы, гаджеты нового поколения, крикет

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

Истории пользователей

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

Как [тип пользователя], мне нужна [конкретная цель], чтобы [причины].

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

Следуйте этим шагам, чтобы продвигать свой продукт, не утонув в слишком большом количестве историй и идей.

  • Используйте только высокоуровневые и абсолютно необходимые истории, также известные как эпосы, которые позже можно разбить на более мелкие сегменты.
  • Рассказывайте кратко и по существу.
  • Они должны объяснить, что нужно вашим клиентам и почему
  • Имейте в виду, что они должны быть ориентированы на пользователя.

Технические проекты и спецификации, необходимые в документе с требованиями к продукту

В этом разделе описывается технический процесс, лежащий в основе продукта, и возможности вашего продукта. Чем больше вы понимаете, как ваш продукт должен работать и какие функции вы хотите, чтобы он предоставлял, тем проще разработчику будет его создать для вас.

Каркас

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

Есть много инструментов, которые помогут вам создавать каркасы, взгляните на этот пример.

Это классический случай, когда ручка и бумага являются вашим «инструментом» для создания макетов, который, честно говоря, отлично работает, если вы хотите динамичных действий.Существуют различные инструменты для создания каркасов, создания более зрелых макетов или даже макетов с высокой точностью. Часто это зависит от процессов, которые вы установили внутри компании, и от того, как обязанности по дизайну продукта разделены между командой разработчиков, дизайнеров и разработчиков. Так что решите, что лучше для вас как организации.

Зависимости

Важно помнить о влиянии вашего нового продукта и следить за тем, чтобы он выпускался без нарушения работы существующих продуктов.Убедитесь, что вы выяснили, повлияет ли новый продукт на что-либо еще живое на платформе, или он нарушит работу каких-либо существующих фреймворков.

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

Управление зависимостями - важный аспект разработки продукта. Это эффективно помогает организации работать более продуктивно, принимать обоснованные решения, улучшать предсказуемость и качество выпусков ваших продуктов.

Метрики

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

В вашем документе с требованиями к продукту (PRD) должно быть указано, какие показатели вы будете отслеживать, как вы планируете их отслеживать, а также критерии успеха вашего продукта.Это то, чему ваш продукт должен соответствовать, чтобы считаться успешным.

Слишком часто мы видим, что этому шагу не придается столько значения, сколько должно быть. Постарайтесь как можно больше назначить количественные показатели своим целям. Наличие слишком большого количества количественных целей также может ослабить фокус, поэтому возьмите небольшое количество наиболее важных целей, скажем 2–4, и придерживайтесь их.

Критерии выпуска

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

Что входит в критерии выпуска?

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

Уровень покрытия тестированием - завершите альфа- и бета-тестирование, чтобы убедиться в отсутствии ошибок. Также определите, сколько тестов QA прошло успешно, а не сколько проблем.

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

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

Retrospect после выпуска

Извините, что сообщаю вам, но ваш процесс создания Документа с требованиями к продукту (PRD) является исходным документом, описывающим основные функции продукта до разработки. Узнайте, как писать отличные PRD, и получите отличные примеры документов с требованиями к продукту и функциональных спецификаций. PRD и продукт не заканчиваются на выпуске.

Пост-релиз - важное время. Вы должны сравнить свои метрические ожидания с реальностью и извлечь уроки из собранных вами данных.Что ты можешь сделать лучше? Что сработало, а что не сработало. Куда вы идете отсюда, что дальше?

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

Итак, вот оно, следуйте этим шагам, и мы гарантируем вам эффективный PRD, который сэкономит вам время и деньги. А также получить результаты, которые вы ожидаете и хотите.

.

Смотрите также