Great Products Begin With Great Requirements

Requirements Management Tools

Every quarter, I work with undergraduates who are studying Data Science, Human-Computer Interaction, Information Architecture, Information Assurance, and Cybersecurity. When asked to identify a problem and design an appropriate solution, they are quick to propose technological interventions such as new websites or mobile apps as their final projects. When pressed to explain how their projects address the problems and stakeholders’ needs they identified earlier in the quarter, they often fumble.

I repeatedly ask students to consider the following: “Why do users need this?” “What does this do, and how does it help solve your problem?” “Wait, is this really a problem? For whom?”

Understanding how a finished product relates to the problem it is intended to solve or to the needs it is intended to address is challenging not only for students, but also for many product companies.

Requirements management is the continuous and iterative process enabling stakeholders to collect, document, analyze, prioritize, and agree upon the requirements while managing changes as product development evolves. Writing requirements is one of the first steps in this process. But writing great requirements involves more than identifying a problem, having a vision, carrying out research, writing code, assembling parts, or launching new products. You must also clearly articulate how your solution will meet your target customers’ needs.

So, how do you define a great requirement?

Great requirements have a number of shared qualities, including but not limited to: clarity, completeness, testability, feasibility, compliance, and traceability.

1. Clarity. Working across interdisciplinary teams that may also be dispersed across the globe requires a dedication to clarity. Avoiding subjective terms such as “easy to use,” “quick,” or “maximize”—terms that mean different things to different people—is the cornerstone of clarity. For example, how would you operationalize “easy to use”? Does it mean the product is intuitive, accessible to users with a range of abilities, requires little to no set-up, or all of the above? Remember the goal of writing requirements is to communicate needs in an objective manner.
2.  Completeness. Writing complete requirements is dependent upon carefully articulating and understanding the problem. For example, if a group of students decides to design an app to address a problem they have defined as “being late to class,” I would ask them if their stakeholders also reported being late to interviews, dates, and/or other social events. If not, then perhaps the problem isn’t “being late to class” but rather motivation to attend class. If a requirement is incomplete because the problem is not clearly defined, the solution will be either incomplete or ineffective.
3.  Testability. Writing clear and complete requirements is the first step toward testability. The next step is to write with a test scenario in mind. For example, each time you write a requirement, ask yourself what the criteria is by which you and your team can determine success. If a requirement can’t be tested and measured objectively for success, then your team members will struggle to know whether the need has been met. Writing requirements with specific test scenarios in mind will help to ensure your product requirements are clear, complete, testable, and feasible.
4. Feasibility. To be feasible, a requirement must be viable given technical, fiscal, legal, and temporal constraints. If you are unsure whether a requirement is technically feasible, you may need to conduct user studies. To determine if a fiscal requirement is valid, you may need to conduct market research and/or ROI analysis. If your company designs technical or medical devices that may impact personal safety and security, you will also need to consider regulatory compliance issues and consult your legal team to assess risks.
5.  Compliance. For today’s product companies, regulatory and environmental compliance play critical roles in product design, development, production, and sustainability, as well as customer success. Dependent upon your industry, you may need to comply with regulatory standards ranging from those outlined by the new European Union’s General Data Protection Regulation (GDPR) to those maintained by the U.S. Food & Drug Administration (FDA) to a host of others (e.g., ISO, OSHA, UL, RoHS, REACH, conflict materials). Keeping compliance in mind as you draft your product requirements will save you time and money in the product design and development phases—and spare you and your team members unnecessary frustrations.
6.  Traceability. Traceability can be best understood as “the ability to describe and follow the life of a requirement in both a forwards and backwards direction” [i]. Considering traceability as you write each requirement will help you think through which requirements need to be linked or cross-referenced, which ones require test cases, which ones need to be mapped to design documents, and which ones directly impact your consumers. Traceability will also help you comply with regulations and industry standards such as those in the medical device industry.

If you want to reduce product issues, costs, and production delays, it’s important to have clear, objective, and measurable requirements that describe a viable product. Poorly defined requirements often drive up costs, create design and production delays, and result in poor customer adoption or satisfaction. Great products always begin with great requirements.

References

[i] Gotel, O.C.Z.; Finkelstein, C.W. “An Analysis of the Requirements Traceability Problem.”  Proceedings of IEEE International Conference on Requirements Engineering. doi:10.1109/icre.1994.292398