6
Product Requirements and Constraints
Product development is a process in which the perceived need for a product leads to the definition of requirements that are translated into a design. The definition of requirements is directly derived from the needs of the market and the constraints in producing the product.
6.1 Defining Requirements
One of the first steps in product development is the process of transforming broad goals and vague concepts into realizable, concrete requirements. While the company's core competencies, cultures, goals, and customers all influence the requirements, Figure 6.1 shows that the product definition results from a combination of marketing and business-driven product requirements, design and manufacturing constraints, and various external influences.
Marketing often takes the lead in determining requirements for products such as toys, cell phones, and personal computers. For components of more complex products (e.g., an engine control module for an automobile), the requirements and constraints are often defined by the customer (the manufacturer of the product or system that the component fits into), and the marketing function is less involved.
The development of product specifications begins with an initial set of objectives, which are formulated into a preliminary requirements document. These should be approved by many people, ranging from engineers to corporate management to customers (the actual people involved in the approval depends on the company and the product). Once the requirements are approved, engineering typically prepares a specification indicating the exact set of requirements that are “of value” to implement.
Design decisions are a balance of all the requirements, as per the final specifications for the product. The design may be adjusted to reduce cost or to improve such attributes as ergonomics, safety, performance, quality, and reliability.
The cost and ease of product support may also factor into product requirements to improve maintenance and accessibility to spares, support equipment, and personnel who can test and repair the product. A poor definition of requirements will often lead to a poor design, for example, where the air conditioning compressor of a car has to be removed to replace a spark plug or special tools are necessary to replace the oil in a car.
6.2 Responsibilities of the Supply Chain
The IEEE Reliability Program Standard 1332 (IEEE Std. 1332–1998) presents the relationship between the component suppliers and customers in terms of reliability objectives. The standard identifies three such objectives. First, the supplier, working with the customer, must determine and understand the customer's requirements and product needs, so that a comprehensive design specification can be generated. Second, the supplier must structure and follow a series of engineering activities to insure that the resulting product satisfies the customer's requirements and product needs with regard to product reliability. Third, the supplier must include activities that assure the customer that the reliability requirements and product needs have been satisfied.
6.2.1 Multiple-Customer Products
For commercial products, requirements are often defined by technical marketing groups. To define the product requirements, these groups use information from diverse sources, including sales personnel from previous or similar product groups, market focus groups, market research and customer surveys, analysis of the competition, corporate objectives, industry standards and agreements, and product roadmaps and trends. The objective of defining requirements is to maximize profit by appealing to the largest possible customer base.
Business goals must also justify the creation of the product. Business goals that might be considered include creating a product that:
- Fills a Perceived Market Need. A new product may be defined and produced because a compelling business case can be made that there is a market for the product that can be tapped.
- Opens New Markets. A new product may be defined and produced (possibly at a financial loss) to facilitate the company's entry into a new market that it considers to be strategic and/or believes can be created for the product.
- Keeps the Company Competitive in a Key Market (Maintaining Market Share). A new product may be needed to maintain competitiveness in a market that the company considers important. For example, in the cellular phone market, companies must continuously define and create more advanced phones if they want to maintain market share. Skipping a generation of phones may cause a loss of market share that can never be recovered.
- Fills a Need of Specific Strategic Customers. Many companies tailor their business decisions to the needs of a few influential customers (or a key market segment). Product requirements may be defined solely to satisfy one customer's needs, either because the customer is viewed as a leader in its marketplace or because that customer has a large enough demand for the product to justify making the product.
- Improves Maintainability/Extensibility and Cost of an Existing Product. Redesigning or modifying a product may increase profit margins or competitiveness by reducing the cost of producing, supporting, or extending its life.
6.2.2 Single-Customer Products
Many low volume and specialty applications effectively have only a single customer who predefines the product's requirements. Delivering products with these requirements at the lowest life-cycle cost, and/or strategically exceeding the minimum requirements, gains the customer's business. For single-customer products, the requirements and constraints are determined from customer definitions, analysis of the competition, and technology roadmaps and trends. The business reasons that justify the creation of the product include:
- Maintaining Market Share and Customer Confidence. Just as with commercial products, a new product may be needed to remain competitive in a market or with a customer that the company considers important. A new product may also be important to retain the customer's confidence that the company is a long-term partner and a legitimate competitor in a strategic area.
- Demonstrating Experience with a New Technology or Methodology. In the single-customer market, customers are often influenced by prior experience with cutting- edge and niche technologies. Continued demonstration of the ability to integrate these techniques maintains customer confidence.
- Reducing Life-Cycle Costs of an Existing Product. For single-customer products, the manufacturing cost of the product may not be as important as the costs of product sustainment (support, maintenance, and upgrade). Product redesigns or modifications for reducing the life-cycle costs are often important to the customer.
6.2.3 Custom Products
Some low volume commercial products and “modular” single-customer products do not fit into either of the categories defined earlier. These are products that are designed with a minimum set of “generic” requirements and then customized using each customer's specific requirements. Examples include supercomputers, military equipment (used across multiple Army, Navy, and Air Force platforms), and corporate Intranets. For these types of products, the guidelines defined above are still relevant. Reconfigurability with platform compatibility and upgradeability may be the salient features of these designs.
6.3 The Requirements Document
The actual content of the requirements document will depend on the application; however, the requirements and constraints fall into the general categories shown in Table 6.1. In addition to defining values for the requirements listed in Table 6.1, the requirements document may also assign a priority to each requirement. Table 6.2 provides three grades often used to prioritize requirements. Schedule and cost might not be included in the requirements document for some products if the document is released to other internal or external organizations for bids.
Table 6.1 Example of product requirements
| Requirement and/or constraint | Definition |
|---|---|
Physical attributes:
| Describes the physical size, shape, and weight of the final product. |
| Functionality | Describes what the product does, including the various features. |
Performance
| Describes the characteristics of operation of the product. |
Environmental conditions
| Defines the environment conditions within which the product must be constrained to operate properly. |
Reliability
| The ability of a product or system to perform as intended (i.e., without failure and within specified performance limits) for a specified time, in its life-cycle conditions. |
Cost/quality
| Defines the yield of the resulting product and the cost to field a tested product. |
Qualification
| Defines how and under what conditions the product's reliability will be assessed. |
Schedule
| Defines when the first product needs to be delivered to customers and what volume needs to be delivered over the lifetime of the product. |
Life cycle
| Defines the ease with which the product can be maintained and upgraded during its fielded life. |
End of life
| Defines what happens to the product after the customer is finished using it; also defines whether any end-of-life requirements exist, depending on legislation where the product is sold. |
| Safety and regulatory | Defines requirements related to customer safety and necessary approvals from legislatures, government agencies, and industry bodies. |
Table 6.2 Requirements grading
| Grade | Definition |
|---|---|
| Must (shall) | The requirement is essential to the viability of the product. |
| Should | The requirement is not essential to the viability of the product, but it should be implemented either because it adds great value or because it can be easily implemented, to add value. |
| Could | The requirement is not essential to the viability of the product, and its development could be delayed either because the requirement is too costly to implement or because it adds only marginal value to the product. |
The inclusion of irrelevant requirements can lead to unnecessary expenditures and time for design and testing. Irrelevant or erroneous requirements result from two sources: personnel who do not understand the constraints and opportunities implicit in the product definition, and including requirements for historical reasons. The latter get “cut and pasted” into requirements documents from a previous product. No one knows exactly why the requirement is included, but no one is brave enough to remove it, simply because no one takes the time to see the obvious mistake or to question the norm.
The omission of critical requirements may cause the product not to be functional or may significantly reduce the effectiveness and appeal of the product by not providing the necessary attributes. This may reduce the market size of the product and delay the product launch, shrinking the time window for achieving return on investment.
A single person cannot realistically define all product requirements for a product. To make the requirements realistic and useful, personnel from different disciplines (see Table 6.3) should contribute to, review, and approve the product requirements.
Table 6.3 Example of requirements buy-in for a multiple-customer product
| Role | Approval level |
|---|---|
| Marketing | Approval authority |
| Engineering manager | Approval authority |
| Product manager | Approval authority |
| Role | Buy-in level |
| Development engineers | Consulted prior to approval |
| Reliability engineers | Consulted prior to approval |
| Customer | Consulted prior to approval |
| Application engineers | Consulted prior to approval |
| Quality assurance | Informed after approval |
| Corporate management | Informed after approval |
6.4 Specifications
Once a set of requirements has been completed, product engineering creates a response to the requirements in the form of a specification. The specification states:
- The Requirements That Must Be Met. The fact that a requirement appears in a requirements document does not guarantee that it will be achieved in the final product. Technical marketing does not always understand what can be successfully engineered within a specified time window. Requirements grading defines the priorities during specification development.
- The Methods by Which the Requirements Will Be Met. This requires an outline of the basic process used to meet the requirements. The outline may consist of flowcharts, block diagrams, manufacturing processes, and possible parts lists and physical resources, such as specialized requirements.
- The Schedule for Meeting the Requirements. The design, prototype, procurement, and manufacturing schedules for the product are identified. Proposed schedules for contract manufacturers may also be included.
- An Identification of Those Who Will Perform the Work. The specific persons who will perform the work may be identified. In addition, groups within the company that perform specific functions necessary to fabricate the product, and all contract manufacturers from outside the company, should also be identified.
- An Identification of the Potential Risks. If any specific design, development, or manufacturing risks are known, they should be stated in this document. Possible second sources of components and services and backup plans should also be identified.
6.5 Requirements Tracking
Once product requirements are defined and the design process begins, the process of continuously comparing the product's requirements to the actual product design begins. As the product's design becomes increasingly detailed through selection of components and implementation strategies, it becomes increasingly important to track the product's characteristics (e.g., size, weight, performance, functionality, reliability, and cost) in relation to the original product requirements. The rationale for making changes should be documented and approved.
The completeness with which requirements tracking is performed can significantly reduce future product redesign costs. Planned redesigns or design refreshes through technology monitoring, and use of roadmaps ensure that a company is able to market new products or redesigned versions of old products in a timely, effective manner to retain its customer base and ensure continued profits.
6.6 Summary
Product requirements are usually defined by technical marketing groups and then reviewed and enhanced by other disciplines in the company. The product engineering function creates a response to the product requirements in the form of a preliminary specification that defines what requirements will be implemented, who will perform the work, how the work will be performed, and a schedule. Requirements are tracked to ensure that the product remains in compliance as it is developed.
Two prevalent risks in requirements and constraints definition are the inclusion of irrelevant requirements and the omission of relevant requirements. The inclusion of irrelevant requirements can involve unnecessary design and testing time as well as money. Irrelevant or erroneous requirements generally result from two sources: requirements created by personnel who do not understand the constraints and opportunities implicit in the product definition, and including requirements for historical reasons. The omission of critical requirements can significantly reduce the effectiveness of the product.
Problems
6.1 Using the example of a cellular phone, develop a list of requirements for a business application.
6.2 Classify the list of requirements in question 1 to “must,” “could,” and “should” categories. Follow the template in Table 6.2. You can add additional rows with justification.
6.3 Give three examples each of (a) multiple-customer products, (b) single-customer products, and (c) custom products.
6.4 Provide an example of an electronic product for which compatibility with another manufacturer's product, such as an Apple iPod, is an essential requirement. Explain how the product requirements could be specified to differentiate your offering from those of similar, competing products. Describe the constraints imposed by the compatibility requirement.
List the appropriate sources of input for this product's requirements and explain the value of each source.