The Requirements Document Guidelines
Principles of Project Management
The requirements document is created for a project depending on the type of project, the needs
for the project, and preferences of the organization, and the organizations stakeholders.
This deliverable for this assignment requires that each ‘Team’ develop a ‘Project Requirements
Document,’ to not exceed six (6) pages of content in length (double spaced,) (the cover sheet of
the template is a seventh page.)
The following sections must be prepared in the ‘Requirements Document’ template:
1. Executive Summary
2. The Requirements Document Purpose
3. Project Conditions and Characteristics
4. High-Level Scope of The Project
5. Detailed Project Requirements
The following are considerations that may be used in developing a project requirements
Who do we need to talk to, to understand the business problem, opportunity, or directive? Who
are the sponsor(s) and who are the key stakeholders, and what are their perspectives and
What is the business case that outlines the requirements and verifies the business need? Who is
responsible for the solution that will be produced?
What is the definition of the scope of the project and the product(s) or process(s) that will be
The Business Case:
What problem, opportunity, directive, or need is to be solved?
What is the scope of the solution to the problem?
Is the investment in solving the problem worth it?
What are the functional requirements for the project? Can these requirements be translated into
specifications? Do they include software requirements, technical requirements, look, feel,
features, and functions? Do they identify how the solution functions, operates, interreacts,
performs, and delivers results? This may include:
User interface assessment
User acceptance understanding
Exemplary (5.0-4.5 points): Provide full description of the requirements for the proposed project.
Complete each of the required sections of the ‘Requirements Document.’ Write in clear and
concise terms. Follow the guidelines for the format of the report and the naming convention.
Each member of each team contributes to the narrative. Effective (4.4-4.0 points): Provide an
adequate description of the of the requirements for the proposed project. Issues with the
format, or the concise and focused narrative. Minimal requirements that do not follow the
guideline. Ineffective (3.9-3.5 points): Selects requirements that are not well explained or that
are not aligned with the proposal, without explaining why this is the optimal choice.
Unacceptable (3.4-0): Failed to articulate sections of assignments or assigned deliverables,
and/or failed to deliver the ‘Requirements Document.’
Written Assignments: All written assignment must be word processed, with a 12pt font size, be
double spaced, have normal margins, include page numbers, be submitted on the scheduled due
date, and delivered as an MS Word file type (not as a .PDF) to the appropriate ‘Assignment Drop
Box’ on the course homepage. Reports and/or papers that are submitted after the due date will
be automatically reduced in score by twenty percent (20%) before they are read.
All written reports/templates must be uploaded as a softcopy to the appropriate ‘assignment
drop box’ in the ‘Assignment’ section of the course homepage.
The ‘Documentation Specialist’ is responsible for uploading the completed work products for the
The following naming convention must be used when uploading the project work products:
Course Number Assignment Name Team Name and Semester Abbreviation
Example: MSPM1-GC1000 The Requirements Document Team Name….
Delivery Channel: Upload the completed ‘Team’ assignments to the appropriate assignment
drop box in the ‘Assignment’ section of the course home page.
Project Requirement Document
Organization or Business Unit or Department
Team Members Names:
Course ID Number:
The name of the
The name of the
• Change 1
• Change 2
• Change n
The Principles of Project Management
Provide a ‘high level’ statement of the proposed project, and the rationale and business
justification for undertaking the project. Reference the business problem or opportunity that
precipitated the initiation of the project. This is not a detailed review of the sections to follow,
but rather a high-level overview. More detailed explanations are reserved for the respective
sections that follow.
The Requirements Document Purpose
This section should be a short description of the purpose of this tool: ‘The Requirements
Document.’ Explain to the reader why it is important to develop a document that includes a
listing of what the customer/client requires in the solution that will be developed for the project.
You may reference the proposed scope for this project, to provide context for explaining why it
is important to develop a set of specific and systematic requirements that describe the features
and functions that will be needed in the solution (deliverables) that will be produced in this
A requirement document defines what you are looking to achieve or create, to solve the problem
or take advantage of the opportunity, for which a project has been proposed. The purpose of
the ‘Executive Summary’ of the requirements document is to provide a high-level overview, not
a full explanation, of how this tool will be used to document the functional and non-functional (if
applicable) requirements of the project. These requirements will be based on an active outreach
to the project owner and its stakeholders, to understand their needs. It may be used to describe
examples of the features and functions that the project ‘solution’ will be expected to deliver.
This template is intended for use to facilitate the formal documentation of the requirements for
a project. It will be version controlled to ensure that the iterations of an evolving set of
requirements is systematically controlled. The primary audience for this document will be the
stakeholders who have an interest and expectations for the deliverables that will be produced
from this project. Use this section to explain the purpose that the ‘Project Requirements
Document’ will serve.
The contributors and reviewers of this document will include the project ‘Executive Sponsor,’ or
‘Project Owner,’ authorized ‘End-users’ and ’Subject Matter Experts,’ ‘Business Analysts’ and
Technical Analysts (as appropriate,) and the ‘Project Manager’ and ‘Project Team Members.’
When this document is accepted by representatives of each stakeholder as an appropriate
understanding of the statement of requirements for the project, then the team will use it as a
guide to develop the business case, as a precursor to develop detailed specifications for the
project, and as a critical resource for determining the formal scope of the project.
Project Conditions and Characteristics
This section is to be written as a narrative and will provide a high level (non-technical) description
of the project conditions and characteristics. Each of the following subheadings can be
referenced in this narrative. It is preferable to retain the subheadings, and include a brief
narrative related to each of them, under the subheading.
Why have you chosen to develop this product (or service) and the need that it will serve.
Who the primary stakeholders are, who is developing the project, and who will benefit
from the finished product.
The Solution Functionality
What the features and/or functions are for this solution will deliver, what its purpose will
be, and what is the primary need this solution will satisfy.
Who the stakeholders are (and why,) including the participant stakeholders, the vested
interest stakeholders, the customer and/or workforce stakeholders, and their motivation
to use it.
Product or Service Functions
What does product or service do? What is its purpose or function? What activities can
users perform while using it? List the main functions and or features that you will build
into your product here.
Project assumptions are circumstances and events that need to occur for the project to
be a success, but outside of the control of the project team. They are listed as
assumptions if there is a high probability that they will happen.
Project dependencies are logical links, between the tasks of a project, as well as links to
other projects outside of the control of a project manager. These include logical planning
dependencies (logic driven,) resource-based dependencies (resource limits,) and
preference planning dependencies (the Project Manager’s preferences.)
These are restrictive conditions or limitations that the project may face, such as the
availability of resources when needed, or restrictive date or time limitations. The three
baseline constraints are represented here, including the ‘schedule’ baseline, the ‘budget’
baseline, and the ‘scope’ baseline, in addition to the influencing constraints, including
‘risk,’ quality,’ and resources.
The High-Level Scope of the Project
This section is used to define the high-level logical boundaries of the project. The emphasis is on
the ‘Goal(s’) of the project. It will include a high-level statement of purpose. The anticipated
deliverables for the proposed project (both the ceremony of the project process as well as the
product or service that is to be produced.) Provide enough explanation and detail for the reader
to be able to understand what is being proposed. Note: these are stated in more general terms.
Detailed Project Requirements
This section of the document lists specific requirements, detailed deliverables (specific products
or services) that the project is expected to deliver. This section lists specific requirements
(functional and non-functional) for project. It may include features, functions, look, feel, design,
operations, rules, regulations, policies, procedures, or compliance concerns that must be met.
Requirements may be divided into the following sections as applicable:
1. User requirements. These are requirements written from the point of view of end users,
usually expressed in narrative form (the most common of the requirements.)
2. System requirements. These are detailed specifications describing the functions the
system must be capable of doing (see the systems requirements section below
3. Interface requirements. These are requirements about the user interface, which may be
expressed as a list, as a narrative, or as images of screen mock-ups (If applicable.)
User Requirements (Functional)
Requirements should be written from the point of view of end-users, expressed in a
narrative form. They should describe the required look, feel, features, functions,
behavior, and any other characteristics of the final deliverables of the solution(s)to be
derived from the project. This may come from business rules, policies, procedures,
regulations, or law. Discovery typically is through the elicitation sessions with users,
stakeholders, and other stakeholders. It will include gathering data and information from
surveys, focus groups, reports, a scan of information from the external environment, and
other methods that are associated with determining the scope of the project
System Requirements (Non-Functional)(If applicable)
Note: for a systems related (IS/IT) project, it is common to collect what is known as
nonfunctional systems requirements. These are requirements that typically are not visible
or obvious to the customers or clients for home this project is focused. These
requirements may be related to the design or implementation of a system solution, and
can include performance requirements, security requirements, volume of use
requirements, or reliability requirements. It is important to be aware of this type of
requirement, but it may not be applicable to all projects.
Prepared by __________________________________
Approved by_ Edward Kleinert_________________________________
Project Executive Sponsor
Appendices (If applicable):
This section of the requirements document represents various resources that be important to refer
to that will have an impact upon identifying requirements and supporting their needs. They are
different types of document resources that may be included (if applicable.) Use this to list the
various support documents that you may acquire see the following examples.
Legal and Regulatory Documents
Policies and Procedures That Apply to The Governance of an Organization
Product Design Documents
Standards and Practice Documents
Environmental Analysis Documents
Exhibit: Rules for Effective Requirements
Note: this appendix is for your use in helping to develop a project requirement. It does not
need to be developed for the requirements document assignment, but rather is a reference for
the work that needs to be done for this assignment. Is not needed Each requirement must form
a complete sentence, containing a subject and a predicate. These sentences must consistently
use the verb ‘shall,’ ‘will’ or ‘must’ to show the requirement’s mandatory nature, and ‘should’ or
‘may’ to show that the requirement is optional. The whole requirement specifies a desired end
goal or result and contains a success criterion or other measurable indication of the quality.
1. Identify and define objectives
• Explain for what purpose the system is being deployed
• Qualified objectives identify the desired deliverables
• The value proposition explains return-on-investment
2. Verify the requirements against the objectives
• Validate accurate scope for high-level requirements
• Assure consistent focus for application rules
• Provide critical management tools for scope change decisions
• Verify every iteration of the requirements and design documents
3. Defining a good requirement
Correct (technically and legally)
Complete (express a whole idea or statement)
Clear (unambiguous and not confusing)
Consistent (not in conflict with other requirements)
Verifiable (it can be determined that the system or solution meets the
Traceable (uniquely identified and tracked)
Feasible (can be accomplished within cost and schedule)
Modular (can be changed without excessive impact)
Design-independent (do not pose specific solutions on design)
Team Name: XLocker
Team Members Names:
Course Name: Principles of Project Management
Course ID Number: GC1000
Principles of Project Management
Summary of the Proposed Project
Our team proposes to develop a mobile application called “XLocker” which
would store important documents such as passport, state ID, driver’s license,
medical insurance card, and social security proof. The mobile app will be a verified platform for digital document storage by the United States Government.
The digital versions of the documents will be accepted at all airports, train
and bus stations, hospitals and all government organizations and departments
such as the Department of Motor Vehicles (DMV), national security departments, etc.
The Problem or Opportunity
Most of us end up carrying a lot of important documents, especially during
travel which can be lost or misplaced leading to unwanted consequences such
as identity theft and personal confidential data being compromised. This is
where XLocker comes in. It is a government-vetted secure storage place for
documents and can only be accessed with a numerical passcode, face identification or fingerprint biometrics, which will ensure access to the documents
only to verified users and their respective verified accounts.
The High-Level Scope of the Proposed Project
Since the application for XLocker will be government verified, it will be marketed through the government and its agencies for easy adoption by the residents of the US.
The app can be downloaded from the app store on apple, google and android
devices. Once download is complete, the user will have to enter some preliminary information to verify his/her identity. Once verified, the user will be able
to create a profile by choosing a username and password, and filling in the
forms for the respective documents that have to be uploaded. The forms will
need information such as the number on the document, date of issue, date of
expiry, issuing authority, address associated with the document, etc., which
will be verified by the government to issue the digital version of the documents
to be stored on the app. A unique QR code will be associated with each approved document that can be scanned in place of the original physical document.
Once the application is verified by the government and released to the public,
the Xlocker team, in conjunction with the government will market and advertise the app through social media platforms, public modes of transport and
billboards. The company will also set up customer service and IT helplines for
any questions and/or concerns.
Proposed Deliverables and Objectives
o A Mock-Up Mobile Application - Building a mock-up of the app with the
necessary UI/UX , and integrating functions such as upload, verification
by third party organizations, etc. This process will include a continuous
feedback loop until finalization.
o The Mobile Application - Once final changes are made, and the US Government approves the mock-up and its functions, the app will be built.
Once fully developed, it will be tested with some target consumers to
check for glitches and bugs before eventual release to the public. Since
the application is government verified, the company XLocker, along with
government advertising agencies will market the app for quick adoption
by the residents of the US.
Purchase answer to see full