Understanding Design Constraints

While previous articles focused on requirements writing, another element of products requirements is design constraints.

A design constraint might not be a requirement in the purest sense, but must be accommodated in product requirements (and, ideally, identified as such). Design constraints almost always make their way into product requirements.

Let’s use a simple example whereby a specific housing material is specified (a polyester thermoplastic elastomer).

The requirement might simply be: “The housing material shall be made of a polyester thermoplastic elastomer”. The PRD is then provided to the designer, essentially telling him he must use this material.

[Read more…]

by Robert Allen Leave a Comment

Using Hierarchy In Complex System Requirements and Design

Managing requirements for complex systems can be challenging, however, establishing a hierarchical framework of key questions (answered at each layer of the hierarchy) can be quite helpful.

While some regulatory authorities (such as the FAA) may require various layers of documentation and traceability, this article isn’t necessarily advocating a bureaucratic development process. The process can be scaled based on the complexity of your system, your ability to model it’s (system) design performance and/or based on the amount of product development risk the organization is willing to assume. [Read more…]

by Robert Allen Leave a Comment

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:

[Read more…]

by Robert Allen Leave a Comment

Design Optimization Using Value Equations

Quality Function Deployment (QFD) is an excellent tool to ensure linkage of customer needs to product requirements. This article will provide a high-level overview on creating a ‘first-level’ QFD and how it can be used to guide design optimization.

(There are many additional features of QFD , however, and readers of this article are encouraged to research the methodology further.)

As stated above, we use the QFD matrix (similar to a cause-effect matrix) to ensure linkage of customer needs to product requirements using the critical thinking / questions as follows: [Read more…]

by Robert Allen Leave a Comment

When the system is the customer – system integration

In recent articles I framed the structure of a market analysis to ensure we understand customer needs and value, product requirements are “the what” the design provides (to ensure customer needs are met); the design is “the how” the product requirements will be met.

Product requirements are determined by answering the following question: “What shall the (product) design provide (output) @ input conditions? (Input conditions are functional inputs provided by the user, or environmental conditions.)

A complex product may have several outputs that interface with a system, however, and/or several inputs may be needed in order to enable the product to perform it’s intended function. System integration is therefore required.

Let’s assume your product is a subsystem. The questions become:

“What shall the subsystem design provide (output) in order to ensure optimum system performance?
“What does the subsystem need (inputs) from the system in order to ensure optimum system performance?”

How do we establish optimum system performance? We would expect the customer (system designer) would model system performance and provide functional inputs, outputs and specification limits (for your subsystem) in order to achieve optimum system performance.

In the case of a subsystem, value is in the context of the system optimization and system integration

Accordingly, subsystem integrators should understand system performance well-enough to help system designers with overall system design optimization…at the very least, understand gaps in requirements and associated system/subsystem development risks. The subsystem requirements document therefore is a key deliverable, reviewed in detail and approved by the customer.

An integrated approach to ensuring customer needs and value should be embedded in the product life cycle process, and can save your company (and your customers) millions of dollars in product development costs.

by Robert Allen Leave a Comment

Why Market Requirements Don’t Really Exist

Wouldn’t it be great if we could require the stock market to provide us 15% increases in our portfolio every year…or if we could simply require a sunny day for a picnic?

You might be familiar with the term ‘market requirements’ or a ‘market requirements document’ as a deliverable in the definition phase of a product life cycle process. To understand why market requirements don’t really exist, we must first provide the definition of a requirement. [Read more…]