Characteristics of Good Requirements

November 4, 2015 - Rebecca Haag, Systems Engineer II ; and Gary Seim, Principal Systems Engineer, Retired

When designing medical devices, overall project success is typically measured using a combination of three metrics – whether the project was 1) completed on time; 2) on budget; and 3) delivered the expected result. The requirements definition process has the potential to impact all of these metrics. This paper will explore the importance of good design requirements, Minnetronix’ philosophy on design requirements, and the risks involved in utilizing poor design requirements.

Importance of Good Requirements:

The importance of good requirements may not be obvious at first glance and, indeed, even the purpose of requirements can be rather opaque. Requirements represent a translation of customer needs or wants into a contract that designers and verifiers can follow in the development of the product. By creating a requirements hierarchy, the functions and qualities necessary in a system are agreed to with key project stakeholders and documented for use further downstream in the development process. It is important to remember that project stakeholders include individuals other than the end user and the design team – for instance, regulatory bodies, marketing, manufacturing, maintenance, etc. Documenting good requirements early in the process, helps to ensure the project stays on track and delivers the expected and agreed upon result.

Risks of Utilizing Poor Requirements:

If the requirements do not fully capture all functions and qualities of the system, project change will result as additional necessary functionality is identified during development, directly impacting project schedule and budget. If the functions and qualities remain uncaptured within the requirements, the final delivered system could fail to fulfill the customer expectations or user needs. If the requirements written are ambiguous or open to interpretation, delays in development and verification can result while rework effort is pursued to clarify the intent of the ambiguous requirements. All of this underscores the importance of ensuring that the agreed upon set of requirements is comprehensive, unambiguous and verifiable.

Minnetronix’ Philosophy on Good Requirements:

Creating a set of good requirements may not be as easy in practice as in theory. The objective is to establish a cascade, or set of requirements, from business/user needs to system and subsystem requirements. This requires a special ability to translate customer terms into engineering terms. A big part of that translation is the ability to listen and understand what is driving customer expectations.

Minnetronix’ systems engineers are experienced in the creation of requirements and can help to ensure they are written to be useful throughout the development process. In order to do this, the requirements need to be understandable from the points of view of the user/customer organization, the design team, and the verification team. By utilizing engineers with experience in requirements elicitation, creation, and management, the overhead associated with developing and maintaining a requirements cascade can be greatly reduced.

The following is a discussion of characteristics of good requirements and why each characteristic is important.

  • Unique and singular: Each requirement should state a single capability or quality that the system needs to have. The inclusion of multiple capabilities or qualities within one requirements statement adds complexity and increases the risk that a requirement will be overlooked in the design and/or verification process.
  • Necessary: Each requirement included should define an essential characteristic of the system. The inclusion of additional, unnecessary requirements adds effort, cost, and risk to the project. This additional effort is non-value added to the completion of a working system which meets stakeholder needs.
  • Unambiguous: Each requirement should be written in a clear and understandable manner. To clarify intent, it may be necessary to include discussion or rationale around the stated requirement. If requirements are ambiguous, discrepancies may arise between the interpretations of the user/customer organization, the designers, and the testers. These discrepancies may be caught at any point during the development process; however, correcting these issues later on in the project is exponentially more difficult and costly than at the requirements definition stage.
  • Verifiable: Each requirement should be able to be measured or otherwise evaluated for whether or not it has been implemented sufficiently. Verification is the process of proving that the system has been built correctly – that it has met the requirements. In order to successfully accomplish this task, requirements need to be measurable through inspection, analysis, demonstration or test. As part of ensuring a requirement is verifiable, it is preferred to write the requirement statement in positive terms, as it is easier to prove a system can do something or has a characteristic than to prove it can’t or doesn’t. To make sure requirements are verifiable, it is useful to start thinking as early as possible within the requirements elicitation process about how the requirement will be tested.

In addition to characteristics of individual requirements, a good set of requirements will also meet certain criteria.

  • Complete: The requirement set should, together, describe all of the necessary behaviors, capabilities and qualities of the system. If a capability is left out of the requirements, no matter how basic or essential, it may not get implemented or verified. The requirement set is the ultimate set of documentation against which the rest of the development process is carried out.
  • Consistent: Each requirement within a requirement set should be consistent with the rest of the set. No two requirements should conflict with any other. Additionally, it is important to make sure that the language used within the requirement set is consistent (e.g. that system component names are used the same way throughout the documentation).

These characteristics should be utilized as review criteria during requirements reviews throughout the design process.

Summary:

Requirements are an essential step in the medical device development process. Good requirements have the potential to greatly improve the chances for a positive project outcome with respect to schedule, budget and quality output. The experienced Systems Engineering team at Minnetronix can help make sure that the requirements written meet all of the characteristics of good requirements. While the natural inclination of product development teams is to dive head first into developing a product, it is important to restrain the team and spend time up front to fully document the expectations for the system. By doing this, project outcomes can be greatly improved, and both the customer and designing organization can be confident that the project scope is understood, everyone within the involved organizations is driving towards the same set of blueprints, and the ensuing effort will result in a device that meets expectations.

References: INCOSE Guide for Writing Requirements