Today’s issue is the first of two topics covering product requirements.
Requirements, as the fuel that powers your company’s software development engine, are an essential part of product management. Without this fuel, development doesn’t happen. Too little or too much, too sparse or too rich — all lead to a poorly running engine. It is essential that you as a Product Manager master product requirements.
Because this is such a big topic, today’s issue will discuss the Requirements document, while next week we will cover the Requirements process.
[private]
The Requirements Document
If somebody gave you the assignment to create one of the documents commonly used throughout the software industry — business plans, marketing plans, development plans, test plans — chances are you would feel reasonably confident about what content and level of detail is needed. You could expect that what you produce is a common variation that others have encountered in the past.
While this can be said about many documents produced or used by Product Managers, when it comes to the area of product requirements, standards and expectations seem to be wide open. When the word “Requirements” is spoken, people picture everything from lists of bullets to design specs.
Read on for the basics on who creates and uses the Requirements document, and what to include to make this document effective.
Who Builds It?
Product Managers build the Requirements document, taking information from their own market research and competitive analysis, from prospects and customers, then from the sales, marketing, consulting, customer care, training, and development functions.
Requirements should not be written by developers based on material presented verbally to them. That’s asking them to set their own tasks and priorities. You need separation of powers, just like in the U.S. government.
Sales reps, consultants and trainers should not submit extensive written requirements. They can send brief descriptions of fixes or enhancements that are important to them. The Product Managers are the ones to take requirements from many different sources and define and prioritize them.
Who Uses It, and What For?
Product Managers use the Requirements document to present a consolidated, consistent, and prioritized list of needed changes and enhancements to Development for the next product development cycle.
The company uses the Requirements document to specify all developer or engineer time needed during the next cycle, whether for sales and marketing support, customer care, testing, or coding.
Developers use the Requirements document to create resource estimates, plans and schedules for all work provided by developers or engineers during the next product development cycle.
What Does It Contain?
First, some overall guidelines on the content.
Requirements are not specs. They are not many-paged documents laying out in excruciating detail each screen, field, button, and piece of functionality. Your company may or may not choose to develop specs down to that level of detail. Such specs can be completed by developers during the design work that is based on the Requirements document.
Requirements are not a wish list. They do not need to contain every single wish for product functionality ever voiced by someone inside or outside the company. They also provide enough factual information so that the requested functionality is not open to widely differing interpretations by developers. No fluffy requests like “Make the report writer user friendly” with no further explanation.
If you make it complicated, you’re stuck living with that complication at the start of every single release cycle when you go to update the Requirements. If the meaning of a column in the requirements is obvious to most people, then you’re on the right track in terms of simplicity.
There are a couple back issues that discuss the level of detail for Requirements documents:
- Requirements: From “Hype-ful” to Helpful — provides tips on how to create a simply worded requirement.
- Requirements: How Much Is Enough? — discusses the optimal amount of detail and best focus for the requirements effort.
Beyond this general advice, the Requirements document is most useful as a spreadsheet or table with the columns described below.
Category
Organize your long list of requirements into categories to help you and others at the company see the bigger picture in terms of product direction and amount of development work requested.
Research shows that most people are able to keep track in their heads of between seven and nine separate items. Chances are those research subjects were tested in a calm environment without the usual information overload of the office. If you can simplify things into five or six categories, even better.
The goal is to provide a more structured picture of product changes and improvements. Different developers or teams of engineers may focus on different categories, and their jobs are made easier if they can ignore unrelated requirements.
Requirement Number
This is a unique identifier for the requirement. You can build other information into this number, such as Category, and even date, if you want to track the date a requirement is first defined.
For example, the number 02-015-030317 would be the fifteenth requirement defined for the second Category, on March 17, 2003. It’s quite possible, though, that you would never wind up putting the date information to practical use, so you’re better off with a simpler number like 02-015.
Priority
Keep prioritization simple, for instance: High, Medium, and Low.
High priority requirements are those that must be worked on in the next development cycle.
Medium requirements may be incorporated if there are development resources left over after all High priority requirements are estimated and scheduled.
Low requirements are important enough to record, but aren’t important enough to do in the upcoming development cycle.
Remember, if you assign a High priority to all the requirements, you’re putting the final prioritization into the hands of the development team. They get to pick and choose what they want to do.
Source
This can be a useful piece of information to identify individuals, departments, or business partners that request the change.
Putting individual names can be a way of encouraging people to come forward with requirements. When teammates see their names on the Requirements document, they get a feeling of ownership.
Having the Source can also provide an additional resource to consult besides the Product Manager when a developer needs clarification during the design phase.
Development Cycle
This indicates the cycle number or version number where work on the requirement is carried out. This may be a single cycle, or a more extensive enhancement may span a number of versions.
A quick scan of this column provides you the list of what is going to be worked on in the coming release.
ROI/Impact
It is always useful to provide a column that gives the justification for a requirement. This might be “Architectural Upgrade” or “Needed by VARs”, or ideally, a dollar figure of estimated revenue/cost savings from the added functionality.
Recent accounting guidelines for software companies (2000 and later) make the dollar figure a useful number that your company’s Finance department can use to recognize revenue and assign costs.
Description
This is a factual description of the correction or enhancement required. There should be enough information that a developer, following internal standards for design, quality, and coding, can understand what to do without having to make important judgment calls.
A requirement may be one to three lines, or one to three paragraphs, but don’t make it longer than that, at least in the main Requirements document. If necessary, certain requirements may involve detailed explanations in a separate document, which you refer to in the Description column of the appropriate requirement.
Two articles that discuss optimal wording for Requirements documents are:
- Requirements: From “Hype-ful” to Helpful — provides tips on how to create a simply worded requirement.
- Requirements: How Much Is Enough? — discusses the optimal amount of detail and best focus for the requirements effort.
Follow the guidelines above to streamline the creation of a solid, workable Requirements document that feeds the vital fuel to your software development engine.
— Jacques Murphy, Product Management Challenges
Product.ManagementChallenges.com
Next Topic: the Requirements Process
[/private]