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
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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
[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