Use case — the case made for how a user interacts with a product or system — is essential to the broader product development process. But the path to building a reliable use case depends on something more fundamental: establishing product requirements.
At Pivot International, we’re a single-source global product design, development, and manufacturing firm with specialized experience in determining the minimum viable products to refine ambiguous requirements. With nearly 50 years of expertise across fourteen industries, we deliver the technical diversity and know-how to help our clients move from viable use case solutions to optimal ones.
In this piece, we’ll first explain why it makes sense to look at product requirements separately from the use case. Then, we’ll provide a brief overview of the two types of product requirements. Lastly, we’ll provide ten questions to help you assess your product requirements.
Why Develop a Product Requirement List Separate From Use Case?
Beginning with a product requirements list that is distinct from use case enhances traceability. This is essential for ensuring that each identified requirement is tied to business needs and is incorporated in the broader product development process. In other words, use cases can certainly be crafted that capture all requirements, but many lend themselves to being considered separately.
Two Types of Product Requirements
Product requirements fall into functional and non-functional categories. (Either of which can be ambiguous — open to interpretation and therefore optimized to use in various ways.)
Functional Requirements
As the term suggests, functional requirements focus primarily on how a product works and performs. It also defines its parameters, scope, and interface with relevant technologies. (At Pivot, because many of the products we develop depend on multiple technologies – wifi, cellular, Bluetooth, and so forth – ensuring compatibility between them is vital.) Examples of functional requirements include assessments related to SWAP-c challenges. (Challenges related to product size, weight, power, and cost ratios.)
Non-Functional Requirements (NFRs)
Non-functional requirements focus less on how a product works and performs and more on how it looks, feels, and is experienced by the end-user within the product ecosystem and operating environment. Non-Functional requirements also consider what is required to maintain a product and examine potential security issues related to its use.
Non-functional requirements also factor in the regulatory standards set for any given industry and product category. (This is why selecting a partner with the necessary certifications is mandatory for ensuring quality and achieving regulatory compliance.) They also include cultural and political considerations.
For all these reasons and more, NFRs are not incidental but rather serve to strategically constrain development and limit design options. (Which paradoxically serves to fuel rather than hinder innovation.)
Ten Questions for Assessing Your Product Requirements
Now that we’ve explored the difference between functional and non-functional requirements, let’s cover ten questions to ensure your bases are well covered.
1. Are the product requirements bounded? (Are they contextualized within the product ecosystem and operating environment?)
2. Are they accurate? (Do they correctly describe the product in question using detailed specifications?)
3. Are they complete? (Do they describe product criteria in comprehensive terms?)
4. Are they coherent? (Do any of the sub-requirements run counter to each other?)
5. Are they realistic? (Is it possible to create this product in light of technology and manufacturing limitations or supply chain challenges?)
6. Are they necessary? (Are these requirements truly non-negotiable, or can they be dispensed with?)
7. Are they ambiguous? (Can they be interpreted in more than one way or satisfied with any number of solutions?)
8. Are they prioritized? (Have they been scaled from most to least important?)
9. Are they verifiable? (Do reasonable metrics exist for assessing and testing them?)
10. Are they validated by all stakeholders? (Are stakeholders in agreement about answers to the previous nine questions?)
Moving Closer Toward Use Case
Use case begins where satisfying your product requirements ends, so you can now start applying the insights you’ve gained to this next step in the process. (To learn more about use case creation, read this piece describing Pivot’s approach to developing optimal solutions for use case challenges.)
Are you gearing up to begin NPD? Pivot is the partner you’ve been looking for! With local roots and global reach, an internationally award-winning product portfolio that spans multiple markets, and a proven track record of success, we’ll work closely with your team to make your product vision a profitable market reality. Contact us today to learn more!
