Requirements originating from standards are a common challenge for most industries, all the way from heavy machinery to delicate medical devices and even to pure software development. There is no way of avoiding the burden of studying how those requirements have to be fulfilled in each project, but it is possible to give a good kick-start for this work by reusing the documented standard requirements from previous projects.
Standard requirement reuse has few indisputable advantages:
– Cost Savings – If the work can be done only once, there is no sense wasting time and effort doing it all over again in each project
– Requirement quality and coverage – As you iterate the requirements derived from standards over time you ensure the requirements are perfected and taken into account exactly the right way for your projects
– Prepare for standard compliance audits – Each project provides comparable reports for auditing and proving end-to-end traceability
– Synchronize changes – Changes to existing standards can be communicated efficiently
The more projects you have, more value you gain from requirements reuse.
Deriving requirements from standards
Requirements are needed because they are the basis for all product development, project management and testing. They define product content and scope, describe what (and how) customers and product users need, and also their fundamental motivation why (benefit, delight). Studies show that up to 85 % of project failures are due to incorrect requirements, so it is easy to argue why put effort on proper requirement definition.
But why it is important to document individual requirements from standards, isn’t it enough that we have the standard document to guide the development? It is important for accomplishing traceability between different artifacts, which is a fundamental requirement in most safety and quality standards. Standard document should always be refined into a set of good quality requirements and related test cases, that cover the whole standard. These artifacts can then be reused in all relevant projects, which significantly reduces the individual effort spent on requirement management and fulfilment of standards in each project. It also enables common metrics and reports for each project, and makes preparing to compliance audits much easier.
In a future article we give some good hints and tips for how to create your standard requirements asset in practice.
Central requirement database
Typically there are several different standards your projects need to deal with. To avoid hassle and mistakes, it needs to be very straighforward where they can get the latest versions of the requirements and test cases for each standard when the project starts. Easiest way to do this is to create a central requirement database, which in time evolves to a common standard requirement asset. To keep your asset valuable, it needs to have a clear owner and process for changes. Projects must be able to trust that the repository contains only relevant, up-to-date artifacts, otherwise it has no value for them. If the project needs to spend great deal of time evaluating the quality of the asset, the benefit of reuse is quickly lost.
In the same way, there should be a clear ownership for standard related reporting across all projects, instead of creating the metrics separately in each project. Organization who owns the reporting, should push the projects to keep compliance to the standard, for example by ensuring the end-to-end traceability. Quality organization is quite natural selection for this responsibility.
What happens when standards change?
When a standard changes, the asset needs to be updated and the changes communicated to the projects. Projects will then evaluate if the change is relevant for them and act accordingly. Without a well-defined process and responsibilities this will not work and in the worst case some project will miss a change that is required for the product approval by authorities. To prevent this from happening, make sure that there are dedicated parties to
1. Follow-up the standard evolution
2. Update the requirement asset per standard when changes occur
3. Communicate the changes to the projects
It cannot be emphasized enough that the central database containing the requirement asset must always be the authority in what comes to the standard requirements. Projects copy standard requirements only from the database, not from other projects. This ensures not only the quality of the data, but using the right tooling it also enables the automatic communication of changes and tracing of the projects that use the data.
How to get started?
Start small and figure out what is the best way of doing the reuse for your company step-by-step. Spend minimum effort by selecting just one or two projects and one standard to pilot how it could work, and change the approach if needed after the first results. Record the time saving in pilot projects to measure whether the centralized model is more cost effective. If there are very few and long projects, it might be that the reuse is not the best solution for such company. But as mentioned earlier, more projects the company has, more benefits this approach has.
Interested in learning more?
Let’s have a 1-hour online demo where we can show you a solution how to do this in practice!
Just send us your email address and we’ll get back to you.