HANDOUT #1
<Insert Project Name>
Requirements Definition Template
Version: Major.Minor
This template developed by Requirements Quest is based on IEEE (Institute of Electrical and Electronics
Engineers) 803 Standard SRS (Software Requirements Specification). For additional information, visit
http://www.ieee.org. To request an electronic copy of this template, send an email to
[email protected].
<Insert Project Name>
Requirements Definition
Table of Contents
1.
INTRODUCTION..........................................................................................................3
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.
1.7.
2.
REQUIREMENTS........................................................................................................4
2.1.
2.2.
2.3.
2.4.
3.
PURPOSE OF THIS DOCUMENT..........................................................................3
REFERENCE MATERIALS..................................................................................3
SPECIFIC TERMS AND ACRONYMS.....................................................................3
USER ROLES................................................................................................3
ASSUMPTIONS..............................................................................................3
CONSTRAINTS...............................................................................................3
DEPENDENCIES.............................................................................................3
BUSINESS REQUIREMENTS...............................................................................4
USER AND FUNCTIONAL REQUIREMENTS............................................................4
NONFUNCTIONAL REQUIREMENTS.....................................................................5
COMMON INFORMATION..................................................................................6
APPENDICES..............................................................................................................7
3.1.
3.2.
3.3.
3.4.
REVISION HISTORY........................................................................................7
VALIDATION HISTORY.....................................................................................7
REQUIREMENTS ISSUES..................................................................................7
ATTACHMENTS..............................................................................................7
Public Version 5.2
<Insert Project Name>
1.
1.1.
Requirements Definition
Introduction
Purpose of this document
This document contains all User-level and System-level requirements for this project.
1.2.
Reference Materials
There are many other documents that together describe the complete set of requirements for this project.
Reference Document Name
1.3.
Brief Description
Location of Definitive
Source
Specific Terms and Acronyms
Terms here are specific to understanding the content of this document.
Term or Acronym
1.4.
Description
User Roles
Roles played by various users that interact with the business process or system are described here.
Role
1.5.
Description of Role and Activities Performed
Performed By Job
Title (Optional)
Assumptions
Identify anything that adds clarification to or provides background information about the requirement
statement, or other related item.
ID
Assumption Statement
Related To
A1
1.6.
Constraints
Identify anything that puts limits on implementing the requirements.
ID
Constraint Statement
Related To
C1
1.7.
Dependencies
Detail any external event, condition, or system that must be in place for a requirement to be valid.
ID
Dependency Statement
Related To
D1
4
<Insert Project Name>
2.
Requirements Definition
Requirements
1.8.
Business Requirements
Business-level requirements are written from the sponsors perspective. The business requirements identify
the reason why the project is being done or what business objective it supports, as well as the benefits to the
business. Business requirements are typically documented early in the project life cycle or the planning
phase of the project, and are frequently documented in the project management deliverables.
ID
Business Requirement Statement
B1
The purpose of the [project name]
is to [describe project goalwhat is the team to implement or deliver?]
so that [describe the measurable, business benefits for doing the project].
1.9.
User and Functional Requirements
User-level requirements are written from the user roles perspective. Named information is shown quoted in
these requirement statements. Information used in the user-level requirements is described in the Common
Information section below.
Functional requirements are written from the systems (features or functions) perspective. What must the
system do to support the user role? Information referenced in the functional requirements is described in the
Common Information section below.
Column Header Key:
BR = Business Rules Identifier, CI = Common Information Identifier, S = Status, P = Priority
Status Column Key: A = Accepted, C = Changed since last review, N = New since last review.
ID
User and Functional Requirement Statements
BR
CI
DOMAIN
User Role
Goal A
A.U1
AU1.F1
AU1.F2
A.U2
AU2.F1
Goal B
B.U1
BU1.F1
B.U2
BU2.F1
5
<Insert Project Name>
ID
User and Functional Requirement Statements
Requirements Definition
BR
CI
BU2.F2
User Role
User Role
Goal C
C.U1
CU1.F1
CU1.F2
C.U2
CU2.F1
CU2.F2
1.10.
Nonfunctional Requirements
Nonfunctional requirements focus on the qualities that must be applied to design and implement the system.
These are specific standards and attributes in support of the other requirements. For detailed information
about nonfunctional requirements, including over 2,000 suggested elicitation questions, reference
The Quest for Software Requirements, by Roxanne E. Miller, www.RequirementsQuest.com.
ID
Nonfunctional Requirement Statements
BR
CI
OPERATION Requirements: How well does the system perform for daily use?
Access Security
How well is the system guarded against unauthorized access?
The extent to which the system is safeguarded against deliberate and intrusive faults from internal and external sources.
N-ACS1
Availability
How dependable is the system during normal operating times?
The degree to which users can depend on the system to be up (able to function) during normal operating times.
N-AVL1
Efficiency
How fast can it process? How many can be processed? How well does the system respond?
The extent to which the software system handles capacity, throughput, and response time.
N-EFC1
Integrity
How accurate and authentic are the data?
The degree to which the data maintained by the software system are accurate, authentic, and without corruption.
N-INT1
Reliability
How immune is the system to failure?
The extent to which the software system consistently performs the specified functions without failure.
N-REL1
Survivability
How resilient is the system from failure?
The extent to which the software system continues to function and recovers in the presence of a system failure.
N-SRV1
Usability
How easy is it to learn and operate the system?
The ease with which the user is able to learn, operate, prepare inputs, and interpret outputs through interaction with a system.
N-USE1
REVISION Requirements: How easy is it to correct errors and add functions?
<Insert Project Name>
ID
Requirements Definition
Nonfunctional Requirement Statements
BR
CI
Flexibility
How easy is it to modify to work in different environments?
The ease with which the software can be modified to adapt to different environments, configurations, and user expectations.
N-FLX1
Maintainability
How easy is it to upkeep and repair the system?
The ease with which faults in a software system can be found and fixed.
N-MNT1
Scalability
How easy is it to expand or upgrade the systems capabilities?
The degree in which the system is able to expand its processing capabilities upward and outward to support business growth.
N-SCL1
Verifiability
How easy is it to show the system performs its functions?
The extent to which tests, analysis, and demonstrations are needed to prove that the system will function as intended.
N-VER1
TRANSITION Requirements: How easy is it to adapt to changes in the technical environment?
Interoperability
How easy is it to interface with another system?
The extent to which the software system is able to couple or facilitate the interface with other systems.
N-IOP1
Portability
How easy is it to transport?
The ease with which a software system can be transferred from its current hardware or software environment to another.
N-POR1
Reusability
How easy is it to convert for use in another system?
The extent to which a portion of the software system can be converted for use in another.
N-REU1
1.11.
Common Information
In the other Requirements subsections, specific information that is referenced multiple times may be
described once here. This named information may then be referenced by its name with quotes around it in
the rest of the document.
ID
Named Information
Related
Req. ID
Definition or Business Usage /
Business Elements
Definitive
Source
CI1
CI2
CI3
CI4
CI5
CI6
<Insert Project Name>
3.
Appendices
1.12.
Revision History
Change
Date
1.13.
Requirements Definition
Changed
by
Description of Change
Version
Validation History
Participant Index
ID
Stakeholder Name
Supplier 1
Supplier 2
Supplier 3
Supplier 4
Receiver 1
Receiver 2
Receiver 3
Receiver 4
Specific Role or Area of Expertise
Outcomes: A = Accept, C = Accept with Conditions, R = Reject
Review
Overall
Supplier Outcome(s)
Receiver Outcome(s)
Date
Outcome
S1
S2
S3
S4
R1
R2
R3
R4
1.14.
ID
Identified Issues
Requirements Issues
Description
Raised by
Assigned to
Statu
s
IS1
IS2
IS3
IS4
1.15.
Attachments
Below are other documents that help to illustrate and define the User-level and System-level Requirements.
1.1.1.
Attachment
