Developing a new product: Creating functional and non-functional requirements

Read time: 4 mins

When developing a new product, the product strategy outlines the overall direction and goals for the product and the product roadmap defines the themes and timing of each release. Product requirements—both functional and non-functional—are the next level of detail that specify what will be in each release.
Product requirements help to turn the vision of a product into reality by outlining what engineers should build. They are the granular features that contribute to the larger picture.

Functional and non-functional requirements

Functional requirements

Functional requirements are features that are built to serve the products’ users. They are pieces of functionality that solve particular problems for users. An example of a functional requirement would be: “User should be able to import contacts into their mail application.”

Non-functional requirements

Non-functional requirements concern the operation of the system, such as technical requirements or other non-user-facing functionality. An example of a non-functional requirement would be: “System should support 100 users simultaneously.”

Functional requirements and user personas

When creating functional requirements, it is important to understand which user persona these requirements will benefit. Realizing that there may be different user personas for your product, naming the user persona will help provide a context for your engineers.
Note: You usually do not create requirements (or build) to fit buyer personas because, as part of their buying criteria, buyers want you to build features that satisfy users.

Identify the problem your product solves

Identifying and explaining the problem you are solving for the user might be the most important part of a requirement. This enables the engineers to understand why they are building a particular feature, and it allows them to use the root problem to identify alternative solutions. To ensure that you are truly solving the user’s problem, implement the Toyota method of repeatedly asking yourself (up to five times) why you are building that particular feature. It will help you to discover the real pain you are trying to solve and make your requirement more salient.

Example of the “why” method

• Mary (user persona) misses the bus most days going to work.
• Why?
• Mary sleeps through her alarm.
• Why?
• Mary’s alarm is not loud enough.
• Why?
• Mary is hard of hearing.

Defining “what,” not “how” when developing a product

There are many ways to solve your user’s problem. Do not tell your engineers how to solve a problem; only tell them what the solution should achieve. This will enable your engineers to develop ingenious solutions and be more motivated to find the right solution. Telling an engineer how to do his or her job is a definite de-motivator.
Using the example above, one’s first instinct may be to give the engineers a requirement to build a louder alarm clock. However, this would violate the “what, not how” guideline. Instead, by stating the problem and what you’d like the solution to achieve, you have allowed for flexibility in the solution.
Improved requirement: “Mary is hard of hearing. We need an alarm clock that will allow her to understand it is time to wake up.”
In this particular example, the engineers may choose to make a sound-based alarm clock, or they may decide on a totally different route, such as a light-based notification system. By outlining what the solution needs to achieve, it allows the engineers to think creatively to solve the problem.

Writing user stories to help create product requirements

Without being prescriptive, write user stories to outline the scenarios that the user must be able to achieve. For more effective results, provide your product testers with the user stories and user personas. They can use these stories to ensure that the delivered solution meets the user’s needs.
Ask the following questions when creating user scenarios:

• What is the user doing to cause the problem?
• What is the user trying to achieve?

Product requirements typically involve three types of user stories that cover particular scenarios

• Daily-use scenarios: These scenarios involve the user’s most frequent actions with the product (limited to two or three possibilities). Example: Mary turns off her alarm clock.

• Necessary-use scenarios: These scenarios involve the types of actions with the product that are necessary, but not performed often (for example, configuring the system, creating a report). As these do not occur as frequently as daily use scenarios, they can take more steps to execute than those used more often.Example:Mary sets her alarm clock for a change in schedule.

• Edge-case scenarios: These scenarios rarely occur in real-life situations, but are of some concern for engineers. It might be difficult to create these types of situations, as virtually all users will never encounter them. Example: Mary decides to change the alarm settings and the power goes out.

Note: Refer to the article, Product requirements template for examples of each element of a requirement. For other information on product requirements, refer to the additional four articles in this series:

• Validating product requirements
• Prioritizing product requirements
• Understanding the cost of product requirements
• Determining the product release

---

Summary: Two types of product requirements, functional and non-functional, detail what a product release will contain and tell engineers what to build.

---

References

Cooper, A. (1999). The Inmates are Running the Asylum. Sams Publishing.
Date, C.J. (2000). What Not How: The Business Rules Approach to Application Development. Upper Saddle River, New Jersey: Addison-Wesley Professional.
Ohno, T. (1988). Toyota production system: beyond large-scale production. Portland, OR: Productivity Press.
Johnson, S. (2009). Writing the Market Requirements Document. Pragmatic Marketing website. Retrieved July 19, 2010, from http://www.pragmaticmarketing.com/publications/topics/01/0104sj
Wiegers, K. (2003). Software Requirements (2nd ed.). Microsoft Press.