Professional Documents
Culture Documents
The Requirements Traceability Matrix (RTM) is designed to serve the following purposes:
:To support the capture and management of all categories of requirements and business rules.
:To provide a means of verifying that the project team correctly understands the requirements and business rules.
:To allow for traceability of detailed requirements back to high-level drivers, objectives and benefits and thereby demonstrate to the project sponsor and senior management
that all elements of the project can be justified.
:To allow for traceability of the solution design elements back to the requirements to ensure that they have been fully catered for.
:To provide a means of communicating the requirements to the people who will design, implement and test the solution.
:To provide a baseline document to be referred to when determining whether issues with the solution are to be treated as defects or change requests.
The requirements within this document are meant to be solution independent. They are intended to provide a statement of what the solution is to do and how well it should do
it but not of how it will be implemented.
Approval of this document along with the associated Service Specification Overview (if provided) is taken as confirmation that our understanding of the requirements and
business rules is correct.
A significant amount of explanatory text is provided within this document either below or as information rows within the worksheets.
Questions regarding the content of the document, the requirements for your project, should be directed to the relevant Business Analyst or Project Manager.
ID (mandatory)
All requirements statements should be allocated a unique ID. This supports traceability, aids communication and facilitates change impact assessment.
The format of these IDs is usually XXXN although other formats are allowed. The XXX is a unique string that helps to associate the ID with the requirements sections to which it
belongs. It is preferable to use a string that readers will easily associate with the subject name. For example, if the subject is Ordering, you might use ORD as the string. The N
part of the ID is a sequential integer that uniquely identifies the requirement within the subject area. E.g. ORD1, ORD2, ORD3.
Be wary of changing the ID of any existing requirement. This may cause problems for traceability.
Implementation phase
For solutions that will be rolled into production over a series of phases, this attribute indicates the phase in which the requirement is to be satisfied.
NFR Traceability (mandatory)
The ref number of the related item in the Non-Functional Req's Analysis template used to elicit non-functional requirements. Used to support traceability.
Parent requirements (recommended)
The ID(s) of the parent requirement(s) that each requirement can be traced back to. This is a key element in enabling traceability and evaluating the completeness of the set of
requirements needed for the project success.
Priority (mandatory)
An indication of the importance of the requirement. Refer to the Lists worksheet for a list of the available options and their meaning.
Rationale (recommended)
Where appropriate, you should describe why the requirement is important. This may include references to other requirements if it makes sense to do so. This is optional
although generally recommended as a good practice.
Document Identification
File name: Unable to obtain the file name. Please enter it here manually and ensure to update it with each new version.
Version: Unable to determine version number. Please enter it here manually and ensure to update it with each new v
Status: Draft
Date: 1 Jan 2012
Prepared by:
Responsible Authorities
Service owner:
Sponsor:
Senior user:
Senior supplier:
System owner:
Contributors:
Example Availability Allow students to use the online forms via the public Internet with minimal interruption Students need universal access to these forms. PS Mandatory 1 Apr 2012 OBJ1,DBE1 Approved
throughout the year.
Example Support Provide business hours support with a maximum first response time of one hour. Support will be provided through the current ITS PS Mandatory 1 Apr 2012 OBJ3 Approved
Support processes.
SRQ1 New
Project Services | Requirements Traceability Matrix Page 5 of 68
604686134.xlsx
<set your project name on the Front Page> - Service Brief
Current Requirement
ID High level capability Description Rationale Stakeholder Priority Date Parent requirements Comments
function? Status
SRQ2 New
SRQ3 New
SRQ4 New
SRQ5 New
SRQ6 New
SRQ7 New
SRQ8 New
SRQ9 New
SRQ10 New
Acceptance criteria
The statements below outline the initial business expectations of how well the solution must perform in order to be accepted by the business and put into production. These statements will be used as a basis for the User Acceptance Testing scripts and may also influence the Utility and Warranty requirements.
Acceptance criteria (optional) -
i These statements define the criteria that must be satisfied in order for the project to be judged a success.
Example All mandatory utility and warranty requirements have been satisfied. PS Mandatory 1 Apr 2012 OBJ1,DBE1 Approved
ACR1 New
ACR2 New
ACR3 New
ACR4 New
ACR5 New
ACR6 New
ACR7 New
i You should delete these rows before presenting the RTM to others for review.
<set your project name on the Front Page> - Non Functional Requirements
High level process, function or A description of each requirement that is: Cohesive,
Unique identifier capability that the requirement Complete, Consistent, Correct, Feasible, Modifiable,
addresses. Unambiguous and Testable.
CNF3 Comply with privacy acts Ensure that all data that is stored, processed
or transmitted by the solution is done so in
accordance with the Information Privacy Act
(Vic) 2000 and the Privacy Act (Cth) 1988.
CNF4 Comply with the Health Ensure that all data that may be defined as
Records Act health information that is stored, processed or
transmitted by the solution is done so in
accordance with the Health Records Act (Vic)
2001.
CNF5 Comply with copyright acts Ensure that the solution is compliant with and
upholds the enforcement of the Copyright Act
(Cth) 1968 and the Copyright Amendment
(Digital Agenda) Act (Cth) 2000.
CNF6 Support users with Ensure that the solution can be accessed by
disabilities users with disabilities in accordance with the
Disability Discrimination Act (Cth) 1992,
Disability Standards for Education (Cth) 2005
and the Equal Opportunity Act (Vic) 2010.
Compliance to be assessed against WCAG 2.0
AA.
CNF7
CNF8
Technical Operational Requirements
i This section is used to capture the requirements for ITS technical support teams to effectively technically maintain, supp
ITS Technical Operating Standards and Activities
TOR1
TOR2
TOR3
Events & Remediation Management
ERM1
ERM2
ERM3
Build, Deploy, Decommission
BDD1
BDD2
BDD3
Project Checklists
Information Security Management (ISM)
i The following are standard requirements that apply to most University systems. Your sponsor should be familiarised w
If there is an intent by the business to have any component of the solution hosted externally, e.g. Student Gmail, you sho
i may need to be factored into the requirements.
SEC1 Central user authentication Ensure that the electronic identities of all users
are established through the University’s
Identity and Access Management tool before
allowing access to the solution.
SEC2 External system Ensure that external systems and interfaces
authentication are identified, authenticated, and authorised
before granting access to the solution.
ACC2 Comply with WCAG 2.0 Ensure that web accessible elements of the
Level AA solution comply with the Web Content
Accessibility Guidelines set out in WCAG 2.0
Level AA.
ACC5 Alternatives for video and Provide alternatives for time-based media such
audio as video and audio.
ACC8 Data table headings Add column and row headings (e.g. <th>) to
data tables.
ACC9 Increased text size Ensure that all pages are readable and
functional when text size is increased by up to
200%.
AC10 Accessibility via keyboard Make all functionality available via the
keyboard.
ACC11 Sufficient time for reading Provide users with enough time to read and
use content.
ACC14 Language identification Identify the human language of the page (e.g.
English).
ACC16 Labels, cues and Provide sufficient labels, cues and instructions
instructions for users when completing forms.
ACC20 Javascript and adaptive Ensure that changes to the page via Javascript
technologies are reported to adaptive technologies.
AGC11 Support accessible content Ensure the availability of features that support
production the production of accessible content.
AGC12 Documentation Ensure that documentation promotes the
production of accessible content.
Usability
i The following are standard requirements that apply to systems that are to have a user-facing interface. Your sponsor sho
i Some other usability factors to consider are:
i - keyboard accelerators
i - languages required
i - online help
USA1 University MOEs Ensure that the system can be operated using
the current MOEs in place at the University.
USA6 Location Ensure that the system provides the user with
information about where they are in the system
or a task.
USA7 Task completion - success 75% of new users to the system should be
able to complete the 5 most common tasks
successfully on the first attempt.
USA8 Task completion - time Ensure that the system allows users to
complete a task in an acceptable time.
- 75% of users rate the time taken to complete
a task based on its complexity as good, very
good or excellent.
USA9 Page load If web-based, page load is less than 10
seconds for 90%
USA10 Content Ensure that headings, font size, spacing and
colour are consistent across the system.
USA11 Findability - navigation Ensure that the system allows users to find the
most common functions easily through the
system navigation.
- 75% of users rate the system as 'easy to find
content or functionality'.
USA16 Power users Ensure that features are provided that allow
power-users to do their work quickly and
effectively. For example, short-cut keys.
Branding
BRD01 UoM branding Provide the ability to customise the solution
with UoM logo, branding. Consistent use of
colours and style standards
BRD02 UoM branding Provide the ability to apply consistent colours
and style standards to the solution
quirements
existing IT customer
facing and/or Mandatory
Why is this requirement Who provided this
supporting IT services Desirable
needed? requirement?
that the requirement Optional
relates to
pport teams to effectively technically maintain, support and operate the service(s) once implemented into production
ty systems. Your sponsor should be familiarised with them and endorse them. You may remove them if they are not applicable to your project.
ution hosted externally, e.g. Student Gmail, you should refer to the Externally Hosted System Documentation Request for guidance on the sort of considerations that
Simplifies access and IT Security and Risk Mandatory
improves usability. Manager
h allow users to author content that will be viewable via the web. For examples, a CMS, blog or wiki.
The ATAG set out Web Accessibility Program Desirable
guidelines for ensuring that Leader
any web content generated
by users is accessible.
If the system allows users Web Accessibility Program Desirable
to enter information that Leader
will automatically generate
web content, then the
system should ensure that
the content is accessible.
re to have a user-facing interface. Your sponsor should be familiarised with them and endorse them. You may remove them if they are not applicable to your project
Your sponsor should be familiarised with them and endorse them. You may remove them if they are not applicable to your project.
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
New
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Service level
i This section is used to capture the needs of the business in regards to the support they'll need in the event of requests or problems of any type.
Example Service Desk support Level 1 support from the ITS Service Desk must be available for users between 8am and 5pm GD Mandatory 7 Apr 2012 HLR2 New
on University business days.
Example Response levels Provide responses for level 1 support requests within 2 hours. GD Mandatory 7 Apr 2012 HLR2 New
SLE1 New
SLE2 New
SLE3 New
System availability
Example Availability Ensure that the system will be consistently available to users between the hours of 8 am to 8 GD Mandatory 7 Apr 2012 HLR2 New
pm on University business days. There should be no more than 12 hours of accumulated
outages during these business hours within any calendar year.
SAV1 New
SAV2 New
SAV3 New
System performance
Example Online response time All screens should complete processing and return a response to the user within 5 seconds. Improves operational efficiency and user GD Mandatory 7 Apr 2012 HLR2 New
satisfaction.
SPE1 New
SPE2 New
SPE3 New
System capacity
i This section is used to capture the information about expected numbers of users and transactions along with anticipated growth patterns.
Example Availability Ensure that the solution is available to, and equally effective for, all users. Users will be in GD Mandatory 7 Apr 2012 HLR2
the following locations:
- Main Parkville campus
- Southbank campus
- Burnley campus
- Shepparton campus
- Dookie campus
- Creswick campus
- Werribee veterinary campus
Example Number of users The expected maximum number of users of the solution per year is <n>. Ensure that the GD Mandatory 7 Apr 2012 HLR2
solution can support the data volumes expected to be generated by this many users.
Example Concurrent users The expected number of concurrent users can vary from <n> to <n>. Ensure that the solution GD Mandatory 7 Apr 2012 HLR2
can still meet the performance requirements with this many concurrent users.
Example Annual transaction volumes It is expected that up to 250,000 books will be borrowed via the new system per year and that GD Mandatory 7 Apr 2012 HLR2
this will grow by 20% per year. Ensure that the solution can support this number of
transactions for at least the next 20 years.
Example Peak transaction volumes It is expected that up to 80% of the anticipated subject enrolments will occur within a one GD Mandatory 7 Apr 2012 HLR2
week period. Ensure that the solution can support this level of activity.
SCA1 New
SCA2 New
SCA3 New
System configuration
Example Ease of configuration changes Allow authorised business users to alter financial delegation limits in the production Reduces overheads and increases ability of GD Mandatory 7 Apr 2012 HLR2 New
environment without technical knowledge or support. business to self-serve.
SCO1 New
SCO2 New
SCO3 New
Continuity
Example Disaster recovery In the event of a major system failure, ensure that the system can be available to users again GD Mandatory 7 Apr 2012 HLR2 New
within 4 hours.
Example Disaster recovery In the event of a major system failure, ensure that no more than 24 hours of data is ever lost. GD Mandatory 7 Apr 2012 HLR2 New
CON1 New
CON2 New
CON3 New
Security
Business Rules
i Business rules can be distinguished as being invariant and independent requirements that either constrain structure or behaviour or require something to be done as the result of a defined trigger condition.
i These rules must be respected and supported by all persons, processes and systems.
i
i Business rules generally fall into two groups: Structural rules and Operating rules.
i Structural rules can be used to:
i - define terminology
i - define the nature or operating structure of an organisation
i - define the nature or structure of entities that the organisation works with
i - define the allowable relationships between the entities that the organisation works with.
i Operating rules can be used to:
i - define what actions must be performed based on some trigger condition
i - define what actions cannot be performed under certain conditions
i - define how information should be derived or transformed.
i
i Most importantly, you should remember that business rules exist and govern the structure and operations of the business regardless of what systems may or may not be in place.
i The requirements captured in this document should be in alignment with these business rules. You can use the Related requirements column to associate business rules with the related requirements.
i The solution that is delivered should support the implementation and enforcement of the business rules.
i
i Business rules should be:
i - stated in appropriate terminology to enable domain SMEs to validate the rules
i - documented independently of how they will be enforced
i - stated at the atomic level and in declarative format
i - separated from processes that the rule supports or constrains
i - maintained in a manner that enables the organisation to monitor & adapt the rules as the business policies change.
i
Example No more than 20% of program participants can be foreign nationals. Commonwealth law requires us to ensure that DIISR
no more than 20% of program participants are
foreign nationals.
Example Students must provide proof of their citizenship status before their admittance to a mobility program is approved. GD BR1 G007
BR1
BR2
BR3
BR4
BR5
BR6
BR7
BR8
BR9
BR10
BR11
BR12
BR13
(i.e. primary
author)
Accountable
Support
(i.e.
contributing
authors)
Consulted
Informed
Specific role Staff name
The roles that should
review the document and
provide feedback regarding
Reviewers its content which should
then be taking into
consideration when
finalising the document.
The role that provides
formal approval of the final
version of the document.
Approval The SCLC Artefact RASCI
spreadsheet defines the
approval roles for each
SCLC template.
Requirement Status
New The requirement is newly captured and has not undergone any review or approval process.
Changed The requirement has been changed since it was last reviewed or approved. It will need to be reviewed and approved again.
Validated The requirement has been reviewed and validated by the person who originally provided the requirement AND at least one other SME.
Approved The requirement has been approved by the project sponsor or an authorised business owner.
Deprecated The requirement can be ignored. It is either no longer relevant or a duplicate of another requirement statement.
Potential Duplicate The requirement is believed to be a potential duplicate of another requirement statement. This is to be assessed and acted on.
Incomplete The requirement needs additional information.
Sample The requirement is provided as a sample and should eventually be removed or confirmed as a valid requirement.
Out of Scope The requirement has been agreed as out of scope for this service change/project
Requirement Priority
Mandatory The requirement is mandatory. Failure to satisfy this requirement would be an issue serious enough to stop the solution going into production.
Desirable The requirement is desirable. Failure to satisfy this requirement may result in compromises to ideal business processes and require various workarounds.
Optional The requirement is optional. Failure to satisfy this requirement will not have a significant impact.
Unknown The priority of this requirement has not been determined.
Not Required The requirement can be ignored. It is either no longer relevant or a duplicate of another requirement statement.
Frequency of Usage Indicates how often the function is typically used within the business, inclusive of all users.
Ad-hoc
Daily
Multiple times in a week
Once in a week
Fortnightly
Once in a month
Once in a quarter
Twice a year
Once a year
Implementation Phase For solutions that will be rolled into production over a series of phases, this attribute indicates the phase in which the requirement is to be satisfied.
Phase 1
Phase 2
Phase 3
Phase 4
Phase 5
You may delete this Template Control worksheet prior using this workbook.
Template Control
Template approvals
Version Approval date Name
100 13 Aug 2012 Naomi Barry
Name Title
Mark Perelaer Team Lead - Project Centre, PMO
Prepared by
ew Rajesh Padmawar
Document Control section Rajesh Padmawar
Review Ref. Log table. Rajesh Padmawar
spreadsheet conventions. Removal of David Hodgman
simplify process.
content from previous Business David Hodgman
cument
emaining (BRD)
BRD template.
commentsMultiple
and feedback David Hodgman
e.
ignment of Front Page data.and
Provision of information David Hodgman
ents
n thetoUsage
default Accessibility
Guide. David Hodgman
ory textoffor
ucture some sections
requirements in the
across multiple David Hodgman
information about University goals to David Hodgman
section.
tweaks. David Hodgman
t to the Front Page. David Hodgman
nty Requirement" tab Naomi Barry
Functional
n-functionalRequirement" tabtab and to
Requirements Stephen Miles
n-Functional Requirements Analysis