The Essential Guide to Requirements Management

Successful product development teams know that behind every successful product is a comprehensive product requirements document (PRD). A good PRD gives everyone a single point of reference for a product’s technical design input requirements, outlines exactly what the product must do to meet the needs of the customers, and aligns the team around a common vision, goals, and objectives for the product being developed. 

But identifying what makes a good PRD is one thing — actually creating one is much more challenging. Many teams look for online templates, but while those can be a useful starting point, they may not be the best fit for a team or product. Every team and product are unique, and it is entirely possible that the team will need to either create its own or tailor an existing template that meets their needs before writing the PRD. The contents and organization of the data and information contained in a PRD will be different for each organization depending on their product line, culture, and product development processes – one size doesn’t fit all! The tables below show some example outlines for a PRD that various organizations have used. Table 1 shows generic sections, Table 2 expands the design input requirements section 3.2.x. 

Having standard templates that are tailored to your product line provide for reuse as well as provide a checklist to help ensure completeness.  The templates should be generic for all products developed within your organization, but tailorable for specific types of products per the needs of individual projects. 

The templates can contain more than just an outline. They can contain “boiler plate” text that is common across the product lines.  In addition, it is common to have a common set of requirements that apply to many of the products developed by the organization such as quality requirements, safety and security requirements, user interface requirements for displays and controls, and requirements dealing with standards and regulations. 

Having templates allows your project team members to focus on defining requirements that are to be contained within the PRD rather than having to first re-invent an outline for organizing those needs and requirements.  Once the templates have been developed, they can be reused by future projects.  Having a standard organization for your requirements, it makes it easier to find information within the documents.  The standard outline, boiler plate text, and requirements common to the product line can also be used as a checklist to prevent omissions. 

Before creating or tailoring a PRD template, it’s important to understand what exactly a PRD is and what its purpose is. 

A PRD is written to define the product technical design input requirements. The PRD should communicate what, who, and how — what the purpose of the document and the product is, who it is for, and how it will result in the stakeholders’ needs being met.  Some organizations may refer to the PRD as a Product Requirement Specification (PRS), a Software Requirements Specification (SRS), a System Requirements Document (SRD), or System Design Specification (SDS). 

It’s important to remember that the PRD is not the same as the Stakeholders Needs Document (SND). Ideally, the SND should come first, as it is focused on the customer’s, users, and other key stakeholders needs and wants. Like the PRD, some organizations may refer to the SND by various names: Marketing Requirements Document (MRD); Stakeholder Requirements Document (SRD), Business Requirements Document (BRD), Scope Definition Document (SDD), Product Concept Document (PCD), etc. The name is not as important as the contents.) 

Any successful product development effort must begin with the customer and other key stakeholders’ needs in mind. What problem is the product to address? What is the vision, goals, and objectives that define the expected outcomes? What are the drivers and constraints? Budget and schedule? What are the use cases and operational scenarios? What capabilities, features, performance, and level of quality do the stakeholders need? What are the safety and security risks associated with the use of the product that must be addressed? What standards and regulations apply? Is what is being asked for feasible?  

These are some of the questions that must be addressed and documented within the SND at the beginning of the project. It is important to understand the stakeholder’s perspective of what they need and expect from the product before defining the technical design input requirements. The integrated set of needs documented within the SND will be transformed into the requirements for inclusion in the PRD. The requirements in the PRD communicate to the development team what the product must do to meet the customers’ users,’ and other stakeholders’ needs. 

Learn more about defining and managing requirements. 

There are many kinds of “good” PRDs, and what makes a PRD “good” for one team doesn’t make it “good” for another team. 

That said, good PRDs have several things in common: 

• The PRD clearly defines the purpose of the product, including a clear statement of the problem the product is addressing and the vision, goals, and objectives defined in the SND. The PRD clearly defines the intent of the stakeholders needs that were defined in the SND from which the requirements were transformed. 
• The requirements in the PRD define “what” the product must do to meet the stakeholder needs, not “how” the product will meet those needs — that’s what the product development process is for. Although the list of requirements should be comprehensive, it should also allow for as much innovation by the development team as possible. 
• The PRD includes a comprehensive list of requirements that will result in the capabilities and features defined in the SND to be realized. Each capability and feature should be clearly defined by well-formed requirements expressions with rationale clearly stating the reason for the requirement being included in the set.  
• In addition to rationale, for each requirement, key attributes should be defined including criticality, priority, source, owner, etc. 
• The PRD should include traceability from each requirement to the stakeholder need(s) from which it was transformed or other source.  

• For each requirement in the PRD, criteria for acceptance should be defined. It is this criterion for acceptance that system verification activities must collect data that can be used to show the product has meet the requirement. 
• In addition to requirements dealing with capabilities, features, and functionality, the requirements set included in the PRD should also address interactions with other products, the operational environment in which the product will be used, quality expectations, performance, scalability, reliability, and compliance to standards and regulations. 

PRD templates are as varied as the teams that create them. The most common templates, and the ones that are usually available for download, come in common formats such as Word, Excel, a database, or within a Requirements management software application like Jama Connect. For small development teams working on simple, straightforward projects, these downloadable templates may be a good fit. 

For teams working on more complex products that involve complex market requirements, or need to meet certain compliance standards, a more robust template might be necessary.  

Good PRD templates will follow a logical progression that takes you from idea through design to final product release. Your PRD template might vary a bit in language or definition, but it should include the following in roughly this progression:

• The objective: Who is this for? What personas or use cases are relevant? How does the product align with strategic initiatives?
• Release details: Include milestones, dependencies, name, release date, and other details relevant to product launch.
• Features of the product: This piece will obviously be the bulk of your PRD. Name and describe the features, their purpose, and the problems the features solve. Do not include items that are outside of the scope for each feature.
• Wireframes and mockups: A picture is worth a thousand words, as they say. Use visual elements to help define user flow and design.
• Analytics: Use this section to establish expectations for your product. Be as specific as possible. For example, “we believe changing the chat interface will improve customer satisfaction” is less specific than “we believe redesigning the chat interface to blue on white will increase our NPS score by 1 – 2 points.”
• Future plans: Assume the best—your product will be a success, and you’ll need to build on that success going forward! What future work, plans, and goals might result from a successful product launch?

In general, the focus of Agile development results in Agile project teams avoiding documents as a formal method of communicating needs and requirements. Agile projects do address the information traditionally contained within SNDs (Stakeholders Need Document) and PRDs as described above, but in less formal forms relying on frequent interactions between team members and customers, progressing in “sprints.”   The team will define, informally, the expectations and desired outcomes for each sprint.  

However, many organizations will define a high-level set of project expectations, needs, and requirements in what some call an Agile Requirements Document (ARD). The information is high-level identifying the problem to be solved, the purpose, vision, goals, and objectives for the product, key drivers and constraints, high-level use cases, capabilities, features, performance expected, compliance requirements, etc.  

The purpose of the ARD is to communicate a high-level definition for the Agile project team that bounds the scope of the project. The ARD is used to kick off the project, communicating high-level customer expectations which product acceptance will be based.   At this level of communication, normally the contents of the ARD do not change once baselined and the project is initiated. The details for addressing the vision, goals, objectives, needs, and requirements within the ARD are left up to the Agile team. 

Because of the nature of Agile product development, templates for SND and PRD type documents are not applicable. Agile teams must be flexible and respond quickly to changing requirements. For scrum teams, the short sprints and quick turnarounds mean there is little time to create documents, much less keep them updated and maintained.  

Teams working under Agile guidelines need to be able to remain nimble, which means avoiding the use of documents. In an agile environment, a team may have a short timeline for a sprint to complete a feature or new release. Adding the development of formal documents to this short process will only add an unnecessary layer of work and complication.  

Historically, non-Agile product development projects define and record the data and information associated with the various product development artifacts in the form of “documents” like a SND or PRD as discussed above. However, using a document-centric approach has many disadvantages for today’s products.   

As products become more complex and regulated, the sheer volume of documentation can be overwhelming; especially in terms of configuration management, change control, and change impact assessment across the product lifecycle.    Often many of the documents are developed and managed by different geographically separated organizational units in silos with limited collaboration. 

In a document-centric approach, it is nearly impossible to keep all the data and information contained within the various documents in sync, current, correct, and consistent resulting in no real single source of truth (SSoT). For example, needs and requirements for the product may be undergoing change, making the maintenance of the data and information within the documents cumbersome and time consuming. For highly regulated products, the amount of documentation that must be developed, maintained, and supplied to regulators to show compliance has become overwhelming. Inconsistencies in these documents can result in a product that is not approved for use. 

The cost and time overhead associated with managing documents and changes to the data and information within the documents consumes a large part of development cost, eating into profit margins.  The time overhead often results in longer development times and time to market, making a company less competitive. Additionally, quality suffers resulting in post product launch costs associated with increases returns, recalls, warranty work, and company image degradation associated with negative social media comments – all of which also eat into profits. A highly regulated product that is not approved for use can result in a company’s stock price to plummet and in some cases the company going bankrupt. 

As valuable as documents like the SND or PRD can be, managing the needs and requirements in document form has shortcomings like those discussed above. When change happens, the project team needs an effective method to assess how the change affects other artifacts across the lifecycle.  

To effectively develop and manage these complex, highly regulated products, organizations need to transition to a requirements management software platform such as Jama Connect allowing project teams to work on a Living Requirements™ Management basis in order to establish a SSoT, establish traceability across the product lifecycle, and manage and assess change.   

Even for less complex products, using documents as the primary form to record data and information typically contained within an or PRD may not be the right call. If teams are widely dispersed, keeping these documents current, in sync, and consistent may be challenging, even if it is stored in the cloud.  

The need for, and benefits of, templates discussed above apply equality to data-centric product development using a requirements management software platform like Jama Connect.  The difference is that the organization of data and information is defined in terms of specific types of data and information in a form that supports traceability. A “schema” is defined concerning the various types of data and information and their relationships.  

Rather than “documents,” needs and requirements are organized in “sets.”  You would have an integrated “set” of stakeholder needs rather than a SND. and you would have sets of requirements corresponding to the product architecture rather than a PRD and other requirements documents 

This doesn’t mean there will not be documents. While the SSoT is maintained within the data and information stored and managed withing the software application, documents can be created as “reports.”  Each report can have a template defined within the software application with the same characteristic discussed earlier. 

Using this approach, the SSoT is maintained with in the requirements management software application, not the report that is an output of the application. Users of these type of documents need to understand that the currency of the data in the “document” is only valid at the time the document was output from the application.  

Product development teams know that often, the difference between a good product and a great product or a good launch and a great launch is in the planning. Starting with clear definitions and descriptions, tracing requirements throughout development, and staying flexible enough to adapt to change along the way are key. Documents don’t always provide the right framework for a true Living Requirements™ approach. 

Jama Connect can help your development team step into the future of product development and move away from documents. To learn how Jama Connect can streamline requirements, contact us.