The Most Complete Guide to Requirements Management and Traceability
Glossary
Table of Contents
|
Acronyms
|
Terms
|
Definition
|
|---|---|---|
|
RM
|
Requirements Management
|
The process of identifying, documenting, analyzing, tracing, prioritizing, approving, and maintaining requirements for a project or product.
|
|
BRD
|
Business Requirements Document
|
A formal document that describes the high-level business requirements for a project or product. It typically includes information about the business need, scope, stakeholders, functional requirements, non-functional requirements, assumptions, constraints, risks, and project timeline.
|
|
FRD
|
Functional Requirements Document
|
A detailed document that describes the specific functional requirements for a project or product. It typically includes information about the system features, user requirements, use cases, scenarios, data requirements, and acceptance criteria.
|
|
NFRD
|
Non-Functional Requirements Document
|
A detailed document that describes the specific non-functional requirements for a project or product. It typically includes information about the system performance, scalability, availability, reliability, security, maintainability, usability, and accessibility.
|
|
SRS
|
Software Requirements Specification
|
A comprehensive document that describes the functional and non-functional requirements for a software system. It typically includes information about the system architecture, design, implementation, testing, and deployment.
|
|
Use Case
|
Use Case
|
A technique for capturing and describing the functional requirements of a system by defining the interactions between the system and its users or other systems. It typically includes a description of the steps taken by the user or system to achieve a specific goal or task.
|
|
Traceability Matrix
|
Traceability Matrix
|
A document that provides a traceable link between the requirements, design, implementation, testing, and deployment of a system. It typically includes information about the relationship between the requirements and other system artifacts, such as test cases, defects, and change requests.
|
|
Change Control Board
|
Change Control Board
|
A group of stakeholders responsible for evaluating, approving, and managing changes to the requirements, design, implementation, testing, and deployment of a system. It typically includes representatives from various departments, such as business, development, testing, and operations.
|
|
Requirements Elicitation
|
Requirements Elicitation
|
The process of gathering and documenting the requirements for a project or product from stakeholders, users, and other sources. It typically involves techniques such as interviews, surveys, observations, focus groups, and brainstorming sessions.
|
|
Stakeholder
|
Stakeholder
|
A person or group of people who have an interest in the success of a project or product. It typically includes customers, users, sponsors, business owners, developers, testers, and support staff.
|
|
Requirements Prioritization
|
Requirements Prioritization
|
The process of ranking the requirements for a project or product in order of importance or urgency. It typically involves identifying the critical requirements that must be addressed first and assigning a priority level to each requirement based on its business value, technical feasibility, and risk.
|
|
Requirements Management Tools
|
Requirements Management Tools
|
A software application used to support the requirements management process. It typically includes features such as requirements capture, traceability, version control, collaboration, reporting, and analytics. Examples of requirement management tools include Visure Solutions, IBM Rational DOORS, Jama Connect, and HP ALM.
|
|
Baseline
|
Baseline
|
A set of approved requirements that forms the basis for further development and testing of a system. It typically includes the functional and non-functional requirements that have been agreed upon by the stakeholders and signed off by the change control board.
|
|
Validation
|
Validation
|
The process of evaluating whether the requirements for a system are complete, accurate, and consistent with the stakeholders' needs and expectations. It typically involves reviewing the requirements documents, conducting stakeholder reviews, and verifying that the system meets the specified requirements through testing and other methods.
|
|
Verification
|
Verification
|
The process of evaluating whether the system meets the specified requirements. It typically involves testing the system against the acceptance criteria defined in the requirements documents and ensuring that all the requirements have been implemented correctly.
|
|
Scope
|
Scope
|
The boundaries and objectives of a project or product. It typically includes information about the features, functions, and capabilities of the system, as well as the constraints and limitations that must be taken into account.
|
|
Impact Analysis
|
Impact Analysis
|
The process of evaluating the potential effects of a change to the requirements, design, implementation, testing, or deployment of a system. It typically involves identifying the affected areas of the system, assessing the risks and benefits of the change, and determining the resources and timelines required to implement the change.
|
|
Requirements Review
|
Requirements Review
|
A formal process for evaluating the requirements documents to ensure that they are complete, accurate, and consistent with the stakeholders' needs and expectations. It typically involves a review by a team of stakeholders, including developers, testers, business analysts, and subject matter experts, who provide feedback and identify any issues or concerns that need to be addressed.
|
|
Requirements Traceability
|
Requirements Traceability
|
The ability to track and manage the relationship between the requirements and other system artifacts, such as design documents, test cases, defects, and change requests. It typically involves creating a traceability matrix or other tool to ensure that all the requirements are accounted for throughout the development process and that any changes to the requirements are properly managed and documented.
|
|
Requirements Baseline
|
Requirements Baseline
|
The set of requirements that has been approved by the stakeholders and forms the basis for further development and testing of a system. It typically includes the functional and non-functional requirements, as well as any constraints, assumptions, and risks that have been identified. The requirements baseline is used as a reference point for managing changes to the requirements throughout the development process.
|
|
Requirements Engineering
|
Requirements Engineering
|
The systematic and disciplined approach to eliciting, analyzing, specifying, validating, and managing the requirements for a project or product. It typically involves the use of various techniques, such as interviews, surveys, use cases, scenarios, and prototypes, to ensure that the requirements are complete, accurate, and consistent with the stakeholders' needs and expectations.
|
|
Requirements Documentation
|
Requirements Documentation
|
The collection of documents that describe the requirements for a system, including the business requirements document, functional requirements document, non-functional requirements document, use cases, user stories, and other related documents. Requirements documentation provides a comprehensive understanding of the system's features, functions, and capabilities, as well as the constraints, assumptions, and risks that must be taken into account throughout the development process.
|
|
BR
|
Business Requirements
|
The high-level objectives and goals that a system must meet to satisfy the stakeholders' needs and expectations. Business requirements typically focus on the business processes, policies, and rules that the system must support or improve, rather than the technical details of how the system will be implemented.
|
|
FR
|
Functional Requirements
|
The detailed descriptions of the features, functions, and capabilities that a system must have to satisfy the stakeholders' needs and expectations. Functional requirements typically define how the system will behave or respond to specific inputs or events, and they may include constraints, assumptions, and acceptance criteria that must be met to ensure that the system meets the stakeholders' requirements.
|
|
NFR
|
Non-Functional Requirements
|
The descriptions of the system's performance, reliability, security, usability, and other qualities that are necessary to satisfy the stakeholders' needs and expectations. Non-functional requirements typically define the system's attributes or characteristics, rather than its specific features or functions, and they may include constraints, assumptions, and acceptance criteria that must be met to ensure that the system meets the stakeholders' requirements.
|
|
User Story
|
User Story
|
A brief, informal description of a feature or function that a system must have to satisfy the stakeholders' needs and expectations. User stories typically follow a simple template, such as "As a [user], I want [feature], so that [benefit]." User stories are used to capture the requirements in a simple, understandable format that can be easily communicated and prioritized by the stakeholders and development team.
|
|
Acceptance Criteria
|
Acceptance Criteria
|
The criteria that a system must meet to be considered acceptable or satisfactory by the stakeholders. Acceptance criteria typically define the expected behavior or results of a system in specific scenarios or use cases, and they may include quantitative or qualitative measures that must be met to ensure that the system meets the stakeholders' needs and expectations. Acceptance criteria are used to validate the system against the functional and non-functional requirements and ensure that it meets the stakeholders' requirements.
|
|
ALM
|
Application Lifecycle Management
|
Application Lifecycle Management is the procedure of specifying, designing, documenting, and testing the application. It covers the whole lifecycle from the start to the end of the project. It begins with the idea of the application throughout the development, goes to testing, deployment, support, and finally, the user experience.
|
|
CMMI
|
Capability Maturity Model Integration
|
CMMI defines a set of best practices for software development, project management, and organizational management that can help organizations improve the quality, efficiency, and effectiveness of their software development processes.
|
|
MBSE
|
Model-Based Systems Engineering
|
An approach to systems engineering that uses models to represent, analyze, design, and verify complex systems. MBSE involves creating a set of models that capture the system's requirements, behavior, architecture, and other key aspects, and using these models to guide the development process.
|
Don’t forget to share this post!
