5. Requirements Management and Documentation Flashcards
5.1 Requirements Management 5.2 Change Control 5.3 Version Control 5.4 Tools in requirements management 5.5 Types of Requirements 5.6 Legal Issues and Business Analysis 5.7 Documenting Requirements 5.8 Requirements Modelling
5.7 Requirement Documentation
What is the rationale for requirements documentation?
+ Provides a record of stakeholder/business needs
+ Records the source of requirements in case further clarification is needed later
+ Records the priority of requirements in case there is insufficient time
+ Forms an audit trail and allows for traceability
5.7 Requirement Documentation
What are some important considerations to make when documenting requirements?
+ Consider if the format is appropriate for the intended audience and situation
5.7 Requirement Documentation
What are the components of a requirements document?
Introduction and Background
Business Process Models
Function Models
Data Models
Requirements Catalogue
Glossary
5.7 Requirement Documentation
What are some requirements documentation formats?
Requirements Catalogue
User Stories
Use Cases
5.7 Requirement Documentation
What are the elements of a Requirements Catalogue?
Requirement ID: unique identifier
Requirement Name
Source
Owner: provide expertise & advice on the requirement
Author
Priority
Stakeholder: interested in success of the requirement
Type of Requirement:
Requirement Description: actor/verb/object
Acceptance Criteria: measures that will determine if the requirement has been met
Rationale: business justification for the requirement
Comments
Related Documents
Related Requirements
Resolution: included or not in final solution
Version History
5.7 Requirement Documentation
What are the different elements of a user story?
Cards
Conversation: discussion surrounding them
Confirmations: acceptance tests that verify them
5.7 Requirement Documentation
What are the different elements of a fully described use case?
Use case name
Reference
Scope
Level
Actor
Stakeholders
Trigger/Event
Preconditions
Main success scenario
Alternative flows/Extensions
Measures: Performance, volumes etc.
5.1 Requirements Management
What is the rationale behind requirements management?
Requirements management enables the BA to keep track of changes to requirements and the impact of these changes.
+ Enables close control of requirements and ensures that any changes are properly authorised and documented
+ Addresses the issues of storage, traceability, security and control of requirements
5.1 Requirements Management
What are the elements of requirements management?
Identification of the requirements Noting the source of each requirement Identifying the owner of the requirement Cross referencing requirements Change Control Version Control Storage of the Requirements
5.1 Requirements Management
Why is traceability of requirements important?
+ Allows us to trace a requirement’s resolution throughout the development lifecycle
+ Enables us to remember the source of each requirement so that we can refer back to the stakeholder for further clarification/detail
+ Enables us to trace the impact of a change in a requirement to other related requirements
+ Allows us to link business benefits back to specific requirements
5.1 Requirements Management
How is traceability achieved?
+ It is achieved through proper requirements documentation, change control and version control
+ Through documenting of sources, owners, related requirements and related documents for each requirement
5.1 Requirements Management
What is the difference between vertical and horizontal traceability?
Vertical
Tracing business and project objectives to functional and non-functional requirements
Horizontal
Tracing requirements from their source (stakeholders, documents etc.) through the development lifecycle all the way to their resolution and influence on the system
5.2 Describe the change control process.
+ At the start of the project, identify who can authorise and approve changes to requirements
+ Record the version of any document and requirement throughout the entire project
+ Whenever a change of a document or requirement is proposed, a change request should be documented
+ Evaluate the impact of the proposed change on cost, time and other requirements
+ Decision made on whether to accept, reject or defer change
NOTE: Once documents are reviewed and agreed they are baselined. Any subsequent changes require authorisation
5.1 Requirements Management
What is the configuration management process?
Allocating a unique identifier with a version number to a requirement or document. Any changes lead to changes in the version which can then be tracked.
5.1 Requirements Management
What are some sources of change?
New laws and regulations
New people and ideas
Detailed investigation and further probing
Changes to other systems
