Writing requirements is not a mysterious black art although it may sometimes seem that way. Requirements convey details of a customer’s problem to the reader (usually a designer or developer). A requirement reveals the information necessary to create an innovative solution to the problem, perhaps in ways not anticipated by either the requirement’s writer or the associated end-user. Understanding the market is the first step in creating innovative products. The collection of market requirements is the body of what’s often called a “Market Requirements Document.
The Five Steps of Innovation
Successful organizations use five steps for developing innovative products:
- Find a problem
- Analyze it
- Design an innovative solution
- Code to the design
- Test the result
Sadly, these steps are not always followed. Many product managers fail to communicate lucid requirements grounded in the market; too few developers analyze the problem and design an innovative solution. Yet successful technology organizations routinely and consistently follow all five steps.
Alan Cooper, in his book The Inmates are Running the Asylum, says most technical products aren’t designed for the user; they’re designed for the developer. Or worse, they’re not designed at all. Poorly designed products frustrate customers.
Whether using traditional methods or agile ones, we need to understand the problem before building a feature. You’ll need a design before you begin building. Agile methodologies aren’t just about coding; agile teams learn to move through the five steps of innovation quickly and efficiently, usually completing an entire development cycle in a few weeks.
In many organizations, the product management function is ill-defined. Ideally, a product manager finds problems in the marketplace and conveys them to a Development or Engineering organization. When product managers (sometimes called product owners) are also competent in development areas, they’re often recruited to assist in other areas of product development. Since many come from a technical background, they have a natural tendency to work on activities they enjoy and where they have skills, even though these activities are not product management responsibilities. As a result, product managers are often overwhelmed with tactical, technical activities that tie them to their desks; activities that prevent them from spending time in the market. For more on the role, see The Strategic Role of Product Management e-book.
A product manager owns the first step in creating innovative products: finding market problems. These are communicated to Development in the form of requirements—the problems to be solved. The remaining steps of innovation are owned by the Development or Engineering departments. A product architect or designer controls the middle steps (analysis and high-level design) with a team lead in charge of the detailed design, coding and testing. If there is no designer, then analysis and design falls to the Development team. Another critical role is QA. The quality assurance lead is responsible for both internal and external testing. That’s why QA should head up the alpha and beta testing projects. The QA lead validates that the specifications (written by Development) address the problems articulated in the requirements (written by product management) and then tests the result to ensure the requirement is met; this verification role is more effective than merely attempting to “break the code” in clever ways.
So the functions (and roles) are:
- Find a problem (product manager)
- Analyze it (product architect or designer)
- Design a solution (product architect or designer)
- Code (developer)
- Test (QA lead)
Nowadays, we see personas and problems increasingly used as the primary method of defining complex projects, with an associated reduction in the old “reqs and specs” approach. An emphasis on personas and their problems focuses the team on the final result, rather than the tedious implementation of individual features. This approach requires more analysis and design by Development, making it more attractive to competent development organizations.
At Pragmatic Institute, we have long been advocates of personas, both for the users of the product as well as for buyers. Buyers have one set of requirements; users have another. And for most technology products, the buyers and users are different people in the organization. A buyer persona is involved in the purchase of the product; a user persona actually uses the product. The buyer persona is concerned with value while a user persona is more concerned with capabilities. A persona defines an archetype of the buyer or user of your product with a biography that includes context to guide the team. For example, knowing a typical customer—a user persona—is adept at spreadsheets suggests we don’t need a report writer but can implement an export capability instead.
Personas have problems. Stated in the context of a specific persona, a problem represents a situation that our product should be able to address. Problems are specific situations that can be clearly expressed.
The persona definitions and the list of their problems are the basis of the Market Requirements Document (MRD). MRD articulates the new product or new release plan. Some companies call this document a Product Requirements Document (PRD). Some organizations have both an MRD and a PRD but then struggle to define which is which and what each should contain.
Let’s keep it simple:
A business plan defines the overall product opportunity with a financial plan; a requirements document defines the next version or model of a product with a list of problems to be solved.
Do we really need more documents than this?
Traditional Requirements
According to the IEEE definition, a requirement is a statement identifying a capability, physical characteristic, or quality factor that bounds a product or process problem for which a solution will be pursued.
Focus on the ending phrase: Requirements state a “problem for which a solution will be pursued.
Traditional requirements are categorized into these five types:
- Functional. Observable capabilities that must be present for the persona to complete their goals or perform the task specified by the use scenario
- Performance. Characteristics of capacity, speed, concurrency
- Constraints. Conditions that legitimately limit the design
- Interface. Defined interaction with hardware and software components
- Security. Compliance with government mandate and customer privacy
Software vendors may also need to consider these unofficial types of requirements (not recognized by IEEE). For example:
- Standardization
- Certification
- Installation
- Implementation
- Customization
- Localization
- Documentation
- Education
Alas, we often see this traditional approach implemented poorly, combining the requirement with a specification; a statement of the problem as well as a proposed solution to the problem. Clearly the IEEE standard requires these to stay separate.
However, these types of requirements remind us to look beyond problems that result in a feature (functional requirements) to include problems that impact performance, installation, customization, and so on (non-functional requirements). Whatever form you use, be sure to convey the parameters of the problem.
Today’s requirements are written in the words of the persona, in business or personal terms, rather than offering a technical definition. A requirement should be short, only one or two paragraphs, never more than a page or two.
The key: Product managers write requirements to document the problem without a recommended solution to the problem. The Market Requirements Document combines the many requirements into a coherent whole. For a new product, a requirement states a business problem the potential customer is having that will be addressed; for an existing product, the requirement might instead document a usage problem for existing customers.
Characteristics of a Good Requirement
A good requirement conveys the context of the problem. How do you know you’ve done it right?
There are a few ways to evaluate your requirement before you get it in front of a team of designers. One method is SMART, which stands for:
- Specific. Requirements should specify what they are to achieve.
- Measurable. The requirements should provide a metric whereby all stakeholders can determine if the objectives are being met.
- Achievable. Are the requirements’ objectives achievable and attainable?
- Realistic. Are the requirements realistic with respect to the available resources?
- Time-Bound. When is the team to achieve the requirements’ objectives?
The trick of writing good requirements is to convey the critical information in a form that developers and designers can embrace — enough detail to provide context without too much detail that overwhelms the reader. A well-written requirement helps the designer make judgment decisions without turning to the product manager continually throughout the day. Ask yourself: When an implementation question arises, have I provided adequate context? Can the designer imagine the appropriate solution? And for that matter, ask your team: “Have I communicated clearly?”
Requirements That Work
The story approach to writing requirements often works to everyone’s advantage. “Tell me a story. What is happening? What is the persona trying to achieve?”
There are many formats and definitions for stories. Some call them use cases; others call them user stories. Our preferred format is a use scenario, taught in our Build course:
[Persona] has [problem] with [frequency]
For example, Sarah the college student needs to pay her tuition each semester using multiple credit cards.
“Sarah” is the persona, “pay tuition” is the problem, and “each semester” reveals the frequency of the problem. And notice this problem is absent a proposed solution; that’s up to the people doing the design.
Stories are powerful. You put the designer in the customer’s chair, seeing the problem from the customer’s point of view. Use scenarios explain to the designer or developer why a solution to this problem is needed. The use scenario illustrates how the problem occurs; it puts the problem in context. The tone is “imagine if you will,” so the person designing the solution can viscerally understand the problem.
You should provide contact information for two or three potential users of the product who can be reached by the designers when clarification is required. A product manager is usually not a necessary interface between the developer and the customer; include phone numbers and email addresses so the team can contact them directly.
- What is the persona doing to cause this problem?
- How does the persona do it now?
- How might the persona like to do it?
When questions arise about an implementation choice, the team should find the answer in the use scenario. Also, provide requirements and use scenarios to QA for their test plans. The ideal test plan ensures that the problem was resolved, not that the design was achieved.
Artifacts for Requirements
Now that we have the detailed documents—the personas and their problems—what form should be used to communicate to the organization? These documents need to be more than a “cocktail napkin” but don’t need to be multi-hundred-page tomes. They are:
- Business plan
- Product roadmap
- Requirements
A business plan includes information about the business of the product. Typically, we update the business plan annually to compare last year’s goals to the actual results. Items that belong in the business plan are:
- Research regarding market problems
- Results from win/loss analysis
- Market definition and sizing
- Distribution strategy
- Distinctive competence
- Financial plan
A product roadmap has become the most popular artifact for representing product strategy. A roadmap shows phases of deliverables over the next 18-36 months or through the next three or four product releases. Most teams prefer to keep the roadmap as a separate document to share with both executives and the product team but some firms include this document in the business plan. For more on product roadmaps, see Product Roadmapping.
The Requirements document–whether called a Market Requirements Document (MRD) or a Product Requirements Document (PRD) or a backlog or something else–contains a prioritized list of problems for your target personas. Contents include:
- Persona definitions
- Phases of deliverables
- Requirements (problems with use scenarios and frequency)
There you have it. A business case reveals your plans for the product as a whole. The roadmap shows phases of deliverables over the next few cycles. The requirements document contains the details of the problems that will be addressed in the next release or product version.
Requirements explain the personas and their problems. Tell a story to help the team understand the persona’s frustration. By providing this context, the product team understands whether a feature should be implemented for power or ease-of-use; the team members will focus on delighting personas instead of themselves. And we’ll get a product that people will want to buy.
Attend Pragmatic Institute’s Build to learn techniques for prioritizing and organizing requirements to maximize the impact of releases.
