What is a formal Requirements Document?
You’re speaking with a member of OpFocus and the topic of a formal Requirements Document came up. I can tell what you’re thinking. You’re bringing on OpFocus to help drive your project forward and you’re ready to start. You’re already on a deadline that’s fast approaching and there’s no time to lose. Now you’re told you need to complete this before starting the project and you have a lot of questions: what is this, why do I need one, and how on Earth is this going to help me get things done that I needed yesterday?
You’re not alone. We work with clients who are also on a deadline and eager to start executing. You’re excited to start your project but you’re told we need to complete a formal requirements gathering process & documentation first. After completing thousands of projects of all sizes and complexities, my team found that taking a step back to complete this document is the best way to set your project up for success.
This article outlines what a formal Requirements Document is, the information it contains, and what’s required from your team to create it. After reading through this guide, you’ll understand why a formal Requirements Document is important and have everything you need to begin completing it.
What’s a formal Requirements Document?
Let’s dive right into what you’re here to learn: what is a formal Requirements Document? Sometimes called functional requirements, a formal Requirements Document is the result of the discovery process and outlines the deliverables and desired state of your project.
This document is the end product of the discovery sessions you do with OpFocus and provides detail on each deliverable in the SOW serving as the guide for the rest of the project. After you complete a series of discovery calls, the document outlines the current issues you’re facing through user stories, recommendations for addressing these issues, and the desired end state. Simply put, a Formal Requirements Document provides a detailed outline for the requirements for your project. User stories collected in formal requirements Documents are included in Design Projects and Operational Excellence Roadmaps.
Why do I need a formal Requirements Document?
When working with OpFocus, we expect to use formal Requirements Documents in most projects. You’ll come across this step in Implementations, Operational Excellence Roadmaps, system enhancements & optimizations, Growth Services, and Support Services. A formal Requirements Document benefits each of these types of projects. As a result, your contract may include this step.
After completing the document, you’re provided a project plan aimed at addressing issues and reaching the desired end state. It includes recommendations based on our list of best practices. The document then goes to your team for approval. After reviewing the document with relevant stakeholders, you provide your own insight into what the project should look like. The end document then serves as a more in-depth version of the SOW to guide the deliverables of the project. Aligning both teams prevents confusion down the road.
What information does a formal Requirements Document provide?
Now that you know what this document is and when it’s needed, you want to know what it contains. There are three main sections of the document:
Your current state
What do you have in place today and what does your Salesforce instance currently look like? This portion includes the systems, processes, data, integrations, and roles that currently make up your Salesforce org and tech stack.
Your pain points and challenges
Where are the problem areas with your system and processes today, and what specific pain points should this project address? Clearly outline the systems, process, or data the project should focus on as well as the issues that you currently face.
Your ideal future state
What is the desired outcome of this project? Describe both the technical requirements your team is looking for as well as the business impact. This section should cover the goals and results you’re looking to achieve.
The formal Requirements Document includes User Stories and Use Cases. These provide context on why each requirement is important. Users indicate what needs to be completed, who is responsible for completing this, why it’s needed, and the desired end state. Each team/function provides use cases for the document.
A final component of the document is a list of App integrations for each business function. Include the name, description, and purpose of each App, as well as a list of everything integrated with it.
What does my team need to do?
Now that you know what goes into a formal Requirements document, you’re wondering what the effort is for your team. What resources and time commitment should you expect? Completing the Formal Requirements Document consists of three parts:
Complete Discovery Worksheets
The discovery process includes an initial discussion of relevant stakeholders with members of OpFocus. We will walk through the requirements template as you provide information on each business function and process. During this process, you’ll provide information on the current state, pain points, and desired future state.
Identify individuals for each function to serve as stakeholders. These individuals should have an intimate knowledge of the systems and processes for a specific function as they’ll provide User Stories and a walkthrough of systems & integrations associated with the department. These system walkthroughs are a large part of the discovery process and provide my team with the in-depth knowledge they need to create the documentation.
Provide Documentation
As part of the documentation process, your team will compile a list of business processes and functions, as well as any 3rd-Party applications or platforms that impact the functional areas of your project. For example, if your project involves the Salesforce sales platform, you’ll provide a list of all sales stages. Included in this list should be the platform/process name, function, and existing integrations with other applications. Your team has the chance to review the formal Requirements Document after my team compiles it. You’re encouraged to make edits and recommendations to the document before its final approval.
Participate in Post Discovery Meetings
After the initial discovery, we’ll meet on a regular basis to review the document and discuss updates. These meetings are a designated time to discuss updates and make any additional edits to the formal Requirements Document.
How much time should my team expect to work on this?
How long does the process take? This is a question we get all the time. The number of discovery calls for a formal Requirements Document is directly related to the size of the project. Each discovery call takes between 1-2 hours. A small project with a more narrow project scope involves about 2-3 discovery calls. Mid-sized projects involve 5-10 discovery sessions and large projects can have up to 25. Between meetings, you’ll prepare documentation and make subject matter experts available for use case conversations. The time commitment for these commitments is largely based on your internal documentation. We’ve worked with very well-organized teams that already have much on this documentation for internal use.
How do I get started on my formal Requirements Document?
Now you know what a formal Requirements Document is, the information it includes, and what’s needed from your team. So what’s next? If you’re ready to get started on your requirements document, connect with the member of OpFocus you’ve been speaking with. Let’s set your project into hyperdrive.
If you’re not ready, then you probably have questions about what happens once you bring OpFocus. Reach out to your contact at OpFocus and they’ll answer any questions you have
