We were recently asked the following question from one of our clients:

“Our company is updating/replacing a legacy system.  The current system includes an embedded processor that was already built long ago and was developed without any requirements (at least formally defined and managed).  Given that this legacy processor has a nice set of features, management wants to use it in the new system.  Moreover, our System Engineers will have to link (trace) top level requirements to the processor requirements in order to guarantee traceability and coverage.

My issue is this – I strive to have a set of requirements that are ‘implementation free’.  However, I don’t know how to achieve this goal given that I am unsure how to write functional and performance requirements for the legacy processor  without exposing the actual implementation details of the legacy processor.

For example, the processor has a 64KB program memory, would that be a ‘requirement’? I have the impression that it is more of an outcome of a design choice that needs to meet other requirements (like application size, technology constraints, etc.).

Could some give me a feedback on this? Pointers, suggestions?”

Implementation is a common issue.  We have addressed this topic in several blogs: “Avoiding Implementation” and “How to Handle Implementation in Customer Requirements”.

Now to your issue/question which is very interesting at many levels.

The short answer?  The constraint to use the legacy processor is implementation.  We advocate that implementation be avoided in the “design-to” set of requirements and leave it up to the design team to use their expertise to define a design that will best meet the stakeholder needs and expectations as communicated via the “design-to” requirement set.

That said, as a solution to your issue, you could reverse engineer the “design-to” requirements to be consistent with the legacy processor.  These reverse engineered requirements would then be parents to which the design team can trace their processor set of “build-to” requirements.  However, for the project to be successful, you need to seriously evaluate whether or not the legacy processor is the best choice for this project.   As we all are aware, computer technology has advanced exponentially over the years and using a legacy processor may not be the best choice. 

I tell my students: “Writing requirements is not an exercise in writing, but an exercise in engineering.  Every written requirement communicates an engineering decision or choice that is being made concerning the desired functionality, performance, quality, adherence to standards and regulations, etc.”   You could write the “design-to” requirements to be consistent with the legacy processor’s features, functionally, and performance.  However, beware that while you may meet the management constraint to use the legacy processor, you may fail to meet the needs and expectations of the other stakeholders in the current and future operating environment.

The long answer?  We like to look at requirements from several perspectives.  From a technical requirements perspective, we like to make a distinction between “design-to” and “build-to” requirements.

“Design-to” requirements focus on the “what” not the “how”.  They are a result of a transformation of stakeholder needs and expectations into a language that clearly communicates the stakeholder needs and expectations to the design team.  This set of requirements, in general, should not contain implementation – where I am defining implementation here as a choice made by the design team to best meet that design-to requirement that drove that choice.  From a traceability perspective, each of the design-to requirements should trace to one or more stakeholder needs and expectations defined during scope definition.  In the design-to set of requirements, rather than having a requirement on memory size, the requirement should be on the requirements that communicate the capabilities needed (functional, performance, quality, security, interfaces, communication protocols, etc.) that drive memory size and processor performance.

“Build-to” requirements reflect the “how” design choices and communicates these to those who are actually building or coding the system.  These requirements reflect “how” the design-to “what” requirements will be met.  It is this set of requirements that would normally specify the processor to be used, and based on that processor, the amount of programmable memory, communications, speed, power, thermal, etc.  From a traceability perspective, each of the design choices should be able to be traced to one or more requirements in the “design-to” set of requirements.

Now let’s look at the overall process of developing a product.

The client said their company is updating/replacing a legacy system.   This implies that someone (internal or external) has a problem or opportunity that the current system can’t address and the client’s company is supplying a solution – the new system.

The approach we advocate in our classes is to define the scope of the project first.  You can read about this in our blog: “Baseline Your Scope Before Writing Requirements”.   An outcome of these activities will be the stakeholders needs and expectations for system capability including functionality, performance, security, etc.  These needs and expectations are what are being transformed into the “design-to” set of requirements.

These requirements are then allocated to parts of the system architecture.  Those that will be implemented via a processor will be allocated to that processor.  The design team responsible for implementing these requirements will select their choice for a processor that best meets the design-to set of requirements and include their choice in the “build-to” set of requirements.   The requirement for using the selected processor can then be traced to the “design-to” requirements that were allocated to the processor.

Now the fun begins.   There are two scenarios:

In the first scenario, design-to requirements are written to be consistent with the legacy processor’s features, functionally, and performance.  In doing this, the design team should have no problem in meeting the constraint to using the legacy processor and can trace the build-to requirement to use that processor back to the “design-to” requirements.  In reality, they have developed the build-to processor requirement first and then the parent design-to requirements have been reverse engineered to be consistent with the legacy processor.  However, like I said before, the resulting requirements may not be consistent with the needs and expectations of the stakeholders for the new system in the current and future operating environment.

What happens if the implementation of the legacy processor requirement results in a system that does not meet the stakeholder needs and expectations defined during the scope definition phase?

For the first scenario, because both sets of requirements were written assuming the legacy processor, you would pass system verification because the resulting system would meet both the design-to and build-to sets of requirements.  However, if this system does not meet the stakeholder needs and expectations and does not meet its intended purpose in its operational environment, you will fail system validation.

For the second scenario, the design-to set of requirements are written based on the knowledge you gained from the scope definition phase.  These requirements did not assume a specific processor, rather these requirements clearly reflect the needs and expectations of the stakeholders from an overall system capability, functionality, performance, quality, security, etc. perspective.

For this second scenario, it is likely the legacy processor is not able to support this set of requirements.  There are more modern processors that reflect the latest technology in terms of functionality, performance, quality, and security that would meet the design-to set of requirements.

Now management has to make a decision.  Use the legacy processor anyway?  This would mean that the new system would fail system verification, in that the resulting system does not meet the “design-to” set of requirements.  The new system would also fail system validation in that the resulting system would not meet the stakeholder needs and expectations – the system would not meet its intended purpose in its operational environment.    [For more on verification and validation, see my two-part blog “What is the difference between verification and validation?”]

To pass both system verification and system validation, management would need to remove the constraint to use the legacy processor and let the design team select a processor that would best meet the design-to set of requirements that reflect the stakeholder needs and expectations.

A parting thought

Management may feel that they will save time and money if they are able to use a legacy system.  However, in many cases, this is a myth.  The reality is that the legacy system was designed for a specific purpose and operational environment.  It is very risky to assume that the legacy system will perform as intended and needed when used for a different purpose in a different operational environment.

Thus, the second scenario is the best approach to take.   If, by chance, the legacy system will meet the design-to requirements – great!  However, if it fails to do so, management needs to accept that fact and allow the design team to select components that will me the design-to requirements.

Comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.