What Are Implicit Requirements?
Implicit requirements are features and characteristics of the product experience that customers will expect. In fact, without them, the market would view the product as incomplete.
Can you imagine a company that makes spreadsheet software releasing a product that doesn’t let users sum a column of numbers? Or a version that doesn’t allow users to save a file? Of course not. No spreadsheet maker would develop its product without including these basic features.
Thus, few product teams will even add this functionality to their list of must-haves. So that’s why we call them implicit requirements.
Where Do They Fit into Product Development?
In broad terms, we can break software product development into two types of requirements.
Explicit requirements: what the product team writes down.
Explicit requirements are the details the product team captures and shares with stakeholders. These requirements might show up in several formats, including:
- Product backlog
- Sprint backlog
- Product roadmap
- Acceptance criteria
- Wireframe
- Mockup
- Product requirements document (although these are less common in today’s era of agile product management)
Explicit requirements are where a product team captures key differentiators and competitive advantages. As a result, the company must list these requirements because they go beyond what stakeholders and users expect.
An explicit requirements list, for example, is where you’ll find a team’s plans to include features that promise customer delight.
Implicit requirements: what everyone expects and won’t need writing down.
Conversely, implicit requirements are the details that customers expect when they use the product. They are also so central to the product’s reason for being that the product team won’t need to ask the developers to include them.
Types of implicit requirements (for developing software products):
- Stability
- Privacy and security
- Features that have become expected among similar types of products
What Is an Example of an Implicit Requirement?
Imagine an enterprise SaaS company that wants to build a lead-generation form into the free version of its app.
The explicit requirement for this form will include the specific details the sales team wants to capture. Then let’s say one of these details is the user’s phone number.
Adding the phone number field would also include a few implicit requirements for the development team. For example:
- The phone number field should demand 10 digits, to capture the area code.
- Users should be able to use their phone’s native phone number keypad to fill in the field.
- Users’ phone numbers (and other personal details) need to be stored securely on the company’s servers and protected against hacking.
- The field should alert users immediately if they fail to complete the phone number field and not allow them to complete the form until they do so.
Because these are well-established best practices of mobile app form filling, they do not need to be written out or stated. They are implicit requirements.
How Do You Test for Implicit Requirements?
Software’s implicit requirements often focus on performance, such as uptime, speed, and reliability. So developing a process to test for these implicit requirements will be straightforward.
However, as the software testing community StickyMinds points out, testing for the other type of implicit requirements—the user experience details—is more challenging.
As the StickyMinds article on requirements testing explains:
“To test for implicit requirements, a tester must become an expert in the customer’s problem domain and in the technology the software uses to solve those problems.
When the software fails to match an implicit requirement, a report of that failure must also include an explanation of why a customer would expect the software to behave differently. What is the bug’s impact in terms of its effect on a customer’s experience?”