Правильно поставленный вопрос без преувеличения — половина выполненной работы. Для того чтобы правильно поставить проблему, нужно, во-первых, понимать, какие цели преследует очередная автоматизация. Если понимание задачи есть, то формулировку критериев решения мы можем обсудить совместно.
Примеры начальных формулировок задач приходят ко мне самые разнообразные:
С продолжением списка первых запросов по обратной связи можно ознакомиться по этой ссылке.
Я рад любой обратной связи, потому что, человек, написавший хоть что-то в форме обратной связи, значительно более ценен, чем посетитель, просто заглянувший на сайт, и ушедший в неизвестном направлении. Не понятно, понравился ему мой сайт или не понравился, может быть нужно что-то доработать… Короче, если Вы оставите сообщение в форме обратной связи – мною это будет воспринято с интересом.
После получения какого-либо запроса начинается процесс уточнения того, что же потенциальному заказчику нужно. Иногда заказчик приходит, на мой взгляд, неправильно подготовленным, с убеждением того, что его задачу нужно решать вполне конкретным образом. И если путь к решению задачи заказчика мне представляется не оптимальным, а то и вовсе нереальным, приходится убеждать его в том, что не надо даже пытаться «надевать штаны через голову».
Сбор требований и формирование BRD | Часть 1
Откровенно говоря, я бы предпочел понять проблему заказчика, а как ее решать, лучше, чтобы заказчик доверил мне – у меня и выбор инструментов больше. Т.е. мне больше нравится формула: от заказчика – проблема, от меня – решение.
В конечном итоге результатом выявления нужд пользователей должен стать документ, описывающий требования заказчика — BRD (Business Requirements Document) с заранее согласованной структурой, включающий в себя как описание бизнес процессов «As Is», «To Be», так и описание пользовательского интерфейса, варианты использования системы, а также тестовые сценарии, на основании которых будет приниматься программное обеспечение. BRD — основа для дальнейшей подготовки качественной документации.
Иногда и программисты, и заказчики предпочитают использовать другое название для описания задач клиента – техническое задание (ТЗ). Я не против. В самом деле, разделение документов на: BRD (Business Requirement Document), FSD (Functional Specification Document), TS (Technical Specification), — имеет смысл в крупных проектах, где есть бизнес-аналитики, системные аналитики и т.д. в нашем же случае есть я (и бизнес-аналитик, и программист — два в одном) и есть заказчик. И наша задача понять друг друга и договориться по деньгам и срокам с помощью некого контракта. И как этот контракт назвать: ТЗ или просто договор подряда – не так уж и важно. Важно расставить все точки над i.
Если же у вас нет времени и денег на «лишние телодвижения». Если ваши нужды вам предельно понятны, и у вас есть готовое ТЗ, а от исполнителя вы ожидаете фиксированную стоимость и сроки выполнения подряда, то убедитесь, как минимум в том, что в вашем ТЗ чётко определены объемы и критерии приемки работ. Если объемы работ заканчиваются фразой «и так далее», то и стоимость работ тоже будет заканчиваться фразой «и так далее».
PRD, BRD,SRS и другие важные аббревиатуры | IAMPM
Если вы готовы сами написать ТЗ, то вот вам шпаргалка в виде буллитов, что в BRD/FSD/ТЗ стоит упомянуть.
Стоит также упомянуть, что на протяжении всего проекта со стороны заказчика должен быть специалист, который грамотно сможет уточнить смысл любого из пунктов BRD или ТЗ.
А можно ли начать работать без ТЗ? Ну, в самом деле, зачастую заказчик не знает в начале пути, что ему нужно. А в процессе приближения к решению его требования могут несколько раз кардинально поменяться. Мой ответ такой: можно. Но платить придется за отработанные часы (Timehttps://www.quickwin.ru/solutions/brd» target=»_blank»]www.quickwin.ru[/mask_link]
Слово из трех букв
Это моя первая статья на vc.ru, и в ней я попытаюсь разобраться в различных трехбуквенных аббревиатурах, которые часто встречаются в статьях по разработке требований к программному обеспечению. За подготовку статьи выражаю благодарность Майклу Шриватсану и Дмитрию Слуцкову.
76 просмотров
Картинка из общедоступных источников
Не секрет, что в любой профессии очень часто любят использовать аббревиатуры. Из наиболее громоздких и пугающих- сокращения в организационно-штатных структурах государственных органов (например, ОКГЗиСФД, ООДУУМиПДН, ОАПКиИТО). Ну с государственными органами все понятно, любая бюрократическая структура любит плодить подразделения со звучными и непонятными широким массам названиями и обязанностями. Мы же поговорим об аббревиатурах документов, которые сопровождают цикл разработки программного обеспечения.
Наиболее распространенными аббревиатурами, применяемыми для обозначения документов с описаниями требований, являются такие, как: BRD, MRD, PRD, FSD, PSD и SRS. Может какие-то из них уважаемый читатель встречал в своей работе, а какие-то видит в первый раз. Попробуем разобраться, что за трехбуквенные звери обитают в этом зоопарке.
BRD – Business Requirements Document (Бизнес требования)
О чем документ?
BRD описывает бизнес-задачи, стоящие перед пользователями разрабатываемой (или дорабатываемой) системы. Также в BRD могут быть описаны такие аспекты классического бизнес-анализа, как прогноз прибылей, анализ рынка и конкурентов, стратегия продвижения и/или продаж.
Кто разрабатывает?
Бизнес-аналитик, менеджер по маркетингу, менеджер продукта. Иногда авторами BRD являются владелец бизнеса или руководитель компании (особенно в маленьких фирмах).
Какие разделы может содержать?
Обычно (как и в случае с диалектическим материализмом, это не догма, а руководство к действию) документ должен отвечать на следующие вопросы:
- С какими проблемами сталкивается бизнес/продукт?
- Перед кем стоят эти проблемы?
- Какое решение предлагается для решения этих проблем?
MRD – Market Requirements Document (Требования рынка)
О чем документ?
MRD содержит требования рынка к предлагаемому продукту и может являться расширенной версией BRD.
Кто разрабатывает?
Обычно — бизнес-аналитик (совместно с системным аналитиком), менеджер по продукту, менеджер по маркетингу продукта.
Какие разделы может содержать?
MRD может раскрывать следующие вопросы (разумеется, как и в предыдущем случае, необходимость наличия тех или иных разделов документа должна быть продиктована в первую очередь целесообразностью и их пользой):
- Функциональные возможности, необходимые для решения бизнес задач
- Анализ рынка и конкурентов
- Функциональные (что должен делать продукт?) и нефункциональные (как продукт должен это делать?) требования
- Расстановка приоритетов требований и функциональных возможностей
- Варианты использования
PRD — Product Requirement Document (Требования к продукту)
О чем документ?
Если MRD описывает требования с точки зрения рынка, PRD фокусируется на требованиях с точки зрения самого продукта. Обычно он более детально описывает возможности и функциональные требования и может даже содержать прототипы пользовательских интерфейсов. В компаниях, где MRD не включает детализацию требований и варианты использования, PRD выполняет эту функцию.
Кто разрабатывает?
Продуктовый аналитик, менеджер продукта, бизнес-аналитик (да, этот господин в ответе за все).
Какие разделы может содержать?
Те же, что и в MRD, но более детализированные в части функциональных и нефункциональных требований и вариантов использования. Часто в компаниях разрабатывают один документ, который содержит как информацию MRD, так и информацию PRD. В таком случае будет разумнее отнести его к предыдущему типу документов.
FSD – Functional Specifications Document (Функциональная спецификация)
О чем документ?
FSD детально определяет функциональные требования к продукту с фокусировкой на реализации. В отличие от M(F) RD в FSD определяются детали продукта в той форме, которую могут использовать разработчики.
Кто разрабатывает?
Системный аналитик, архитектор решения, техлид команды разработки. Разумеется, к разработке всего, что касается UI/UX, может привлекаться соответствующий специалист.
Какие разделы может содержать?
В документе может последовательно, форма за формой, определяться внешний вид продукта (скриншоты и детальное описание UI), а также реализация функциональных возможностей (сценарии использования).
PSD – Product Specifications Document (Спецификация продукта)
По смыслу, содержанию и ответственным за разработку ничем не отличается от предыдущего типа документов.
SRS — Software Requirement Specification (Спецификация требований)
О чем документ?
Кто разрабатывает?
Те же уважаемые люди, что и в случае с FSD (системный аналитик, архитектор, главный разработчик, дизайнер).
Какие разделы может содержать?
- Назначение документа и соглашения
- Границы продукта (scope)
- Операционная среда
- Роли и права доступа
- Пользовательские истории (User Story)
- Варианты использования (Use Cases), детализирующие каждую User Story
- Системные требования, определяющие порядок реализации каждого из вариантов использования
- Модели данных (концептуальная и логическая)
- Детализированное описание UI/UX
- Описание интеграций с внешними системами
- Нефункциональные требования (производительность, безопасность, атрибуты качества).
Отдельно хочется отметить, что требования к безопасности бывают двух видов — как Safety Requirements (требования к производственной безопасности, условиям использования и эргономике), так и Security Requirements (требования к информационной безопасности). Это разные категории нефункциональных требований, и не нужно натягивать одну сову на два глобуса: )
В данном посте я попытался объяснить, как некоторые трехбуквенные аббревиатуры могут помочь при документировании требований к разрабатываемому программному обеспечению. И небольшой забавный факт: только трехбуквенных аббревиатур из букв английского алфавита можно составить 17576. Поэтому не стоит удивляться, что при всеобщей любви к трем буквам можно натолкнуться на документ, который здесь не рассмотрен.
Всем удачного дня и до новых встреч!
Источник: vc.ru
Зачем нужен BRD при разработке проектов?
Основная роль BRD в планировании проекта заключается в том, что он позволяет уточнить требования и ожидания заказчика в отношении проекта. На основе требований и ожиданий формируется план проекта, который включает планирование ресурсов, времени и бюджета. План проекта также определяет конечный результат проекта.
Бизнес требования также позволяют обеспечить понимание и согласованность между командой разработчиков и заказчиком проекта. Он определяет все ключевые аспекты проекта, такие как цели, ограничения, функциональные и нефункциональные требования, а также описывает предполагаемый результат проекта. Это позволяет команде разработчиков точно понимать, что должно быть реализовано и каким образом.
BRD также является важным инструментом для управления изменениями в проекте. Как только BRD утвержден, он служит основой для всех последующих изменений и обновлений в проекте. Каждое изменение должно быть привязано к определенным требованиям, которые были установлены в BRD, и должно быть одобрено заказчиком проекта.
Таким образом, BRD играет важную роль в планировании проектов. Она обеспечивает понимание и согласованность между командой разработчиков и заказчиком проекта. BRD также служит основой для управления изменениями в проекте. Бизнес требования позволяют определить цели проекта, его ограничения и требования, что является необходимым условием для успешной реализации проекта.
Как BRD помогает определить требования к проекту.
BRD помогает сформулировать идентифицируемые, измеримые, достижимые, релевантные и связанные (SMART) требования к проекту. Это помогает избежать недопонимания между заказчиком и командой проекта, а также убедиться, что команда разработчиков понимает, какие функциональные и нефункциональные требования должны быть реализованы.
Кроме того, бизнес требования позволяют управлять изменениями в проекте. При любом изменении требований BRD должен быть обновлен и пересмотрен. Это позволяет сохранять единое понимание требований и убеждаться, что все изменения соответствуют исходным целям проекта.
В целом, BRD является необходимым инструментом для планирования проекта, определения требований и управления изменениями. Он помогает убедиться, что проект разрабатывается в соответствии с ожиданиями заказчика, а также гарантирует, что все участники проекта имеют общее понимание того, что нужно создать.
Как бизнес требования влияют на процесс разработки, тестирования и внедрения.
Бизнес требования играют важную роль на всех этапах проекта, включая разработку, тестирование и внедрение. Вот как ини влияют на каждый из этих этапов:
Разработка. BRD обеспечивает четкое определение целей проекта, требований и качества, а также обзор рисков и проблем. Это помогает команде разработки создавать продукт, который соответствует потребностям клиента и ожиданиям пользователей, а также учитывает возможные проблемы и риски, которые могут возникнуть в процессе разработки.
Тестирование. Бизнес требования являются основой для создания тест-кейсов и проверки соответствия системы требованиям. Тестирование выполняется, чтобы убедиться, что система работает должным образом. Система должна соответствовать требованиям и ожиданиям пользователей. Система не должна иметь ошибок или недостатков, которые могут привести к нежелательным последствиям.
Внедрение. Бизнес требования помогают убедиться, что система развернута и настроена правильно, и соответствует требованиям клиента и пользователей. Это также обеспечивает, что в процессе внедрения не будет непредвиденных проблем или ошибок, которые могут привести к негативным последствиям.
Таким образом, BRD играет важную роль на всех этапах проекта. Она обеспечивает успешное выполнение проекта, соответствие требованиям клиента и пользователей. Также BRD помогает управлять рисками и проблемами.
Источник: itonboard.ru
