The main objective of the second project management knowledge area, which is called scope management, is to gather requirements and transform them into the project scope. Collect requirements process is the second process of scope management, which comes after creating the scope management plan. During this second process of PMP Scope management, several techniques can be used to collect requirements. After requirements have been collected and finalized, they are documented as requirements documents.
Attend our 100% Online & Self-Paced One-Hour Free PMP Training.
As described in PMP Training, project documents are important for each phase of the project life cycle; and naturally so are the requirements documents. Because requirements are foundations of the project scope and they reflect the expectations of project stakeholders. Requirements history, whether it is in the final list, or eliminated, which deliverable will fulfill the requirement etc. needs to be documented in order to meet all agreed requirements of a project once the project is completed.
In this article, we are going into the details of requirements documents. If you’d like to get further information about requirements documents, project management professional courses will give you that specific information.
What is included in Requirements documents?
Let’s begin by listing the main requirements documents. Requirements documents should include these kinds of requirements:
Business Requirements: Business requirements generally come from the customer of the project. They represent the product features, or what the end outputs of the project need to provide. Let’s consider an e-commerce shopping website example. Developing a retail online shopping site that will get the 2% of the market in the US is an example of a business requirement, so it should be documented as a part of requirements documents.
Stakeholder requirements: Any person, group of people, company or parties that will be affected positively or negatively by the project are project stakeholders. Each project stakeholder can bring a requirement to the project which should be a part of requirements documents.
Solution requirements: Solution requirements are actually technical requirements. For instance, during meetings with the software architecture team of the company, since the customer data of the e-commerce shopping website is critical, software architecture team can require building geographically backed up databases.
Project requirements: These requirements are generally about schedule and budget. For instance, sponsor of the project might require completing the project in 6 months and with a $1,500,000 budget. This is another example of requirements documents as well.
Transition requirements: These are the requirements documents that generally describe how to switch from an old system or product to a newer one. For instance, let’s consider that you are managing a database upgrade project. Since your site will be live and since the database will have critical customer data, how to switch off the old database and how to activate new data on the new database must be clearly planned and documented as one of the requirements documents. Otherwise, there will be service loss and this will affect customers.
Other Types Documents
Other than the requirements documents listed above, there are also different kinds of requirements documents. These are assumptions, dependencies, and constraints and they are also included in the requirements documents.
Project management is actually planning activities that will happen in the future with the information available today. While doing these, assumptions can be done. Let’s consider a construction project. Weather conditions can affect a construction project severely. Therefore, the planning process can be done under the assumption that there won’t be long-lasting bad weather conditions that will affect the project.
Dependencies can be either internal or external. For instance, a software development project can be depending on the infrastructure implementation project and the software development project can start only after the infrastructure implementation project completed. Or the start of a construction project will depend on the procurements of the materials.
Constraints define the limits of the project. For instance, if the budget available for the project is $1,000,000, this is a constraint and you have to finish the project with this budget. Or if the company can assign only 6 software developers for your project, this is an example of resource constraint.
Note that, assumptions, dependencies, and project constraints affect the success of a project. Therefore, usually, assumptions, dependencies, and constraints are put in contracts as well to make these legally binding.
