A business requirements document (or BRD), is a document that clearly states everything that a project entails. A BRD can be the key to a successful project and can help you avoid wasting valuable resources.
Are you ready to learn everything you need to know about how to write a business requirements document? This article will explain in detail what information you’ll need to put in your BRD, as well as step-by-step instructions for creating your own. We know it’s helpful to see an example when you’re starting a document from scratch, so we’ve given you a full example, too.
Plus, you can use our pre-built requirements management template to help you write your own BRD. Once this is done, you’ll be able to start your project even faster using our pre-built project scheduling template.
What is a business requirements document (BRD)?
So, what is a business requirements document? It clearly defines everything that a project entails. It considers all facets of the project, including the expected outcomes and the key stakeholders.
PRD, BRD,SRS и другие важные аббревиатуры | IAMPM
This document outlines what’s needed to reach the intended project objectives. When it’s done well, it should be so self-explanatory that it removes any ambiguity associated with the project work. Nobody is left guessing — everything they need is listed in the business requirements document.
In a paper for the Project Management Institute (PMI), Paul Burek emphasized that business requirements are the “what” — what an organization wants to do upon completing a project. The requirements define the changes that will come as a result of the project work.
While it might sound overly formal, a business requirements document is a critical element to ensure alignment among all parties involved.
What information do you put in a business requirements document?
Now that we have a loose overview of what this document is, let’s dig into the nitty-gritty of what goes into it.
Business requirements documents are similar to other formal documents such as requests for proposals (RFPs) and client contracts. With that in mind, they often include:
- An executive summary: Write this summary after completing the rest of the document. This high-level section should outline the project requirements and should summarize the following contents of the document.
- Project objectives: Describe the project’s goals and objectives and mention what the work will achieve. What are the outcomes? How does the project align with the goals of the business? To simplify this product management roadmap and ensure it’s succinct, use the SMART system for project objectives.
- A needs statement: This is where you make your case as to why the project is needed. Providing rationale and garnering support from stakeholders and employees is a great way to build rapport with your peers before diving into the rest of the project.
- Project scope: Why is scope management important? Successful projects communicate the work scope from the beginning and stay within the defined boundaries unless otherwise instructed. Clear project scope will help you avoid dreaded scope creep. Find a scoping document template that works for you to clearly lay out your project scope.
- Requirements: After requirements gathering with key stakeholders, you’ll need to summarize all of the project’s requirements in this section. Be mindful of high-level requirements like the “what,” as well as technical requirements like the “how.”
- Key stakeholders: Identify the stakeholders involved in the project and lay out their roles and responsibilities. Who will do the work? What are the expectations of each stakeholder? Will the business need to hire any additional resources?
- Schedule, timeline, and milestone deadlines: Detail the project phases in this section, carefully outlining what is required and when. Create timelines and account for dependencies, as well as unforeseen challenges that could arise.
- Cost-benefit analysis: Your cost-benefit analysis is where you’ll capture the associated costs involved in the project along with the expected benefits to help you build a case for the return on investment (ROI) of the project.
How to write a business requirements document
There’s no denying that there’s a lot that goes into this document. But, writing business requirements and adding them to a business requirements document doesn’t have to be an overwhelming challenge. Follow these tips for writing your own.
Как писать требования так, чтобы команда хотела их читать / Александр Войтехович / ISsoft
1. Start by learning from previous successful projects
If starting this document feels daunting, spend some time reviewing successful past projects completed within the organization.
Look at the documentation associated with these projects and use your insights to outline your new business requirements document. Some elements to consider as you review previous documentation include:
- What worked well
- What didn’t work
- Hurdles the project team had to overcome
- Dependencies that might affect your current project
- Elicitation methods used during the requirements-gathering phase
2. Capture your requirements
Here are the meat and potatoes of this process: gathering requirements. This may consist of many different types of requirements ranging from high-level to technical.
Ultimately, your business requirements document won’t be effective without gathering and capturing all stakeholders’ requirements accordingly.
«A Guide to the Business Analysis Body of Knowledge» (BABOK® Guide) identifies commonly used requirements elicitation methods, including:
- Brainstorming: Bring your stakeholders together and elicit ideas and themes for the project. This particular method may be beneficial if there are multiple solutions identified.
- Document analysis: Review all existing documentation pertinent to the project, including previous documentation for successful projects.
- Focus groups: Identify stakeholders to gather input from them on a smaller scale. You can dig into the proposed solutions further with pre-determined stakeholders than you would in a brainstorming session.
- Interface analysis: This elicitation method is particularly beneficial for software solutions and involves user interactions with an application.
- Interviews: One-on-one interviews are a popular way to gather input for requirements. Hone in on the stakeholder’s thoughts and perspectives related to the project and potential solutions.
- Observation: This method of elicitation is beneficial when revamping a process or workflow. When observing a worker’s process or workflow, be mindful not to interrupt them. Instead, ask them to review your documentation post-observation.
- Prototyping: Using a prototype is a great way to ensure that the current requirements meet all stakeholders’ needs. Prototypes can illustrate how a solution might work and help determine if requirements should be altered.
- Requirements workshops: Conduct collaborative workshops with your stakeholders to outline requirements together. Workshops generally have more direction than brainstorming sessions with pre-determined asks of each stakeholder specified at the beginning.
- Surveys/questionnaires: Surveys and questionnaires can help if you’re looking to obtain feedback from a larger group of stakeholders. Question design is important, so be sure to determine how best to pose questions to gather the information you need.
Don’t worry — it’s certainly not essential to use all of the techniques mentioned above. Instead, identify which ones will work best for you and your current product specifics. Throughout the project lifecycle, ensure you listen for impacts to the requirements defined at the beginning of the project and address them as needed.
Try our pre-built requirements management template to help you organize all the inputs.
3. Use clear, jargon-free language
Business documents like these can often be long-winded and heavily detailed, making them difficult for your team members to follow and understand. Remember that this document will be viewed by lots of different stakeholders in various roles, and not everyone will understand technical text. There’s no need to include heavy jargon in your business requirement document — try and keep your language clear, relatable, and concise.
A good tip is to include a glossary of terms at the end of your document so that any technical terms can easily be found, and misunderstandings can be avoided.
4. Add visual elements to make content more digestible
Visuals and surrounding context can increase your plan’s effectiveness and break up text-heavy chunks of information.
Research indicates that 65% of the population are visual learners, which means incorporating visuals in your document can help you convey your message and plan in a more compelling way.
For example, a business process diagram is a typical visual seen in a business requirements document. Mapping out business processes in their current state versus the proposed future state can help communicate requirements with ease.
5. Ask team members to review your document
Once you’ve finished your business requirements document, ask stakeholders to review it and validate it. This provides the opportunity for you to confirm you’ve captured all of the requirements accordingly and offers a chance for stakeholders to provide feedback and make changes before the project begins.
As an added bonus, completing a review process also contributes to overall alignment, setting your team up for success from the get-go.
Business requirements document example and template
We’ll admit that all of this can feel a little complex and academic, so let’s walk through a basic requirements document example.
Imagine that your organization wants to find a way to better track employee performance and key performance indicators (KPIs).
For the sake of this example, let’s say there’s currently no system that allows employees to track their performance, so one will have to be selected and implemented. Here’s what a very simple document might look like for this type of project (along with some helpful tips):
1. Executive summary
Our organization is seeking a performance management system to track our overall employee performance, boost retention and morale, and increase transparency between managers and employees.
We aim to have this system launched within the second quarter and will evaluate systems, implement the system, and provide adequate training to managers and employees by June 1, 2023.
There are a number of requirements we’re looking to satisfy, including career path mapping, reporting and analytics, and goal management. A number of stakeholders will be involved in the selection and implementation of this system, including a project manager, human resources, department heads, executives, managers, and employees.
This document details the selection of this system, the objectives, needs, scope, requirements, stakeholders, schedule, and cost-benefit analysis.
2. Project objectives
Use the SMART system for your project objectives:
- We will have all 500 employees trained using our new performance management system by June 1, 2023.
3. Needs statement
Back your statement with data and research, if possible, to strengthen your position:
- A performance management system is needed to increase our employee retention rates, maintain consistency across employee development paths, boost our financial position by up-leveling our talent, and motivate and reward employees. Turnover costs our organization on average $35,000, and implementing this system will allow us to save money by retaining our employees.
4. Project scope
Clearly define what work falls within the scope:
- In scope:
- Evaluating and selecting a performance management system
Implementing the performance management system - Providing system training to managers
- Providing system training to employees
5. Requirements
Work with key stakeholders to outline all of the requirements:
- Goal management for tracking progress
- Performance evaluation for mid-year and end-of-year performance reviews
- Career path mapping and succession planning
- Reporting
- Performance analytics
- Coaching and mentoring opportunities
6. Key stakeholders
Identify key stakeholders and outline their roles and responsibilities:
- Project manager: responsible for holding all parties accountable to the project timeline
- Human Resources: will research performance management systems, gather requirements, provide a recommendation to the Executives for signoff, conduct manager and employee training sessions
- Department heads: share desired needs with HR for a comprehensive list of requirements
- Executives: responsible for signing off on the selected performance management system
- Managers: will be trained on the system
- Employees: will be trained on the system
7. Schedule
Outline all various phases of the project along with the deadline for each phase:
- Phase I: Complete requirements gathering with all stakeholders by March 31, 2023
- Phase II: Select a performance management system to recommend to Executives by April 7, 2023
- Phase III: Onboard HR team to the new performance management system by April 26, 2023
- Phase IV: Complete training materials for managers and employees by May 3, 2023
- Phase V: Conduct manager training on May 10, 2023
- Phase VI: Conduct employee training on May 17, 2023
Use a tool like Wrike, to help you visualize your project timeline through a Gantt chart view and keep your stakeholders up to date on your progress.
8. Cost-benefit analysis
Complete a cost-benefit analysis:
- Costs of employee turnover per team YoY
- Costs of resources needed by the project team to implement the system
- Benefits of having employees aligned to company objectives
- Benefits of legal protection for terminations
How to plan a business requirements document with Wrike
A collaborative work management platform like Wrike can take plenty of stress and headaches out of the process by streamlining communication, collecting requirements from stakeholders, and providing visibility into the process. Our pre-built templates, like our requirements management template and our project scheduling template, can help bring those results to fruition even more quickly.
Are you ready to manage projects more efficiently, increase productivity, and decrease risks? Click here to start your Wrike free trial and avail of our pre-built templates and valuable product management resources that will supercharge your business.
Источник: www.wrike.com
Что такое brd в бизнесе
Статья Майкла Шриватсана, в которой он проливает свет на запутанную систему документов с описаниями требований к продукту. BRD, MRD, PRD, FSD, PSD, SRS, IRS. хотя последнее как-то связано с налогами, нет?
Заранее прошу прощение за возможные ошибки в переводе названий документов. Это просто невозможно! Я не знаю точных аналогов в наших документах, поэтому вынужден придумывать. По уму следовало бы заглянуть в ГОСТы и ЕСПД, чтобы выудить оттуда хотя бы правильные названия программных документов – но лень 🙂
Алфавитная каша
Если вы похожи на меня, то вы выросли в окружении всевозможной алфавитной еды – алфавитные хлопья, алфавитные печенья, алфавитный суп, и много всякой другой еды в форме букв алфавита. Я полагаю, большинству из нас она на самом деле нравилась – или наоборот по настоящему не нравилась. Не знаю, к какой именно группе относитесь вы – но в любом случае вы ее ели.
Сейчас мы все выросли и редко едим эту алфавитную ерунду, но практически во всех профессиях профессиональный жаргон это алфавитная каша, наводненная ТБА (трехбуквенная аббревиатура). ХЭП (хорошо это или плохо)?
Управление продуктом и аналитика продукта не исключение – особенно, когда дело касается описания требований. У нас есть BRD, MRD и PRD; у нас также есть FSD, PSD и SRS и еще много вариаций на ту же тему.
И, как будто этого мало, так еще все организации используют эти аббревиатуры по-разному. То, что в одной организации называется MRD, в другой называют PRD. Иногда я не могу сдержать смех, когда вижу очередную ТБА. Как говорится, дайте нам шанс, а уж мы то постараемся!
Вот вам смешной вопрос: сколько различных ТБА вы сможете составить, используя только заглавные буквы английского алфавита?
P.S.Если вы добрались до сюда и до сих пор не знаете, что такое ТБА – стыдитесь! Пожалуйста, перечитайте все с начала, ладно?
Аббревиатуры описаний требований
Давайте пройдемся по наиболее распространенным аббревиатурам, используемым для обозначения документов с описаниями требований:
BRD – Business Requirements Document (Бизнес требования)
BRD фокусируются на определении бизнес задач проекта. BRD определяет одну или несколько бизнес задач стоящих перед пользователями, которые могут быть решены с помощью продукта компании. После этого предлагается решение – обычно это новый продукт или усовершенствование существующего продукта в нужной части.
Он также может включать какой-то предварительный бизнес анализ – прогноз прибылей, анализ рынка и конкурентов, а также стратегию продаж и продвижения.
Чаще всего он пишется Менеджером по продукту, Менеджером по маркетингу продукта или Бизнес аналитиком. В маленьких компаниях это может быть даже директор или владелец фирмы.
Предположим, ваша компания разрабатывает систему управления взаимоотношений с клиентами (customer relationship management CRM).
BRD может фокусироваться на проблемах стоящих перед менеджерами по продаже – отслеживание всех сделок и возможность формирования достоверных прогнозов. Он может определять:
- Перед кем стоят подобные проблемы:
- Менеджеры по продаже компаний входящих в список Fortune-500
- Отсутствие отслеживания статуса заказов в реальном времени
- Невозможность формирования достоверных прогнозов
- Создание web-ориентированного ПО для отслеживания (проведения) сделок и формирования прогнозов
MRD – Market Requirements Document (Требования рынка)
MRD фокусируется на определении требований рынка к предлагаемому новому продукту.
Если BRD определяет круг проблем и предлагает вариант их решения – то MRD более подробно описывает детали предлагаемого решения. Он может включать несколько или все нижеприведенные аспекты:
- Функциональные возможности, необходимые для решения бизнес задач
- Анализ рынка и конкурентов
- Функциональные и не функциональные требования
- Приоритезацию требований и функциональных возможностей
- Варианты использования
Чаще всего он пишется Менеджером по продукту, Менеджером по маркетингу продукта или Бизнес аналитиком совместно с Системным аналитиком.
Давайте продолжим предыдущий пример компании, разрабатывающей систему управления взаимоотношением с клиентами (customer relationship management – CRM).
MRD может фокусироваться на определении и приоритезации требований, а также на описании вариантов использования. Требования включают функциональные и не функциональные, такие как:
- Функциональные требования:
- Должно работать под Internet Explorer (версии 6.0 и выше) и Firefox (версии 1.5 и выше)
- Должно использовать SSL для обеспечения безопасности
- …
- Пользователь должен иметь возможность вводить данные через web-формы для: пользователей, компаний, контактов, и т.д.
- Должно поддерживаться до 100.000 одновременных пользователей
- …
- Необходимо полное руководство пользователя на Английском, Немецком и Японском
Некоторые организации объединяют MRD и PRD в один документ и называют этот документ MRD. В этом случае MRD будет включать то, что описано в этой части и то, что описано в следующей – и может содержать более 50 страниц.
PRD – Product Requirements Document (Требования к продукту)
PRD фокусируется на определении требований к предлагаемому новому продукту.
Если MRD фокусируется на требованиях с точки зрения нужд рынка, PRD фокусируется на требованиях с точки зрения самого продукта. Обычно он более детально описывает возможности и функциональные требования и может даже содержать скриншоты и лэйауты пользовательских интерфейсов.
В организациях, где MRD не включает детализацию требований и варианты использования, PRD закрывает эту брешь.
Обычно он пишется Менеджером по продукту, Бизнес аналитиком или Продуктовым аналитиком.
Давайте продолжим предыдущий пример компании, разрабатывающей систему управления взаимоотношением с клиентами (customer relationship management – CRM).
PRD может фокусироваться на детализации требований, таких как:
- Форма авторизации должна включать поля для имени пользователя и пароля.
- Она также должна включать ссылку «Забыли пароль?»
- Страница «Контакты» должна включать поля для имени, фамилии, телефона, email и т.д.
- …
- Алгоритм формирования прогноза должен содержать 5-шаговый мастер, который проведет пользователя через шаги, необходимые для создания ежегодного отчета. Все шаги описаны далее…
PRD может также включать подробные варианты использования.
Некоторые организации объединяют MRD и PRD в один документ и называют этот документ MRD. В этом случае MRD будет включать то, что описано в этой части и то, что описано в предыдущей.
FSD – Functional Specifications Document (Функциональная спецификация)
FSD детально определяет функциональные требования к продукту с фокусировкой на реализации. FSD может определять продукт последовательно форму за формой и одну функциональную возможность за другой. Это документ, который уже может непосредственно использоваться командой разработчиков для создания продукта.
Если MRD и PRD фокусируются на требованиях с точки зрения потребностей рынка и продукта, FSD фокусируется на определении деталей продукта, в форме, которая может быть использована разработчиками. FSD может также включать законченные скриншоты и детальное описание пользовательских интерфейсов (UI).
Обычно он пишется Системным аналитиком, Архитектором решения или Главным разработчиком – т.е. автор обычно сам относится к разработчикам.
PSD – Product Specifications Document (Спецификация продукта)
PSD – это наименее популярная аббревиатура, но в тех организациях, которые используют эти документы, они обычно соответствуют по содержанию и объему Функциональной спецификации (Functional Specifications Document FSD) описанный выше.
SRS – Software Requirements Specification (Спецификация требований)
SRS – это еще одна не очень популярная аббревиатура. В организациях, которые используют SRS, они обычно очень похожи на то, что описывается в PRD и FSD.
Итак, вот они – 6 типов документов, описывающих требования, расшифрованные и разжеванные. Только хочу вас предостеречь – все организации по-разному используют эти документы. Каждая организация определяет, какие документы создавать и что именно в них описывать, в зависимости от своих нужд.
Ответ на смешной вопрос : количество ТБА (трех буквенных аббревиатур), которые вы сможете составить, используя только заглавные буквы английского алфавита равно: 26 3 = 17576.
Вы понимаете, что это означает, да? Будьте морально готовы выучить еще 17500 ТБА касающихся описаний требований.
НВВ (ну вот и все) – наше путешествие в замечательный мир аббревиатур документов описывающих требования завершен.
Опубликовано в дневнике Michael on Product Management https://sites.google.com/site/sloutskov/brd-mrd-prd-fsd-%D0%B8-%D0%BF%D1%80%D0%BE%D1%87%D0%B8%D0%B5-%D1%82%D0%B1%D0%B0″ target=»_blank»]sites.google.com[/mask_link]
BRD. Как написать идеальный документ
Исчерпывающая документация бизнес-требований четко определяет проект. Если документ составлен правильно, он сделает за проектную команду много тяжелой работы: будет управлять ожиданиями, устанавливать стандарты, отмечать достижения и обеспечивать успех.
Ниже приведены основные элементы, которые необходимо включить в документ бизнес-требований, а также лучшие практики, ограничения и соображения по объему.
Ключевые элементы документа бизнес-требований
Перед нами 10 элементов, которые необходимо включить в документ бизнес-требований и которые помогут обеспечить успех вашей команды.
Версионирование
Набор бизнес-требований — это живой организм. Он создается до начала проекта и может часто меняться и редактироваться, когда все остальное уже готово.
Поскольку на документ будут ссылаться снова и снова, важно, чтобы все изменения были отмечены в пределах разумного. Если изменились требования или даты, запишите это; если вы исправили опечатку, оставьте это без внимания.
Краткое изложение
Несмотря на то, что резюме обычно появляется первым в документе бизнес-требований, его рекомендуется писать последним. Это формулировка высокого уровня, которая должна описывать требования проекта и подводить итог остальной части документа.
Цели проекта
Изложите цели и задачи проекта, подробно описывая, что будет достигнуто в результате работы. Если проект поддерживает бизнес-процессы или потоки, это должно быть описано здесь.
Цели всегда должны соответствовать SMART: быть конкретными, измеримыми, достижимыми, реалистичными и ограниченными по времени.
Формулировка потребностей
Описание потребностей должно быть убедительным. Это — основной смысл проекта. Воспринимайте формулировку потребностей как обоснование, которое должно убедить заинтересованных лиц в правильности идеи и придать мотивацию команде проекта.
Объем проекта
Подробное описание объема проекта поможет установить границы выполняемой работы. В зависимости от вашего проекта, целей, команды и обстановки, иногда бывает проще определить элементы или модули, которые не будут обновляться или включаться в рамки проекта, вместо того, чтобы определять абсолютно все требования.
Стейкхолдеры
Необходимо определить все заинтересованные стороны, включая их должности. Полезно перечислить их должности в соответствующих организациях, а также их роли и обязанности, относящиеся к текущему проекту.
Финансовый отчет и анализ экономической эффективности
Финансовую информацию, включенную в документ бизнес-требований, не следует рассматривать как бюджет, она призвана показать влияние проекта на баланс компании.
Здесь должны быть указаны источники финансирования, но не забывайте, что любое лицо или организация, вносящие свой вклад, также могут считаться заинтересованными сторонами и должны быть включены в оба раздела.
График, сроки и основные этапы
В зависимости от масштаба проекта информация о графике, сроках и основных этапах может быть объединена в один раздел или выделена в отдельный. Важно четко определить ожидания и сроки, обязательно указав точки принятия решений, а также моменты, когда работа должна быть завершена.
Отслеживайте все действия, включая сроки подписания результатов проекта, привлечения внешних поставщиков и установки оборудования.
Для долгосрочных проектов определение четких этапов дает идеальную возможность для промежуточного выставления счетов, чтобы можно было расплатиться с поставщиками и подрядчиками.
Функциональные требования
Функциональные требования составляют основную часть хорошего документа с бизнес-требованиями. Чем подробнее требования, тем лучше результат.
Обязательно используйте четкий, лаконичный язык без жаргона или сленга. Избегайте аббревиатур, даже если они кажутся общепринятыми. По возможности добавляйте визуальные элементы, такие как скриншоты, прототипы и макеты. Отличная идея — сравнить текущее состояние с будущим, когда меняются бизнес-процессы или рабочие процессы.
Там, где это имеет смысл, разбивайте большие разделы на более мелкие и доступные части. А если требования носят опциональный характер или зависят от других зависимостей, разбейте их на обязательные, необходимые и «будет приятным бонусом».
Нефункциональные требования
Задокументируйте в этом разделе любые требования к отчетности, аналитике и интеграции. Помните, что некоторые виды деятельности, например, проверка безопасности, могут потребовать пересмотра других разделов документа с бизнес-требованиями, поэтому необходимо предусмотреть в бюджете соответствующее время.
Лучшие практики работы с документацией по бизнес-требованиям
Существует ряд лучших практик, которые могут гарантировать успех вашей документации и проекта в целом. Вот 8 из них, которые следует учитывать при планировании проекта.
- Получите вклад и перспективы. Представьте документ бизнес-требований на экспертную оценку.
- Установите разумные сроки. Дважды и трижды проверьте даты и сроки, чтобы убедиться, что они достижимы: лучше завысить оценку и выполнить работу раньше, чем срывать сроки.
- Предусмотрите время для исследований. Если необходимо привлечь подрядчиков или поставщиков, убедитесь, что время и затраты на это включены. Если исследование необходимого поставщика или стороннего продукта является частью проекта, определите это как риск, который необходимо снизить в случае, если подходящее решение не будет найдено, займет больше времени, чем ожидалось, или превысит бюджетные ассигнования.
- Помните о нормативных требованиях. Не забудьте учесть все нормативные и законодательные акты, которые могут повлиять на проект.
- Подробно опишите необходимые технологии. Включите подробную информацию об инструментах и технологиях, которые будут использоваться и применяться.
- Запланируйте постоянную поддержку. Если ваш проект потребует постоянного обслуживания и поддержки после внедрения, укажите план поддержки, перечислите мероприятия и лиц, которые будут задействованы.
- Оставьте время для документации. Помните, что документирование должно быть частью любого проекта. Необходимо включить мероприятия, отведя время на подготовку документации и учебных материалов.
- Будьте гибкими. Будьте открыты для определения и изменения функциональных требований, но помните о том, что изменения могут повлиять на другие виды деятельности, временные рамки или сроки.
Ограничения документов бизнес-требований
Несмотря на то, что документы бизнес-требований являются источником истины и надежным советником для проекта, они имеют свои ограничения. Вот некоторые из ограничений, связанных с рамками документа, и как их обойти.
- Не всегда нужно знать, как что-то делается. Функциональные требования должны отвечать на вопросы «что» и «почему», но не «как». Хотя это различие может показаться тонким, знание того, как разработчик выполнит ту или иную задачу, выходит за рамки этих документов.
- Не оставляйте вопросы без ответа. Документы бизнес-требований всегда должны отвечать на вопросы, а не задавать их. Если есть вопросы, которые нужно задать, или неизвестные, которые нужно исследовать, сделайте это во время создания документа, а затем включите в него результаты.
- Включите всю предысторию и детали. Каждый документ бизнес-требований должен быть самостоятельным. Предположите, что все, кто его читает, понятия не имеют о том, что происходило в прошлых проектах. Если есть детали, которые необходимо включить для контекста, включите их, но убедитесь, что они уместны и необходимы.
- Планируйте задержки. Хотя немногие документы по бизнес-требованиям включают раздел по снижению рисков, целесообразно найти способы определения областей, где сроки или деятельность могут быть нарушены и каким образом. Эмпирическим правилом является добавление 20-процентного буфера времени для управления неопределенностью, но корректируйте его по мере необходимости и необходимости.
Документация вдохновляет на командную работу
Если документация составлена и оформлена тщательно и продуманно, она способствует укреплению доверия и прозрачности между проектными группами и другими сотрудниками. Улучшается коммуникация, уменьшается количество ошибок, снижается или устраняется двусмысленность и неопределенность, а результаты могут быть практически гарантированы.
Источник: news.myseldon.com
