NATIONAL ARCHIVES AND RECORDS ADMINISTRATION (NARA)

STAKEHOLDER REQUIREMENTS
SPECIFICATION
(STRS)
TEMPLATE

<PROJECT NAME>

Version X.0 <DRAFT | FINAL>

Prepared by <author>
<Date created (Month XX, Year)>
 <Project Name>
Stakeholder Requirements Specification (StRS)

Table of Contents

1 Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.2.1 Assumptions 4
1.3 References 4
1.3.1 Compliance 5
1.3.2 Guidance 5
2 Business Abstract 6
2.1 Business Purpose 6
2.2 Business Scope 6
2.3 Stakeholders 6
3 System Abstract 7
3.1 System Purpose 7
3.2 System Scope 7
3.3 System Overview 7
3.3.1 System Context 7
3.3.2 System Functions 7
3.3.3 User Roles and Characteristics 7
4 Stakeholder Requirements 9
4.1 Attributes 9
4.1.1 Types 9
4.1.2 Categories 9
4.2 Requirements 10
Appendix A – Glossary 13

StRS_Template_v.4.0.docx Page 2 of 13
 <Project Name>
Stakeholder Requirements Specification (StRS)

Revision History
Date Version Author Revision Description
<mm/dd/yyyy <x.x> <FirstName> <LastName> <TBD>
>

StRS_Template_v.4.0.docx Page 3 of 13
 <Project Name>
Stakeholder Requirements Specification (StRS)

1 Introduction
This section introduces the Stakeholder Requirements Specification (StRS) for <Project Name>. It
discusses the purpose, scope and content of the document and provides an overview of the
functionality that is addressed by the requirements.

1.1 Purpose
<Provide a very brief description of the purpose of the project and what the StRS does to support this
goal.>
<This section may simply say something like "The purpose of this document is to provide the stakeholder
requirements for <Project Name> along with a context to help the reader understand them."
More information may be required. For example, if the point of the project is to do a study and make
recommendations, this section should include a brief description of the study and a statement like "The
purpose of this document is to present the stakeholder requirements derived from the
recommendations of the study.">

1.2 Scope
<Provide a description of the scope of the document.>
<This section may be a simple statement like "The document addresses the full scope of the <Project
Name> project." However, for something like a modification to an existing system, the scope of the
document (and the requirements) may only be the new requirements or a portion of the existing
system, in which case this section should make clear what is in and what is out.>
1.2.1 Assumptions
<It is important to document the assumptions that underlay the document and / or stakeholder
requirements. If there are none, just state "None".>
The following assumptions pertain to the contents of this document in general and to the requirements
specifically:
● <TBD1>
● <TBD2>
● <TBD3>
1.1 References
This section lists the sources that were utilized during the refinement of the <Project Name> stakeholder
requirements. It consists of two sub-sections, “Compliance” and “Guidance”. The documents listed
under “Compliance” directly influenced the content of the stakeholder requirements (i.e., they contain
requirements); the documents listed under “Guidance” contain information pertinent to the stakeholder
requirements but do not themselves contain requirements.

StRS_Template_v.4.0.docx Page 4 of 13
 <Project Name>
Stakeholder Requirements Specification (StRS)

1.1.1 Compliance
1.3.1-1. <Project Business Case>
1.3.1-2. <Project Vision>
1.3.1-3. <Project ConOps>
1.3.1-4. <Project Business Process Analyses (BPAs)>
1.3.1-5. <Project Interview Records>
1.3.1-6. <Project Survey Results>
1.3.1-7. <Feature Vision documents>
1.3.1-8. Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. §794 (d)); US
Government; 1/03/2012; http://www.section508.gov/.
1.3.1-9. Information and Communication Technology (ICT) Standards and Guidelines (82 FR
5790); US Government; 1/18/2017; https://www.gpo.gov/fdsys/granule/FR-2017-01-
18/2017-00395.

1.3.1-10. <TBD>
1.1.2 Guidance
1.3.2-1. NARA Systems Development Life Cycle (SDLC) Methodology Version 1.6; NARA;
11/27/2013.

1.3.2-2. NARA Enterprise Requirements Program Management Plan Version 3.1; NARA (IR);
04/26/2019.

1.3.2-3. NARA Requirements Verification Traceability Matrix (RVTM) Template Version 2.4; NARA
(IR); 02/25/2019.

1.3.2-4. International Standard ISO/IEC/IEEE 29148:2011(E): Systems and software engineering

—Life cycle processes — Requirements engineering; Institute of Electrical and Electronics
Engineers, Inc. (IEEE); 12/1/2011.
1.3.2-5. <Project SDLC Tailoring Plan>
1.3.2-6. <Stakeholder Analysis>
1.3.2-7. <TBD>

StRS_Template_v.4.0.docx Page 5 of 13
 <Project Name>
Stakeholder Requirements Specification (StRS)

2 Business Abstract
This section introduces the <Project Name> project and describes its business context.

2.1 Business Purpose

<Describe at the organization level the reason and background for which the organization is pursuing
new business or changing the current business in order to fit a new management environment. In this
context it should describe how the proposed system will contribute to meeting business objectives.
Note: Information for this section can be copied from a Business Needs Analysis document, Business
Case or ConOps.>

2.2 Business Scope

<Provide a short description of the system being specified including name, high level benefits,
objectives, and goals. Explain what the system will do to satisfy the business need. Note: If a separate
vision and concept of operations document is available, please summarize the content here.>

2.3 Stakeholders
The Stakeholders that are relevant to the <Project Name> requirements are specified in Table 2-1.
<List the groups or classes of stakeholders and describe how they will influence the organization and
business, or will be related to the development and operation of the system. This table may be modified
appropriately. Table 2-1 is required.>
<The "Symbol" column of 1 is for the organization symbol when a NARA organization or the abbreviation
/ acronym for an external organization.>

Table 2-1: Stakeholders – Organizations

Organization Type Main Interests Impact of Project
<The organization's full name <Primary <The main interests of the <The impact of the outcome of
and organizational symbol or | organization as regards the the project on the
abbreviation/acronym for an Secondary project.> organization.>
external organization.> >

StRS_Template_v.4.0.docx Page 6 of 13
 <Project Name>
Stakeholder Requirements Specification (StRS)

3 System Abstract
This section introduces the <Project Name> project and describes its system context.

1.3 System Purpose

<Define the reason(s) for which the system is being developed or modified.>

1.4 System Scope

<Define the scope of the system under consideration by
a) Identifying the system to be produced by name.
b) Referring to and stating the results of the earlier finalized needs analysis, in the form of a brief
but clear expression of the user's problem(s). It explains what the system will and will not do to
satisfy those needs.
c) Describing the application of the system being specified. As a portion of this, it should describe
all relevant top level benefits, objectives, and goals as precisely as possible.>

1.5 System Overview

1.5.1 System Context
<Describe at a general level the major elements of the system, to include human elements, and how
they interact. The system overview includes appropriate diagrams and narrative to provide the context
of the system, defining all significant interfaces crossing the system's boundaries.>
1.5.2 System Functions
<Provide a summary of the major functions (i.e., fundamental actions / system capabilities) that the
system will perform. The summary should show the different functions and their relationships and
should be organized in a way that makes the list of functions understandable to the stakeholders. This
summary typically consists of a simple hierarchical decomposition of the functions, but is dependent
upon the specific system.>
<The functions are typically identified via the requirements elicitation activity. Although functional
analysis and decomposition is typically a system engineering activity that is associated with system
architecture and design, some of the techniques involved may be useful to the BA; there are many
information resources available via the Internet.>
<When a Concept Of Operations (ConOps) exists, it may include a Functional Decomposition that can be
used as a basis for this summary; if the Functional Decomposition is very detailed, you may want to
reduce the amount of detail for inclusion in this document.>
1.5.3 User Roles and Characteristics
The business user roles that are relevant to the <Project Name> requirements are specified in Table 3-1.

StRS_Template_v.4.0.docx Page 7 of 13
 <Project Name>
Stakeholder Requirements Specification (StRS)

<Identify each type of user/operator/maintainer of the system (by function, location, type of device),
the number in each group, and the nature of their use of the system.>

Table 3-1: User Roles and Characteristics

Role Characteristics
<Role1 Name> <Responsibilities and system usage>
<Role2 Name> <Responsibilities and system usage>
<Role3 Name> <Responsibilities and system usage>

StRS_Template_v.4.0.docx Page 8 of 13
 <Project Name>
Stakeholder Requirements Specification (StRS)

4 Stakeholder Requirements
This section describes how the <Project Name> stakeholder requirements are organized and provides
access to the stakeholder requirements via an embedded Microsoft® Excel® object.

1.6 Attributes
This section describes the attributes of the stakeholder requirements utilized for <Project Name>.
1.6.1 Types
Three types of requirements are identified for <Project Name>, as specified in Table 4-1.

Table 4-1: Types of Requirements

Category Description
Business Business requirements define the critical activities that a project that must perform to
meet the organization's objective(s) while remaining solution independent (i.e., "what
the organization wants or needs to be able to do once the project is completed").

Business requirements are included with the stakeholder requirements to provide

traceability and to promote a better understanding of the stakeholder requirements by
making the associated business requirements more accessible. The business
requirements typically come from the project's business case.

Note: It may not be appropriate to include the business requirements with the
stakeholder requirements because of various issues, such as availability. However,
it is highly recommended that they be included when possible.
Business Rule Criteria or condition that dictates a system’s action or response.
Stakeholder Stakeholder requirements define decisions about business needs, goals, and objectives
from the perspective of the stakeholders and their role in the business.

Stakeholder requirements are expected to decompose the business requirements.

1.6.2 Categories
Four categories of requirements are identified for <Project Name>, as specified in Table 4-2.

Table 4-2: Categories of Requirements

Category Description
Constraint Constraints limit the options open to a designer of a solution by imposing immovable
boundaries and limits (e.g., the system shall incorporate a legacy system element, or
certain data shall be maintained in an online repository).
Functional Functional requirements describe the system functions or tasks to be performed.
Non-Functional Non-functional requirements identify operational or system properties. They define
how a system should be. Information Management, Availability, Backup and Recovery,
Compatibility, Maintainability, Reliability, Transferability, Performance, Capacity,

StRS_Template_v.4.0.docx Page 9 of 13
 <Project Name>
Stakeholder Requirements Specification (StRS)

Scalability, Security, Usability, and User Interface requirements are examples of this
type.
N/A Used for Business requirements for purposes of completeness, i.e., to ensure that
every requirement traces to a category. (Business requirements are not typically
categorized.)

1.7 Requirements
The <Project Name> stakeholder requirements are maintained in Requirements Verification Traceability
Matrix (RVTM) that is embedded in this document. To view the contents of this Microsoft ® Excel®
workbook, double-click the following icon.
<This embedded object (template) below should be replaced by the project's stakeholder requirements
workbook.>

↑ double-click to open ↑

Note: You must have Microsoft Excel 2007 or newer to view the above workbook.
The equivalent “viewing” application may also be used.

This RVTM workbook consists of two worksheets:

● Requirements
This worksheet contains the stakeholder requirement id (i.e., Req #), requirements text, and
related information.
The contents of this worksheet are sorted in ascending order by “Req #”.
Columns with a red header are required attributes. Columns with a blue header are optional
attributes.
● Standard Values
This worksheet contains the lists of standard values that are used by the Requirements
Management Division (IR) to instantiate drop-down lists for some of the columns of the
Requirements worksheet.
The columns in the Requirements worksheet are defined as follows:
● Req #
A unique identifier for the requirement.
● Requirement Text
The text of the requirement.

StRS_Template_v.4.0.docx Page 10 of 13
 <Project Name>
Stakeholder Requirements Specification (StRS)

● Type
The type of the requirement, such as "Business" or "Stakeholder". Refer to Table 3-1.
● Category
The category of the requirement, such as "Functional" or "Non-Functional". Refer to Table 3-2.
● Feature
The high-level function, capability, feature or other grouping that has meaning for the
stakeholders.
● Req Priority
The priority of the stakeholder requirement as assigned by the stakeholders.
The valid values for this column (MoSCoW) are recorded in Section 6 of Reference 1.3.2-2 and
are reproduced below:
Must1 requirements that are CRITICAL to meeting the project's objectives
Should requirements that are critical and should be included if possible, but which can be
excluded
Could requirements that are part of the project's scope and add or enhance project benefits
Would requirements that do not have a significant impact on project benefits or could be
considered as a “would like to have”
● Status
The status of the requirement.
● Target Release
The release in which the requirement will be developed. Note that this column may be blank
and hidden from view upon the initial documentation of the requirements, but should be
updated during the appropriate phase of the project.
● Source
The source of the stakeholder requirement, such as "Business Case" or "Interview".
● Process Description
The process description(s) or diagram(s) that are applicable to the stakeholder requirement.
● Use Case
The use case(s) that are applicable to the stakeholder requirement.

1 Minimal Useable SubseT (MUST)

StRS_Template_v.4.0.docx Page 11 of 13
 <Project Name>
Stakeholder Requirements Specification (StRS)

● Notes
Pertinent additional information about the requirement.
For example, it is sometimes very difficult to state a function clearly and precisely. In this case,
simpler and more easily understood requirement text might be used with additional information
under “Notes” which expands upon the intent of the requirement.
Note: There are additional columns in the embedded RVTM to capture the requirements traceability to
Design, Development, Verification, and Deployment Preparation (User Acceptance Testing) attributes.
These columns will be blank upon the initial documentation of the requirements, but should be updated
during the appropriate life cycle phases of the project.

StRS_Template_v.4.0.docx Page 12 of 13
 <Project Name>
Stakeholder Requirements Specification (StRS)

Appendix A – Glossary
<Define all of the abbreviations (including acronyms) and terms necessary to properly interpret this
StRS.>
Abbreviation Definition
ConOps Concept of Operations
e.g. exempli gratia ('for the sake of example')
i.e. id est ('that is'; 'in other words'; 'that is to say')
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers, Inc.
Inc. Incorporated
IG [NARA organization] Program Management Division, Information Services
IJ [NARA organization] IT Project Management Division, Information Services
IR [NARA organization] Requirements Management Division, Information Services
ISO International Organization for Standardization
IT Information Technology
MoSCoW Must, Should, Could, Would (requirements priorities, in order of decreasing
importance or desirability)
N/A Not Applicable
NARA National Archives and Records Administration
PM Project Manager
POC Point Of Contact
REQ Requirement
RVTM Requirements Verification Traceability Matrix
SDLC Systems Development Life Cycle
StRS Stakeholder Requirements Specification
TBD To Be Determined

Term Definition
Stakeholder An individual, group, or organization who may affect, be affected by, or perceive itself
to be affected by a decision, activity, or outcome of a project.

<Delete the word Template from the title page and the footer. Do not forget to remove the watermark!
To remove the watermark in the entire document using Microsoft® Word®, select the entire document
(Ctrl-A) then do Ribbon > Design > Page Background > Watermark from Page Background group >
Remove Watermark.>

StRS_Template_v.4.0.docx Page 13 of 13