Emphasizing Product Requirements

In this article we’ll explore the topic of requirements, and attitudes about identifying requirements before the design work begins.

In my experience, I’ve had design resources literally state “I hope there are no requirements”.  (Unconstrained design and no requirements certainly made this designer’s job much easier.)

There are several other reasons requirements are sometimes neglected:

• Writing and determining requirements isn’t as fun, rewarding or creative as design work.
• Engineers may not know the basics of writing good requirements.
• We often do not know specific product performance levels (specification limits), and would rather focus on what we know rather than what we don’t.
• A good design is easily envisioned and gets much more (favorable) attention than great requirements (which is dry documentation).
• Requirements establish accountability for product performance.  (No requirements, or ambiguous requirements therefore implies less accountability.)

How do we address this?

Leadership, governance and management can emphasize requirements management to enable a competitive advantage

Complete, unambiguous and validated requirements can be emphasized as a critical-to-quality characteristic in the product life cycle process.  Requirements can be seen as a valuable tool in the product development process to ensure customer needs are met, as well as contributing to test planning and procedures.

Other details of requirements management:

• Include requirements reviews (in addition to design reviews) in the product life cycle (PLC) process.  Also, ensure requirements are controlled documents with releases based on peer review (similar to drawings).  For complex systems a requirements management database is encouraged.
• In addition to using requirements to clarify what we know, also encourage and identify things we don’t know…even use “TBDs” as placeholders in the document.  Identification of TBDs are a good thing, and represent identified requirement risks and potential actions for risk mitigation.
• Establish a requirements writing and validation process owner. The term “systems engineer” has taken on several meanings.  However, it can be best described as the resource who manages the ‘technical leg’ of the project management process.  The International Council on Systems Engineering (INCOSE) is a great resource for this. https://www.incose.org/

Superior requirements, and requirements management, can ensure a competitive product, as well as a lower-cost and lower-risk product development process.