Get documents about "rtm_TMP
Document Sample
Revision History
Date Version Author Description of Change
0.50 Initial draft
1.00 Baselined to v. 1.00
Requirements Traceability Matrix Template
V 1.0
3/10/2011
Review and Outcome History
Date Version Reviewed by Outcome
Requirements Traceability Matrix Template
V 1.0
3/10/2011
DEP DIVISION — SYSTEM OR APPLICATION NAME
Change red text as needed. PROJECT NAME — Needs Assessment — vX.YY
Business Source of Need
Need ID Statement of Need Area Statement Business Priority Status Subject Area Notes
001 SAMPLE Program Area Managers need the ability to Medium
identify all program area interests in a facility
002 Low Proposed SA_01
003 High Under Review
004 Accepted
005
006 Rejected SA_06
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
Requirements Traceability Matrix Template
V 1.0
3/10/2011 Page 3 of 5 c3c61b5d-f3ad-4fa9-8a93-ca0e0c7a2210.xlsx
DEP DIVISION — SYSTEM OR APPLICATION NAME
Assign requirement numbers AFTER all requirements have
Change red text as needed. PROJECT NAME — Requirements — vX.YY
been added and sorted as needed.
Requirement Implementa- Use
Requirement No. Need(s) Requirement Type Addressed by tion Priority Timeframe Case(s) Testability Notes
SAMPLE REQUIREMENT REQ-001 001 Business Requirement DEP 1 N/A Test Plan
SAMPLE REQUIREMENT REQ-002 002 Business Rule Vendor 1 N/A Demonstration
SAMPLE REQUIREMENT REQ-003 003 Data Definition Both 1 N/A Simulation
SAMPLE REQUIREMENT REQ-004 004 Design Constraint TBD 1 UC-001 Inspection
SAMPLE REQUIREMENT REQ-005 005 External Interface N/A 1 UC-002 Analysis
SAMPLE REQUIREMENT REQ-006 006 Functional Requirement DEP 1 UC-003 Test Plan
SAMPLE REQUIREMENT REQ-007 007 Quality Attribute Vendor 1 UC-004 Demonstration
SAMPLE REQUIREMENT REQ-008 008 Solution Idea Both 1 UC-005 Simulation
SAMPLE REQUIREMENT REQ-009 009 Use Case or Usage TBD 1 UC-006 Inspection
Scenario
SAMPLE REQUIREMENT REQ-010 010 Business Requirement N/A 1 UC-007 Analysis
SAMPLE REQUIREMENT REQ-011 011 Business Rule DEP 1 UC-008 Test Plan
SAMPLE REQUIREMENT REQ-012 012 Data Definition Vendor 1 UC-009 Demonstration
SAMPLE REQUIREMENT REQ-013 013 Design Constraint Both 1 UC-010 Simulation
SAMPLE REQUIREMENT REQ-014 014 External Interface TBD 1 UC-001 Inspection
SAMPLE REQUIREMENT REQ-015 015 Functional Requirement N/A 1 UC-002 Analysis
SAMPLE REQUIREMENT REQ-016 016 Quality Attribute DEP 2
SAMPLE REQUIREMENT REQ-017 017 Solution Idea Vendor 3
SAMPLE REQUIREMENT REQ-018 018 Use Case or Usage Both 1
Scenario
SAMPLE REQUIREMENT REQ-019 019 Business Requirement TBD 1
SAMPLE REQUIREMENT REQ-020 020 Business Rule N/A 1
SAMPLE REQUIREMENT REQ-021 021 Data Definition DEP 1
SAMPLE REQUIREMENT REQ-022 022 Design Constraint Vendor 1
SAMPLE REQUIREMENT REQ-023 023 External Interface Both 1
SAMPLE REQUIREMENT REQ-024 024 Functional Requirement TBD 1
SAMPLE REQUIREMENT REQ-025 025 Quality Attribute N/A 99
Requirements Traceability Matrix Template
V 1.0
3/10/2011 Page 4 of 5 c3c61b5d-f3ad-4fa9-8a93-ca0e0c7a2210.xlsx
Business Implementation Testability
Business Areas Priorities Statuses Subject Areas Use Cases Requirement Types Addressed by Priorities Methods
Name Name Name Name ID Name Primary Actor Name Notes Name Name Name
BA_01 High Proposed SA_01 N/A N/A N/A Business Requirement A business requirement states a high-level business objective. It should answer the question: “Why are we DEP 1 Test Plan
devoting resources to this requirement?”
Categories:
• Financial benefits such as reduced costs, increased revenue, enhanced market share
• Improvements in business operations
• Strategic positioning or brand enhancement
• Regulatory compliance
BA_02 Medium Under Review SA_02 UC-001 UC-001 NAME Public User or Admin User Business Rule A business rule is an organization policy, industry standard, or law or government regulation that defines, Vendor 2 Demonstration
constrains, or governs some aspect of the business. Most business rules exist independently from a
specific software system (that is, they are not software requirements), should be treated as an enterprise-
level asset, and should be documented separately from system-specific requirements. A business rule can
lead to various sets of functional requirements.
Business rule sub-types include:
• Action Enabler: describes an action to be taken when a condition is true, usually written as an “if-then”
or “when-then” statement (for example, “If the customer has an active membership, then display
membership rates”)
• Business Constraint: a policy (whether determined by management or an external regulatory agency)
that limits what the system or an actor within the system can do.
• Computation, Calculation, or Formula: self-explanatory (for example, “The total price shall be
calculated as …”).
• Fact: a simple factual statement, often associated with data attributes (for example, “Each customer has
a unique customer number”).
• Inference: describes a change to the status of data, usually written as an “if-then” statement (for
example, “If the customer does not pay for the reservation by the payment due date, then change the
reservation status to canceled” ).
BA_03 Low Accepted SA_03 UC-002 UC-002 NAME Public User Data Definition Information that the system will Create, Read, Update, and/or Delete (CRUD). Typically this includes the Both 3 Simulation
name of a business object, its attributes, rules, and CRUD functions.
BA_04 Rejected SA_04 UC-003 UC-003 NAME Admin User Design Constraint A limitation of the solution or of its implementation. Examples: TBD 99 Inspection
• “Funding for this project is only $5,000.”
• “The UI has to be compatible with the following web browsers: …”
• “Coding must be in Java.”
BA_05 SA_05 UC-004 UC-004 NAME Public User or Admin User External Interface An interface between the system and the outside world. There are four types of external interfaces: N/A Analysis
• User interface
• Hardware
• Software
• Communication
BA_06 SA_06 UC-005 UC-005 NAME Public User Functional Requirement A single statement of one individual function. Sometimes referred to as TSS statements: “The system
shall …” Functional requirements and other types of requirements information typically are embedded in
the software requirements specification (SRS) document.
UC-006 UC-006 NAME Admin User Quality Attribute A quality characteristic that the system should possess. Sometimes referred to as quality factors or
quality of service requirements. Examples:
• Performance
• Reliability
• Scalability
• Security
• Redundancy
• Backup requirements
• Usability
• Availability
UC-007 UC-007 NAME Public User or Admin User Solution Idea A solution and/or statement of design. Usually stated by a business stakeholder, development or
implementaton team member, or even by the BA during project initiation or analysis. Examples:
• “We’ll need a new server for this application refresh.”
• “The public will have to book reservations only through the online system.”
It’s usually best to work backwards from a solution idea to identify the underlying business requirement:
“What problem are we trying to solve?”
UC-008 UC-008 NAME Public User Use Case or Usage Scenario Describes a process (collection of individual steps). Examples (possible use case name is underlined):
• “Users will be able to post payments to customer accounts.”
• “Users will be able to run accounts receivable agings reports.”
If starting from a use case or usage scenario requirement, it can be used as a way to identify functional
requirements. Its name should always start with an action verb.
UC-009 UC-009 NAME Admin User
UC-010 UC-010 NAME Public User or Admin User
