Requirement management (RM) involves all the activities around product and project requirements, i.e., gathering, expressing, organizing, categorizing, prioritizing, decomposing, reviewing, tracing, changing, versioning and validating requirements.
It focuses on ensuring that the voice of the customer is heard at all points in the development process.
From the initial conception of the solution, through design, testing and changes Introduced for maintenance and product or project evolution.
The key concept in Requirement Management is Traceability – decomposing User Requirements into Product Requirement, specifications and Testing Requirements and then to mark the relationship between all requirements.
The first condition to allow traceability is a central location for all requirements and that when a requirement is changed or added, all impacted requirements will be updated as well if necessary.
Requirement Management involves an extra thought on how requirements are expressed and what information is kept for each requirement.
For example, common attributes for User Requirements are the customer who asked for it, the status of the requirement, its priority, and estimated development effort.
More advanced Requirement Management processes, will include a formal approval process to requirement changes, categorizing requirements into Functional and non-Functional Requirements, maintaining versions of requirements documents and tracking compliance to regulation and standards.
Requirement Management helps to make sure user requirements are expressed correctly and communicated to all project members.
It improves the quality of the product since user requirements are correctly translated into product and testing requirements.
Requirement Traceability will prevent cases where requirements fall between the cracks and will not be developed or tested on time. Such cases lead to frequent redesign and late defect detection, which lead to increased development costs and project duration.
We are all familiar with situations where QA are not aware of changes in the MRD, because they built their tests against the SRS that was not maintained, since its initial approved version.
Forming traceability between requirements allows identifying requirements that are neither handled, nor interpreted incorrectly.
It can also help asses the impact of a change in requirements on resources, budget, time frames and deliverables.
When an organization manages requirements in a central location everyone get a complete visibility of what is being developed, how a development is progressing, what is the status in QA and the health of the release.
Document all the requirements – this will prevent many misunderstandings and surprises during development and testing phases and will assure that everybody are aligned with the right requirements.
Express Requirements Clearly -There are many books and courses on how requirement should be written and categorized. A rule of thumb is that each requirements is expressed clearly, unambiguously, atomically (one requirement per statement) and in a quantified, testable form. You should also separate the problem domain (i.e. what is needed) from the solution domain (how it will be answered).
Structure - Start categorizing requirements into areas and levels of abstraction, for example: Stakeholder Requirements, System Requirements, Functional and non Functional, Testing, Performance, Security, Hardware, Interface, etc..
Record the Metadata - Gather all project stakeholders and start defining attributes i.e. unique ID, status, priority, responsibility, effort, dependency, release ,product, customer and any other additional attribute that will allow to manage, identify and filter requirements.
Centralized Repository - All requirements should be placed in a central location where everybody has access to and only there requirements are updated.
Trace - Analyze the types of relationships there are between requirements and form a traceability model. For example, product requirements, should reference the market requirements it was derived from and testing requirement should reference both market and product requirements.
Tools - This is when you may want to research the market for Requirement Management solutions. When working with Word and Excel, it is hard to have a single repository for all requirements and make sure all users access the latest requirement set of the project. It is almost impossible to form an effective and updated Traceability Matrix and Impact Analysis, when requirements are not stored in a database.
Streamline with Development - The holy grail would be to form an Application Life Cycle (ALM) process, where requirements are linked to development tasks and to test case and defects – this will allow a complete visibility to all aspects of the development life cycle.
Manageware is in the RM space for 10 years and executed dozens of projects.
- Process Assessment - RM Health ChecK - Work-flow definition - Document Templates - Automation - Integrations to other disciplines -On Site consulting to make it fly
Generally Focal Point allows product managers and development teams to get all their Features lists,
Excels, emails and product requests into a central web based repository that is easy to use and quick to setup.
If you currently manage features and requirements in Microsoft Word or Excel, it can help you to better organize, track, manage, trace and prioritize your feature lists in a structured, process oriented method.
You can export at anytime the information back into Word or Excel.
To evaluate whether your features are well defined you can build a checklist of 2-4 Yes/No questions and check each features against them.
Now, the most interesting feature of Focal Point is Prioritization. To prioritize features you articulate a set of 3-7 criterions and rank the features according to these criterions. You might find out that articulating criterions is not that simple task.
The prioritization process is iterative and criterions should be occasionally refined. Focal Point supports pairwise comparisons of your features according to each criterion in an automated 'bubble-sort' method.
Once the requirements are estimated and prioritized, you can visually evaluate the optimized set of features to plan into your next release and roadmap, as well as, build "what-if" scenarios to assist you in the decision process. This is a very powerful technique, however, it may require some preparations that might be seemed too formal.
Key Features:
Easy to use web-based central repository.
Linking & traceability between elements, such as , features, requirements, products, releases, competitors, etc...
Prioritization engine based on quantified estimations and qualitative pairwise comparisons.
Visual dynamic representations of Gap Analysis, Cost vs. Benefit, etc.
RequisitePro is a document centric repository based tool, which integrates using VBA macros with Microsoft Word as a front end. This is its big plus. It can be easly used by product managers, development and QA to gather, organize, manage, analyze and trace product requirements.
Since it is so tightly integrated with Microsoft Word and uses it as the client interface very little training is required. You can select requirement statements within the Word document and store it in RequisitePro Database. It allows defining attributes such as priority, status, release and responsibility.
RequisitePro supports all types of Requirements, like User, Product, System, Test requirements and even Use Cases.
When more advanced traceability and information manipulation is required, RequisitePro provides a DB interface to allow tracking of relationships between requirements in order to verify that high-level requirements are represented in lower level specs and as well as to understand the impact of change. This architecture is a a bit problematic in large deployments since the DB need to update the MS Word files frequently.
Key Features:
Easily supports different requirement, attribute and document types
Define queries and filters to quickly find information of interest
Uses MS Word as the user interface for a straight forward tool adaptation
Bi-directional traceability for impact analysis, coverage reports and traceability matrix
Off-line work
Robust Web interface for management and remote users
User defined views
Integration to other IBM tools
VB script API for easy customization and adaptation of the organization processes
ConsUsing MS Word and a central DB is problematic for large deployments
Requirement management (RM) involves all the activities around product and project requirements, i.e., gathering, expressing, organizing, categorizing, prioritizing, decomposing, reviewing, tracing, changing, versioning and validating requirements. It focuses on ensuring that the voice of the customer is heard at all points in the development process from the initial conception of the solution, through design, testing and changes Introduced for maintenance and product or project evolution.
The key concept in Requirement Management is Traceability – decomposing User Requirements into Product Requirement, specifications and Testing Requirements and then to mark the relationship between all requirements.
The first condition to allow traceability is a central location for all requirements and that when a requirement is changed or added, all impacted requirements will be updated as well if necessary.
Requirement Management involves an extra thought on how requirements are expressed and what information is kept for each requirement. For example, common attributes for User Requirements are the customer who asked for it, the status of the requirement, its priority, and estimated development effort.
More advanced Requirement Management processes, will include a formal approval process to requirement changes, categorizing requirements into Functional and non-Functional Requirements, maintaining versions of requirements documents and tracking compliance to regulation and standards.
Benefits
Requirement Management helps to make sure user requirements are expressed correctly and communicated to all project members.
It improves the quality of the product since user requirements are correctly translated into product and testing requirements.
Requirement Traceability will prevent cases where requirements fall between the cracks and will not be developed or tested on time. Such cases lead to frequent redesign and late defect detection, which lead to increased development costs and project duration.
We are all familiar with situations where QA are not aware of changes in the MRD, because they built their tests against the SRS that was not maintained, since its initial approved version.
Forming traceability between requirements allows identifying requirements that are neither handled, nor interpreted incorrectly.
It can also help asses the impact of a change in requirements on resources, budget, time frames and deliverables.
When an organization manages requirements in a central location everyone get a complete visibility of what is being developed, how a development is progressing, what is the status in QA and the health of the release.
Best Practices
The first step is to document all the requirements – this will prevent many misunderstandings and surprises during development and testing phases and will assure that everybody are aligned with the right requirements.
There are many books and courses on how requirement should be written and categorized. A rule of thumb is that each requirements is expressed clearly, unambiguously, atomically (one requirement per statement) and in a quantified, testable form. You should also separate the problem domain (i.e. what is needed) from the solution domain (how it will be answered).
Start categorizing requirements into areas and levels of abstraction, for example: Stakeholder Requirements, System Requirements, Functional and non Functional, Testing, Performance, Security, Hardware, Interface, etc..
Gather all project stakeholders and start defining attributes (i.e. unique ID, status, priority, responsibility, effort, dependency, release ,product, customer and any other additional attribute that will allow to manage, identify and filter requirements.
All requirements should be placed in a central location where everybody has access to and only there requirements are updated.
Analyze the types of relationships there are between requirements and form a traceability model. For example, product requirements, should reference the market requirements it was derived from and testing requirement should reference both market and product requirements.
This is when you may want to research the market for Requirement Management solutions. When working with Word and Excel, it is hard to have a single repository for all requirements and make sure all users access the latest requirement set of the project. It is almost impossible to form an effective and updated Traceability Matrix and Impact Analysis, when requirements are not stored in a database.
The holy grail would be to form an Application Life Cycle (ALM) process, where requirements are linked to development tasks and to test case and defects – this will allow a complete visibility to all aspects of the development life cycle.
Read More
