Read time: 4 mins
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 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.”
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.
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.
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.
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:
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:
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.