Opportunities & Approaches

If requirement re-use is applied it is often rather unstructured in the sense that requirements are copied from one project to another. Structured approaches for requirement re-use seem to be rarely established. Structured approaches consider defined processes and tools that are applied to properly manage requirements re-use.

However it needs to be stressed that the re-use of requirements does not automatically lead to a high design re-use: for the same requirements different solutions (“designs”) could still be applied. But it offers for sure the opportunity.

Requirement re-use may offer significant advantages – especially when defining requirements for new projects or products:

• Speed:
  The timeline to achieve a complete requirement definition for a new product can be shortened. Therefore time to market can be accelerated.
• Completeness:
  Using checklists / requirements from previous initiatives completeness can be more easily achieved. Therefore product quality and compliance can be enhanced.
• Product Quality:
  Requirements may have been enhanced previously and experience may have been gained in regards to risks and issues with those requirements. Therefore the product quality description could be enhanced – which in the end may also enhance the product quality itself.

Especially within companies that have not yet established a structured approach to requirements management and that still follow a very document-centric approach requirement re-use can be a huge opportunity: If requirements are defined via diverse documents that are managed by diverse authors there is low probability of structured re-use. It may be a challenge to even find the requirements once documented in those diverse sources.

What are possible approaches for requirement re-use?

As stated above a simple but robust mechanism is simple copying of requirements. This is achievable in many ways:

If you manage your requirements essentially via documents you can, of course, simply copy them from one project to another. Also within requirement management tools copy mechanisms typically exist.

This is getting more sophisticated if you trace the link from source item to the copied item. It becomes very difficult via the document-based approach, but is still achievable in many requirement management tools. In this way you are able to understand which requirements are re-used often and you can trace the flow of re-use. Also you are able to apply basic change management procedures: You may achieve transparency of the re-use and consider the multi-use of a requirement within your requirement change process.

The next level of re-use, after copying and linking, is what we would like to call “referencing”: Requirement definitions are maintained centrally. They can then be referenced into different projects, which are simply using those central requirement definitions. In the best case they can enrich the requirement definition with project specific information like the actual requirement fulfillment for instance. See Picture 1 for illustration.

This approach of requirement re-use is more challenging and cannot be achieved via a classic document-based approach: You need to have a central database for requirements. Also the software solution needs to be capable of managing such a principle. Unfortunately not many requirement management solutions are capable of such an approach out of the box.

The three levels of requirement re-use are summarized in the picture below (Picture 2).

Referencing	Requirements are mastered centrally Requirements are referenced into diverse projects Project specific information can be enriched - like the requirement coverage for instance (Prerequisite: Requirement Management Solution with referencing and proper change management)
Copy and Link	Requirements are copied from ine project to the other Via links between the copies the connection becomes traceable In case of changes those connections remain visible (Prerequisite: Requirement Management Solution with proper configuration management control)
Copy	Requirements are copied from one project to the other No traceable link between copied items

The referencing principle might be especially useful if a platform / product line management is applied: In those cases a central definition of the platform or the product line needs to be maintained. This central definition is then made available for those projects / products that are using this platform / belong to this product line. In both cases a corresponding governance organization needs to be in place to manage those requirements and designs centrally.

What requirements are applicable for re-use?

Obviously re-use of requirement content is not applicable for all requirements – otherwise your product would essentially look and behave the same. So the valid question is: For which requirements does re-use make sense?

A first cluster may be the area of legal constraints and compliance aspects: They are often standards that are applicable to many, if not all of your products. Often those requirements are rather robust and could be centrally managed. Also company standards in regards to quality could be re-used: For instance quality standards for the surface quality of a device can be defined that are applicable for all or some products of a dedicated product family.

Other applicable aspects may be in one of the following areas:

• Logistics
• Maintenance
• Security
• Environmental

Beyond this there is the other trend of modularization on the solution side: So more and more products consist of modularized components that are shared for multi-use across diverse products. Obviously in those cases the requirements in regards to those shared components need to be aligned between all re-use partners.

Example: If a brake system is shared across different bicycles the requirements for the break system must have been agreed for all bicycle projects. So in this case the demand of reducing the product complexity by re-using components leads also to an agreement of requirements across multiple projects.

In this scenario again the re-use of requirements seems to be applicable, even a prerequisite, for strong design re-use.

What prerequisites exist for re-use?

Obviously requirement re-use is not achievable for free – otherwise we may have experienced much stronger utilization across industry already. There seem to be a couple of aspects that need to be in place to establish requirement re-use.
It starts with aspects in the area of requirement management tools:

Features as described above for referencing and copying need to be available. Copying may be achievable with many tools – real referencing principles may not be in place out of the box. Also a proper mechanism for change management needs to be there: Versioning of requirements needs to be possible to implement different iterations of changes and apply them in a controlled way to the different usages. In addition the authorization concept needs to be capable to separate the authorizations to maintain the requirement definition (multi-use and therefore managed centrally) from project-specific requirement data like the requirement fulfillment (managed per project / product). Finally a prerequisite is obviously that the requirements are managed in a central repository – easy retrievable for the different stakeholders.

The IT tool itself is however just one dimension – more important are measures in the area of process and organization:

If you want to establish requirement re-use you need to establish central authorities accountable for maintaining those requirements. This obviously requires a change of current governance models. Besides this change of governance models also a corresponding role model needs to be established that interacts with the other stakeholders – essentially with the product development projects. This causes additional overhead costs – which need to be agreed across the whole organization.

In addition a culture of requirement sharing needs to be established: Often product teams work in their own domain only and rarely see a need for sharing requirements or designs. So another key is to establish such openness in regards to sharing of information – supported by an IT tool that accelerates this with easy access and retrieval functions.

Also the one-time cost of establishing central requirement repositories needs to be addressed: We propose analyzing which areas of requirements are most applicable for re-use – and applying a business case in those areas. Building on that you may extend your approach to other requirement domains.

Besides these organizational questions business processes also need to be designed in regards to requirement re-use. This includes first of all a process for carrying over requirements from a library into a project. Aspects like point in time, relevant requirement maturity etc. need to be agreed. Also a process for managing changes is required: This includes a process to request, agree and release changes on shared requirements. To enhance the quality of the centralized requirements definitions a process for providing feedback from the project to the central requirement management authority is also recommended: This may present risks or opportunities in regards to requirements. Using this the requirement definition may be enhanced continuously. Potentially also subsequent processes - for instance in the area of testing - need to be considered. This is especially the case if in those areas also benefits are to be gained.

It should be emphasised that successful requirement re-use is less a matter of tools than a question of organizational set up and processes. On the other hand it needs to be said that quite a few existing requirement management tools struggle with the implementation of a referencing concept as described above.

What advantages can be gained?

There are some key benefits that can be gained during the requirement definition: This is first of all a reduction of the time and effort to create a requirement definition, essentially for new products - simply achieved by re-using existing requirement definitions. In addition the completeness of the requirement definition can be enhanced – by taking complete and consistent libraries as a reference. Also the quality of the requirement definitions could be better in a re-use scenario – assuming a continuous improvement of the centrally maintained requirements via the feedback loops mentioned above. Another advantage may be the reduction of duplicate requirement definitions: Especially for legal requirements diverse standards per country may exist that cover the same requirement but that is phrased differently. A centrally managed library for those legal standards may reduce the complexity by avoiding such duplicates.

But there are also a couple of further advantages that could be achieved: By re-using requirements in defined areas there may be an opportunity to focus on differentiating requirements essentially. This may result in products that differentiate strongly from competitor products. Also the product complexity could be re-used: By agreeing requirements across diverse products you establish the possibility of stronger modularization and therefore reduction of product complexity. Related to this there is the opportunity of accelerated solution identification: If requirements are linked to standardized solutions you may be able to accelerate your solution identification. This requires a strong synchronization of re-useable requirements and related solutions (represented via standard modules for re-use). Also there is the opportunity to reduce efforts during testing: Reducing the diversity of requirements will lead to advantages in the area of testing since test procedures and test tools can be standardized for those requirements.

Conclusion

All in all we can conclude that requirement re-use offers diverse opportunities to enhance the speed and quality of the product development process. Obviously there are some prerequisites that need to be considered before those benefits can be gained, essentially in regards to processes and organization. To achieve a good trade-off between the benefits and required investments and ongoing costs for requirement re-use the relevant clusters for requirement re-use need to be determined. Having once established a mature requirement re-use process in one area this may then offer a solid basis to expand into other clusters.