In this blog post, we recap a webinar discussing why Word & Excel are not enough to manage complex requirements.
Product development is more complex today than ever before. Modern products are multifaceted and multidisciplinary, with hardware, software, and various engineering approaches coming together in the name of superior customer experience. Many industries — medical device, automotive, and aerospace and defense, for instance — also require that complex product developers adhere to rigorous safety standards and regulations. Companies must work effectively and efficiently if they’re going to keep their competitive advantage. And that all starts with requirements management.
In this webinar, experts will discuss how you can manage your requirements in a more efficient way than document and look at how to navigate between different versions (version control) and how to collaborate with your team on your requirements.
You will learn more about:
How using Word and Excel for requirements management introduces risk to your product development
The pitfalls of not having a formal requirements management solution
Benefits of a data-driven approach to requirements management
How Jama Software can help
Below is an abbreviated transcript and a recording of our webinar.
Excel and Word Are Not Enough
Jerogen Frikken: All right. Thank you Marie for the great introduction. So today we’re going to focus on the requirement management tools and why Word and Excel just isn’t enough. We will first talk about the challenges in the pitfalls you will encounter when using a document based approach for your requirement management process. We will then show you the benefits of a data driven approach and why this is the preferred methods over a document approach. And we will end with an overview of how Jama could actually help you with this and close with a Q & A.
The development of products and the delivery of them are more complex today than ever before. Products today are having many different parts and are combining hardware, software, and various engineering approaches all together. Many industries like the medical device, automotive and aerospace and defense industry, for instance, also require that complex product developers apply to safety standards and regulations. Organizations have to work in a more efficient and […] if they want to stay ahead to their competition. Despite this, many teams are still using Word and Excel to manage requirements for these very complex products. This means they’re missing real time collaboration and insights, end to end traceability and integration with product testing.
Jerogen Frikken: Now, I am sure most of you are familiar with the term requirements management. But just in case you are not requirements management is the process of making sure you build just the right products. And for products that will have different releases or versions over time, understanding the changes to these requirements and their impact is a continuous process throughout the complete development cycle.
Basically you can view requirements management in three different ways. First, obtain and document the requirements. In a world of competing priorities and different opinions this is always a challenge and typically the responsibility of business analysts, system engineering and product owners.
Secondly, once we have documented the requirements we need to review and confirm they are the correct requirements. Are the requirements we document really what the user or the customer needs? Confirming this is often called the process of validation. And this is typically done by product managers, customers or users.
Last but not least. You may need to work with the requirements so you can confirm the teams have built the products according to the documented requirements. This process is typically called verifying the requirements or verification. Developers, testers, and quality assurance leads are key stakeholders in this process.
https://www.jamasoftware.com/media/2022/01/WB-2021-12-14_Why-Excel-and-Word-are-not-Enough_Social-Image.png5121024Jama Software/media/jama-logo-primary.svgJama Software2022-02-15 03:00:572023-01-12 16:47:37[Webinar Recap] Why Word & Excel Are Not Enough to Manage Complex Requirements
Whether you’re just learning the basics of requirements management, looking to improve your current requirements management process, or interested in benchmarking your process against industry leaders, you’re in the right place.
This article covers what requirements management is, why managing requirements matters, what the requirements management process entails, and how to manage requirements when creating complex, highly regulated products.
What is a need?
A need is an agreed-to expectation for a product or system to perform some function or possess some quality within specified constraints with acceptable risk. Needs communicate what the stakeholders need and expect from a product or system in order for a given problem or opportunity to be addressed.
What is a requirement?
A requirement is the result of a formal transformation of one or more needs or parent requirements into an agreed-to obligation for a product or system to perform some function or possess some quality within specified constraints with acceptable risk.
There are different types of needs and requirements that range from a business focus to a user focus to a technical focus.
Business needs and requirements, sometimes referred to as stakeholder needs and requirements, are those derived from the business processes or elicited from the stakeholders including customers, users, and other stakeholders involved in the project. The stakeholder needs represent what the stakeholders need the product to do to address the problem or opportunity the product is to address; stakeholder requirements are stakeholder-own product requirements that communicate what the stakeholders require of the product to meet their needs. Stakeholder needs are expressed in natural language without the use of “shall”, while stakeholder requirements are communicated with “shall” to make sure they are treated as binding requirements the product will be verified to meet.
Given there are multiple stakeholders, there will be multiple sets of stakeholder needs and requirements. It is up to the project team to elicit these needs and requirements, resolve conflicts, inconsistencies, and other issues. The results will be an integrated set of needs from which the product requirements will be transformed from. The resulting product requirements represents what the product must do in order for the needs to be met. Product requirements are sometimes referred to as system requirements, software requirements, or technical requirements.
What is requirements management?
Requirements management is the process of gathering, analyzing, verifying, and validating the needs and requirements for the given product or system being developed. Successful requirements management ensures that completed deliverables meet the expectations of the stakeholders. Requirements can be managed using documents, however, complex systems or products in highly regulated industries mitigate risk by using trusted requirements management tools.
Why is requirements management important?
Requirements management is important because it empowers everyone to clearly understand stakeholder expectations and confidently deliver a product that has been verified to meet the requirements and validated to meet the needs.
Requirements management is a sophisticated process that includes many moving parts and diverse groups of people. Typically, the product management department, specifically the product manager, is responsible for the requirements management process. They work with the stakeholders, including business teams, customers, users, developers, testers, regulators, and quality assurance.
Additionally, a product may have only 100 requirements, or it may have several thousand. This depends on its complexity and level of regulation. With all these elements at play, success hinges on the ability to get everyone on the same page, working toward the same goal.
Therefore, the business value of managing requirements is huge, as successful requirements management is key to project success. Benefits of requirements management include:
Enhance understanding of stakeholder needs, requirements, and expectations and the problem or opportunity the product is to address
Gain clarity on scope, budget, and schedule
Minimize costly and time-consuming rework
Increase product quality
Improve likelihood of delivering the right product, within budget and schedule with the required quality.
The importance of requirements management is intensified, however, when building complex or highly regulated products. This is because more time and budget are invested in development. The cost of getting it wrong — be it money, time, or reputation — is too great to risk. Hence, developers in regulated industries, or those who develop products with a lengthy list of needs and requirements, tend to rely on requirements management tools, like Jama Connect® to keep their projects in order.
Requirements management vs. project management
While it may seem that requirements management and project management are synonymous, there is a difference. Simply, project management is getting the product built within budget and schedule with the available resources. Requirements management is making sure the product is the right product built right.
The goal of the product development process is to create a successful product that meets stakeholder, customer, and market needs. The requirements management piece of product development includes managing the needs and requirements so that the product meets stakeholder expectations. Therefore, needs and requirements along with budget and schedule set the scope for the project.
However, the domain of project management encompasses tasks like providing budget, personnel, and resources needed to develop the product.
Stages of the requirements management process
So, how do you manage requirements? The most successful teams work from a defined requirements management process. Defining the requirements management process is important because requirements change throughout a project. When this happens, that change needs to pass through the same, repeatable process.
There are four main stages of the requirements management process — planning, development, system verification, and system validation — each with important considerations to the overall project. Change management, while not a stage itself, affects nearly every phase of the requirements management process.
The product development methodology—waterfall, agile, or Scrum—helps decide how requirements move through the process. Waterfall models are typically linear with development moving from one process area to another with a completed product delivered with the required features and functionality. Agile development, including Scrum, is iterative in nature. In requirements management, agile teams, and those using the Scrum approach, may be working on different sets of requirements concurrently, delivering a product in increments, each increment adding value with additional features or functionality.
No matter which methodology is employed, the RMP is the documented process the team uses throughout product development. It contains information like stakeholder roles and responsibilities, which needs and requirement artifacts will be defined, how traceability will be competed and managed, how needs and requirements baseline will be handled, how interactions (interfaces) with external systems and users will be managed, how changes will be managed, how the product will be verified to meet the requirements, and how the product will be validated to meet the needs.
A successful Requirements Management Plan is visible to and has sign off from stakeholders, as it sets the course and expectations for all stakeholders throughout the product development journey.
Needs and Requirements artifacts
Part of the RMP is defining the needs and requirements artifacts that will be created during the requirements management process.
Needs and requirements artifacts include the data and information concerning the needs and requirements and related information. Examples include diagrams, and models, integrated set of needs, set of product requirements, use cases, design documents, testing plans and procedures. Requirements artifacts are used throughout the product development lifecycle to:
Describe the product being built
Identify the actions needed to develop the product
Capture the actions performed during development
Define the testing needed for system verification and system validation
Assist with stakeholder review, communications, and engagement
While some organizations will communicate this information in a document form (e.g., a Software Requirements Specification (SRS)), the increasing trend is to manage the needs and requirements within a requirements management software application.
The reason organizations are moving towards a data-centric practice of product development is that is hard, for any document-based approach to be flexible and scalable enough for complex agile projects. This is especially true for highly regulated industries that must prove compliance. Due to numerous factors—lack of consistent updating, human error, incomplete data, version control, the need to establish and maintain traceability, etc.—documents simply cannot be relied upon determine whether a need or requirement is fulfilled.
Agile product teams working on complex products in highly regulated industries will have much more success using a requirements management software application to streamline the requirements analysis phase of requirements definition and management. Modern requirements definition and management solutions, like Jama Connect®, define, establish traceability, manage, and validate complex product requirements automatically, which simplifies not only requirements analysis, but the overall requirements definition and management process.
It is imperative that needs and requirements and needs and requirements artifacts are linked to each other and to additional related artifacts. This can be difficult to achieve using documents, as the manual nature lends itself to myriad errors. This is especially true in the case of complex or highly-regulated products where traceability is a prerequisite for proving compliance.
Needs and Requirements attributes
To keep track of the requirements in a given project, each requirement should have a specific list of attributes. Requirements attributes are used to ensure that requirements are organized and uniquely identified across all requirements artifacts. The attributes also aid in managing the sets of needs and requirements, enabling reporting and dashboards to be defined to provide accurate and timely status of the project.
It is a best practice that the following requirement attributes are included for all needs and requirements:
Verification status (for requirements)
Validation status (for needs)
Needs and Requirements Baseline
A needs and requirements baseline is a point-in-time look at a committed set of agreed-upon, reviewed, and approved needs and requirements, or planned functionality and features to be included in the product. The purpose is to provide information to stakeholders so they can make informed decisions on and possibly modify the planned functionality and features using change requests.
The RMP defines a baseline strategy including timing and frequency of creation, needs and requirements prioritization (deciding which requirements should be included), publishing, change management, requirements verification, and requirements validation. In this context needs and requirements verification address the quality of the needs and requirements statements as well as the existence and correctness of the traceability. Needs validation is confirmation with the stakeholders that the integrated set of needs clearly communicates the intent of the stakeholder in terms of what the need the product to do. Requirements validation is confirmation with the stakeholders that individual requirements and the set of requirements clearly communicate the intent of the needs they were transformed from. The quality of the requirements is dependent on the quality of the needs from which they were transformed.
Establishing a requirements baseline is important because it implies that:
Scope has been defined and agreed to – Critical to control scope creep!
Formal change control begins
Staffing levels and budgets are set
Schedule commitments are made
Typically, baselines are stored in software requirements specification (SRS) documents. However, a complex system might need a variety of software, hardware, and interface requirement specifications to encapsulate the baseline’s components. This can be cumbersome to maintain during initial development and downright impossible during change management.
The development stage is conducted using the organization’s requirements analysis process.
The needs and requirements development stage incudes eliciting needs and requirements from the identified stakeholders, properly defining and refining them, and analyzing them to ensure clarity and resolve issues and conflicts. Without successful needs and requirements development there would surely be gaps between what the stakeholders expect and what is ultimately delivered. The result of which could be disastrous.
Eliciting needs and requirements
Also called needs and requirements gathering, eliciting needs and requirements is the act of working with users, customers, and internal business stakeholders to identify stakeholder needs and requirements and get an understanding of the product or system requirements.
Needs and requirements definition
Needs and requirements definition is the time when the gathered needs and requirements are re-written in a clear and traceable way that enables effective communication throughout the product development lifecycle.
Many teams use a requirements traceability matrix (RTM) to track requirements and manage the scope of a requirements change. The RTM is static and maintained manually. The problem is that change is ubiquitous in the product development process. When change happens, teams must manually search the RTM document for all related upstream and downstream needs and requirements, dependent requirements and verification and valdidation tests that may be affected by the change.
Scouring through an excel spreadsheet for each change may not be that daunting if there are only one hundred or so needs and requirements. However, if the product has hundreds or thousands of needs and requirements—think complex, regulated products—managing the scope of change becomes a cumbersome and time draining exercise fraught with risk.
Requirements management tools are designed to streamline the process—even for highly complex, regulated products. Jama Connect, specifically, uses the benefits of living requirements to:
Easily determine the impact of change
Enable end-to-end process improvement
Reduce product risk
Sometimes, there is a gap between what stakeholders say they want and what they actually want. The purpose of requirements analysis is to ensure all business, software, and product requirements accurately represent stakeholder needs and requirements. The goal of requirements analysis is to get a clear understanding of stakeholder needs so the deliverable matches stakeholder expectations.
System Verification Stage
System verification means determining if the finished product meets the baselined product requirements. This is different than system validation (discussed below), which evaluates whether the product satisfies the stakeholder needs. are both important but system verification always comes first.
Planning for this stage starts when the product requirements are being defined. Planning includes, determining which system verification events are needed to confirm that product requirements are fulfilled.
To ensure successful system verification, the following attributes should be defined for each product requirement before the requirements are baselined, to set the expectations for the tests and quality assurance work that needs to be done and reduce the risk of rework efforts later.
Success criteria (what must be proven to show the requirement was met)
Method (test, demonstration, inspection, or analysis)
Strategy (approach to be used, operating environment, test environment, system configuration, etc.)
System Validation Stage
System validation means determining whether the product satisfies the stakeholder needs. are both important but successful system validation is what leads to product acceptance for its intended use, by the intended users, in the actual operational environment. For highly regulated products, approval for use is dependent on successful system validation. Final product acceptance by a customer also depends on successful system validation.
Planning for system validation starts when the integrated set of needs are being defined. Planning includes, determining which system validation events are needed to confirm that needs are fulfilled. One approach is to define a set of attributes that address system validation for each need.
To ensure successful system validation, the following attributes should be defined for each need before the needs are baselined, to set the expectations for the tests and quality assurance work that needs to be done and reduce the risk of rework efforts later.
Success criteria (what must be proven to show the need was met)
Method (test, demonstration, inspection, or analysis)
Strategy (approach to be used, operating environment, test environment, system configuration, etc.)
When building products that have thousands of requirements and countless changes, teams can spend hours circulating, editing, and tracking changes in an attempt to maintain traceability and simply keep development on track.
This is especially challenging when maintaining the needs and requirements in document form. Version control issues are one challenge that results from change. Versioning problems can arise on the artifact itself, for example someone might be giving feedback on SRS version one but there is already an SRS version two with different, additional edits. But version control can even be more granular, within the document as well. For example, requirement one might be on version three, which is linked to test B on version two.
Add that to consolidating feedback from multiple stakeholders via email or meetings, analyzing the impact of change across various versions of requirements artifacts, and communicating the correct changes and statuses to the right people. It’s a nightmare just thinking about how to keep it all straight.
It’s easy to recognize that problems are compounded when managing requirements using documents, or legacy systems based on documents, instead of a purpose-built requirements management tool. Most of these challenges, and more, can be overcome by switching from a document-centric to a data-centric approach to requirements management.
How to successfully manage requirements in complex products and highly regulated industries
Standards and Regulations can be a source of a large number of requirements the product must be compliant. Often not all of the requirements in a regulation or standard apply to your specific product. Often standards and regulations contain requirements not only on a product, but on the organization developing the product, as well as requirements concerning system verification and system validation (acceptance, certification, and qualification).
In addition, often requirements within standards and regulations are written poorly and ambiguously. As part of identifying drivers and constraints at the beginning of the project, the project team needs to identify which standards and regulations apply to their product and which requirements in those standards and regulations apply as well. Then they must write well-formed product requirements to address the intent of those requirements that will result in a product that is compliant with the applicable standards and regulations.
Regulations are not requirements. Requirements must be written to adequately satisfy the regulatory standards. A keen understanding of the standards or regulations is paramount in writing requirements that will lead to a product’s compliance. Once written, a regulatory requirement should be attributed as such in all requirements artifacts. This can be done be assigning a “compliance” attribute. This provides all team members visibility throughout development, which assists with decision making and change analysis.
In addition to expert knowledge of the standards and regulations, the following are needed to maintain product compliance when building a product:
Collaboration between teams
Single source of truth for defining, verifying, and validating compliance requirements
Standard frameworks aligned to standards and regulations
Traceability across all development activities and resulting artifacts.
Simplified audit preparation and data exports
Reporting is key when faced with a compliance audit. Teams must know what data is required for the audit and how to easily access it when needed. Often, audit trails are an afterthought in which teams are scrambling to pull together data from several sources. This is a dangerous practice, though, because it can risk delivery timelines and delay launch, or risk failing to launch altogether. Any teams that must show compliance, must eliminate this risk with a digital, detailed audit trail that can be easily exported whenever needed. Establishing and managing traceability is critical to be able to maintain the audit trail.
Many leaders in regulated industries rely on requirements management tools to reduce the risk of failure to comply with standards and regulations during the product development process. Jama Connect, for example, can track standards and regulations and compliance when building products. These industry leaders leverage Jama Connect to keep them at the forefront of innovation:
The advantages of requirements management tools are many. A modern solution can eliminate the risks and inefficiencies of documents and legacy systems.
A valuable requirements management system, like Jama Connect, can bridge engineering siloes throughout the development process, including test and risk activities. An effective tool helps improve the product development process by:
Ensuring quality and compliance
Increasing efficiency and optimizing processes
Easily understanding and responding to change
Streamlining and accelerating reviews
Enabling real-time collaboration and iteration
There are many requirements management tools available, but only a few that can help reap all the benefits listed above. When thinking about the most important features in a requirements management system, first think about what’s being built. The industry and complexity level will help inform the features that will be best for your team. This guide to buying a requirements management tool may also help.
Quality assessment of requirements and traceability
The good news is that you don’t have to pick and choose. Jama Connect helps navigate complexity and provides end-to-end compliance, risk mitigation, and process improvement with all the features listed above—and more.
https://www.jamasoftware.com/media/2021/08/2021-09-01-what-is-rm-1024x512-1.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2021-09-01 03:00:192023-01-12 16:48:08What is Requirements Management?
Looking for PRD templates and examples that you can download and adopt in your product team’s workflow, but struggling to find something that fits? Jama can advise you on how to build a template that meets your team’s unique needs.
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 development needs, outlines exactly what customers require in a final product, and aligns the team around the vision, goals, and initiative of the new product.
But identifying what makes a good PRD is one thing—actually writing one is much more challenging. Many teams look for free 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 is unique, and it’s entirely possible that the team will need to design its own template before writing the PRD.
What is a product requirements document?
Before designing or adapting a PRD template, it’s important to back up and define what exactly a product requirements document is and what it’s designed to do.
A product requirements document (PRD) is written by a product manager to define the scope, value, and purpose of a product or feature. The PRD should communicate what, who, and how—what the product is, who it is for, and how it will benefit the end user.
It’s important to remember that the PRD is not the same as the marketing requirements document, or MRD. Ideally, the MRD should come first, as it is focused on the customer’s needs and wants. Any successful product or product launch has to begin with the customer in mind. Requirements will be defined by customer needs, and those will drive the PRD.
There are many kinds of “good” product requirements documents, 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:
They clearly define the purpose of the product. A good PRD will set a clear, realistic target for the final product. It will identify problems the product should solve, not the solutions to those problems—that’s what the product development process is for. Finally, the PRD will identify the end user and describe the scenarios where the product will be used.
They include a comprehensive list of features required. Most of the PRD will be comprised of the actual requirements of the product. Each feature should be clearly defined, and the final user experience should be described in detail. The PRD should also identify which requirements support each objective so that teams can perform comprehensive requirements traceability. Finally, although the requirements list should be comprehensive, it should also allow for as much engineering flexibility as possible.
They list the criteria for release. Release criteria may include certain requirements for performance, scalability, reliability, and so on. By setting clear minimum release criteria up front, development teams can have a better view of how to prioritize.
They define a clear schedule. Of course, schedules can be changed, and externalities or unknowns can always throw off the most ideal timeline. But setting a clear schedule for checkpoints, milestones, and final release, development teams will be better aligned to stay as close to original release dates as possible.
What types of product requirement document templates exist?
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, and the Google suite of cloud formats. For small development teams working on simple, straightforward projects, these downloadable templates may be a good fit.
For teams working on more complicated products that require extensive user stories, involve complex market requirements, or need to meet certain compliance standards, a more robust template might be necessary. These more robust templates are usually available from cloud requirements management firms.
What features do good product requirement document templates have?
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?
What are examples of good Agile requirements documents?
The answer is simple: there are no examples of good Agile requirements documents or templates. Why? Because the nature of Agile product development does not lend itself to documents and templates. Whereas the waterfall method of product development lends itself to dependencies and a straightforward process, 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 a complete PRD, much less keep it updated and maintained.
Teams working under Agile guidelines need to be able to remain nimble, which means not confining development to the strictures of a document or template. A better approach for Agile teams is to use software such as Jama Connect to allow for real-time updating.
Agile teams should work on a Living Requirements™ Management basis. Living Requirements mean that teams need a single source of truth, but they also need to acknowledge that the truth will change and adapt over time.
When is a document not the right call?
As valuable as a PRD can be in the right setting, it does have shortcomings. For example, 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 a PRD to this short process will only add an unnecessary layer of work and complication. Or, it’s possible that a product is undergoing rapid change and development, making the maintenance of a document cumbersome. In those cases, it might be better to transition to a requirements management software platform.
Even for a simpler product or more traditional waterfall development method, using a PRD or PRD template may not be the right call. If teams are widely dispersed, keeping a PRD updated may be challenging, even if it’s stored in the cloud. And templates and documents are, by definition, less flexible than software; it may not be possible in a document to catch all of the dependencies when one change is made.
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 along the way are key. Templates and 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 templates and documents. To learn how Jama Connect can streamline requirements, contact us.
https://www.jamasoftware.com/media/2021/08/2021-08-18-what-makes-good-prd-template_1024x512.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2021-08-18 03:00:102023-01-12 16:48:09What Makes a Good Product Requirements Document (PRD) Template?