Today it is easy to assume that all organizations have adopted an Agile approach to product development. While Agile methods are very popular Waterfall and the combination of Waterfall with an Agile method are also fairly common. So in this post I want to step away from Agile and look at requirements in a non-Agile organization.
The requirements document is where the rubber meets the road for your product’s development. At this point your high-level observations about market opportunities get translated into capabilities by your engineering team. Many different people will contribute content to your requirements documentation. The contents often vary between companies. The following sections are frequently a part of this important document:
- About this document
- Business analysis
- High-level use cases
- Functional requirements
- Compliance requirements
- Report requirements
- User interface requirements
- Environment requirements
Now let’s take a closer look at what’s included in each section.
About this Document Essentials
This section sets the framework for the entire document. It is vital that it give the date of the last document revision, the version number, and who made the most recent change. In addition, a description of the revision should be given. These specifics will show who approved the changes and the date of the approval. This section is also a good place to define key terms used in the document.
Business Analysis Section
This section is a high level definition of the business need for the new capability. Here product managers notate the proposed release date linked to the product roadmap. The section lists high-level business and marketing requirements including release dates. A SWOT analysis could be included indicating strengths, weaknesses, opportunities and threats to the project. The last item included is a Feature Matrix, which captures product development estimates for a prioritized list of features. This establishes a firm cut-off line for product development, based on the resources, time, and money available.
High-level Use Cases
Here, you’ll highlight detailed business objectives, which will become functional specifications for the new product. A diagram is often included showing the system with which the user is going to integrate. This system will gain value from the new capabilities you’re developing. If more than one group will use your product, this section is a good place to list all the use cases the team has developed.
Functional Requirements Section
The functional requirements you list will likely develop into something of a use case. It will show behavioral elements of how the product will be used. These requirements are where you’ll reveal specifically what your product is supposed to accomplish. This information will inform and guide the product design.
Compliance
What does the law require of your product? That will be the subject of the Compliance Requirements section. This section could include data use rules, security or contractual considerations, or perhaps even government requirements.
Report Section
Inputs, layout, report fields, headers and footers, and any groupings are all detailed in the report’s requirements section.
User Interface
How does one engage with the project? That’s what is explained in the User Interface Requirements Section. The information often consists of a conceptual site map, and is frequently presented in a diagram exploring the analysis that’s taken place. If there’s a protosite to model the user interface capabilities, a hyperlink is given.
Environment Section
Architectural standards that relate to system performance and any operational or integration are presented in this final section of the document.
Taking the Next Step
In my next post, I’ll look beyond the development of priorities, roadmaps, and requirements to explore the importance of remaining flexible throughout the process.
Advancing the Profession of Product Management™
website I consulting I training I toolkits I books I blog I twitter