Your Reliability Engineering Professional Development Site
In this article, we’ll compare and contrast the definition of a requirement, with a ‘story’, which is used in agile/scrum.
The framework for each is somewhat different, however.
Recall the definition of a requirement:
…a requirement defines “what the product (or process) design shall provide <output> at operating conditions <input>”
The framework of a story is as follows:
Many companies pursue a product development strategy that provides a product (or service) which meets customer needs sooner (rather than later), and then makes adjustments after the product has been fielded.
Pursuing this approach means accepting the associated risks. What if a critical to quality or critical to reliability characteristic fails to meet customer needs? A product could fail miserably by eliminating important product development work scope and accelerating time-to-market. By the time an adjustment or “pivot” can be made it may be too late, or too costly to correct.
In my last article, we reviewed a proposed Product Life Cycle process, which starts with a “Define” phase. In the “Define” phase, we are defining the project as well as the product.
We previously discussed the ‘technical leg’ of this process with the market analysis, identifying customer needs, product requirements, verification and validation, etc. [Read more…]
One of several reasons for emphasizing product requirements includes enabling modeling and simulations of designs, as well as ensuring adequate verification and validation testing.
Recall the fundamental framing of a requirement as:
Note the framing (within the requirement) of a mathematical and/or experimental relationship where “Y” is the output as a function of “(x)” as the input….Y = f(x) or as a function of multiple inputs Y = f (x1, x2, x3…xn). Let’s expand on this for a moment:
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.
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…]
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:
Significant savings in product development costs can be realized with robust validation processes, starting with requirements validation. Validation confirms the product meets customer needs for the products intended use, and answers the question “are we designing the right product?” The “right product” therefore starts with the “right” product requirements. Even a product designed with detailed requirements, but incorrect specification limits, can be considered the “wrong product” (since the product would be rejected by the customer.) [Read more…]
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…]
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:
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.
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.
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…]
Customers want the benefits created by your product. They want the time savings, the reduced yield loss, they want simplicity, coolness, speed, etc.
Customers buy your product to solve a problem, they do not buy it to simply enjoy the features. The features have to do something of value. They have to provide a benefit.
If your product fails, the feature doesn’t work. Customers do not realize the benefit they expected.
In short, your customer wants your product to work as expected. When asked a customer will tell you they do not want to have product failures. [Read more…]
The Quality Triangle provides a method to establish priorities for a project. It strives to balance time, cost, and quality (or scope instead of quality). It does not include reliability.
Now I am a bit bias as a reliability engineer and believe a projects set of priorities should explicitly include reliability performance. Of course, there are many potential priorities, yet reliability certainly can make or break a product, it’s market acceptance, and an organization’s profitability.
So, given a quality triangle based set of priorities, how does reliability fit in? [Read more…]
Guest Post by Paul Kostek (first posted on CERM ® RISK INSIGHTS – reposted here with permission)
One of the keys to a successful project is having a set of requirements that are well defined and stable. We’ve all worked on projects where a lack of defined and controlled requirements has led to scope creep which result in schedule delays.
The requirements development process must also include mitigations for the risks identified in the Risk Management Plan. To accomplish this the initial risk assessment must be completed before the requirements development process begins. [Read more…]
Customers of your product would like the particular one they have to work. To work over time.
If a product meets the customer’s expectation by working as long or longer than they expected it to do so, then they may consider your product reliable.
We use reliability goals to discuss the customer’s reliability expectations. It is the establishment of requirements that converts the customer expectations to development and production obligations. [Read more…]