It project requirements template

Introduce the project and its background — the why, what, how, who and when. This section helps set a context for the project, and ideally references its underlying business case where one exists. The Overview is key for your intended audience to understand why you have chosen to deliver this project, be it an enhancement or new system development. The Scope section describes the major functional and non-functional Scope for the project, enhancement, initiative.

Ideally, this will be represented as a set of high level bullet points that correspond to high level requirements.

Each bullet Requirement here will or should have a corresponding set of detailed Requirements elsewhere within or outside the document. As the name implies, Out of Scope sub-section explains what will NOT be delivered by this project, and usually why. This is important to manage expectations of your stakeholders assumptions about scope are, as you will be aware, a major source of heartburn during implementation sign-off.

On Agile projects, high level requirements usually correspond to Epics and the big User stories that make up these epics. For most non-project stakeholders, the Overview and Scope sections provide sufficient information about the project so it is important to be both concise and precise at the same time. No project undertaking is without its knowns and unknowns. We cannot hope to mitigate or resolve every risk or issue before delivery can begin.

With each known RID, make sure to identify a path to resolution that could help mitigate or resolve it. Risks, Issues and Dependencies arise throughout the lifecycle of a project. Usually, medium to large corporations maintain an online RID tracker linked to a project on a tool such as Clarity. Sometimes assumptions include aspects like resource availability from a particular team that are external to your project and may not follow similar planning practices.

The assumption here is that the back-end team will be available during the agreed timeframe and not be pulled into other higher priority or urgent work. And the risk is that they may not be able to support your project as agreed. What we need is a standard format that you can use to document all requirements.

On Waterfall and Agile projects alike, your company may dictate you follow certain naming and numbering standards for requirements. Why do they have their own sections? This is because NFRs are often stated in measurable terms, and hence need to be stated differently to other requirements.

For example: when a customer logs on to the mobile app, logon should complete and dashboard should load in less than 2 seconds; the system should never go offline, except for scheduled maintenance periods, etc.

This section provides references and links to documents and material that provide more context or supplement the Requirements Document. On Agile projects, you can provide links to the Dashboard, Product Backlog and other Agile artefacts.

On Waterfall projects, you can provide links to the Change Requests Log link? In general, Business case, Architecture and Design documents, supporting Regulatory documents and links, underlying business and marketing documents all find a place in this section.

Add a Glossary of technical and non-technical terms that need defining to add clarity to the document. The glossary benefits stakeholders and project team members that may not understand all the terminology and acronyms being used in the Requirements Document. That depends. In other cases, Audit, Compliance and Legal teams have insisted on seeing a physical document that is specifically dated.

As you can see, while we may have come a long way with Agile, there are some pressing real life needs that still need to be addressed with practical solutions. So, I have recommended to such clients that they should simply extract the Product Backlog or Release Backlog if your Product Backlog spans multiple releases , and insert it in place of the Requirements and Non-functional Requirements.

Your unique project, team, organisational situation will dictate what other sections you need on a Requirements Document template. The information above is intended to get you started on the most fundamental information set any Requirements Document should cover, and I hope you find it useful.

Remember to always prioritise progress over documentation. But then again, remember that documenting knowledge of a project, product, system is essential to ensure business continuity and future project success. Agreed upon requirements. Keyword here is requirements. Basically, the document opens with various project features and progresses into more critical aspects. Uniform revisions. Take note of the Revision History section. Any time a change is made by project managers or employees, this is clearly documented to maintain uniformity.

Most of your time will be spent in the various requirements sections as seen in the External Requirements image. Check out the filler text and see how each section will be useful. Ready for the grand finale? Call it whatever you want. This requirements gathering template is one of a kind. Exact in natur. Ok, lets not trump things up too much. Just dig in and find out for yourself. No reason to over explain, check out the details below.

But the document also commands everything to be nailed down before all details are released. Defined roles and designations. Take a look at the second image. The planning project committee and the technical action committee are divided and stated for separate roles.

This is crucial. Clear revision history. Once again, its important to have a clear revision history when putting projects on paper. Set up a simple conversation or possibly a series of conversations to gather the high-level business requirements right away, and your detailed functionality requirements will follow.

In fact, it could be a big black box for them. That builds trust—something that will help you to get through even the most difficult, complex projects. And eventually, the answers to your questions will turn into expected interactions, features, or functionalities that will help you begin your requirements documentation.

Set yourself up for future iterations of your project requirements documentation by formatting these responses in a readable, shareable format. This will set the expectation of what goals the project will meet and how what you deliver will map back to those goals. The best way to document these requirements is in a spreadsheet or list that works for your team.

You can get a head start by downloading our free Google Sheets project management requirements document template. Start with a top-level question about functionality, and use the response to dig deeper. As you can see, several questions could come out of one single response, and each response could add requirements to your work.

Therefore, this exercise is quite important in understanding what your team can do within your scope. An example coming from the line of questioning above may look like this:.

During design, your team might come up with some new ideas or features that either add to or build on your current requirements. Think of your documented requirements as the ultimate tool in setting project expectations. Sounds pretty great, huh?

The process outlined here is a fairly standard approach to defining and documenting requirements for projects of all sizes. From there, you can look into other methods and tools to help you through the project requirement and documentation process. Just remember: Details are your friend, and they like to hide. Want to save time and effort on project planning? With TeamGantt, you can build an interactive project plan without the tedium.