In this post, we discuss Apex.AI’s selection of Jama Connect to shorten development time and increase efficiency.
Award Winning Automotive Software Developer Selects Jama Connect® to Shorten Development Time, Increase Efficiency, and Sail Through Audit Preparation.
Apex.AI, founded in 2017 in Palo Alto, California, is a mobility software company, and makers of the ISO 26262 ASIL-D safety-certified software framework Apex.OS. As a pioneer in modern C++ software development for safety, they are the first organization to certify a modern C++ open-source product to ASIL-D. Their client list is extensive and prestigious, and they are backed by some of the leading venture capital firms in the world, including Lightspeed Ventures, Toyota AI Ventures, Volvo Ventures, and Airbus Ventures.
More about Apex.AI:
Headquartered in Palo Alto, CA in the heart of Silicon Valley with offices in Munich, Berlin, and Stuttgart, Germany and with employees worldwide.
Founded in 2017 in Palo Alto, CA
Expertise: Building robust, reliable, safe, secure, and certified software for mobility systems
Recent Awards for Apex.OS, the safety-certified automotive OS:
Apex.OS wins two awards from the German Design Council (June 2021): “Best of the Best” award and “Innovation of the Year” award
With a mission to enable automotive developers to implement complex AI software, and enable AI developers to implement safety-critical applications, Apex.AI is an innovator in the automotive industry.
Comprised of alumni from top automotive, robotics, and software companies around the world, the Apex.AI team knew that development success starts with requirements management. That’s why they set out to evaluate the top requirements management solutions from the very beginning. The team had clear objectives and knew that their requirements management solution needed to:
Allow the team to create a centralized repository of requirements
Help them demonstrate compliance with stringent automotive standards like ISO 26262
Enable collaboration across a globally distributed team
Be a modern, cloud-based solution that all team members could use
The team did not take the selection process lightly; they knew there was too much at stake. Apex.AI did an analysis of the full requirements management tools and software market and decided to evaluate Siemens Polarion and YAKINDU more in-depth.
After an in-depth analysis of these requirements management (RM) tools – including interviewing current users of these products – Jama Connect was selected as the solution of choice for the team for the following qualities:
End-to-end traceability from requirements all the way through to tests
Powerful, flexible solution that all team members can easily use
Industry-specific templates and expertise in automotive development
An easier path to compliance
“Why would an innovative automotive company consider Jama Connect? From my perspective, Jama Connect is the best of breed requirements analysis and requirements engineering tool… I would highly recommend it and I would use it again without any hesitation on any subsequent project. ”
Neil Langmead – Senior Functional Safety Engineer, Apex.AI
Jama Connect was also the only solution that had Living Requirements™ management, which allows teams to move away from static requirements trapped in disparate documents and creates a digital thread through upstream and downstream activities.
“Jama Connect doesn’t require much in the way of support and overhead. Once we installed the cloud-based solution it ‘just works’ – and that’s the highest validation for any complex piece of software.”
Neil Langmead – Senior Functional Safety Engineer, Apex.AI
In a previous post, Mario Maldari writes about his first week at Jama Software and gives insight into the Jama Software community and company culture.
Version 1.0 – The beginning
It’s hard to imagine that I started my career over 20 years ago, working on requirements management software. I had just moved out to Boulder, Colorado from Boston and began work as a software test lead on a popular requirements product named RequisitePro. Over the next three years I saw the product evolve from a “floating tool bar” (that was to accommodate users who were comfortable with using Word and Excel) to a full-blown application with folder-based hierarchy and feature reach functionality. Other experimentations occurred during this time, which included plugins to VSNET and Eclipse. Our main competitor was a product from Telelogic named “DOORS.” These were indeed exciting times as the software industry seemed to be constantly evolving and we were working hard to keep up!
Version 2.0 – Evolution
In 2003, Rational Software was acquired by IBM®. New technology, architecture, and clients were all added to help shift and shape the software. Rational® became part of the larger software group with giants like DB2 and Websphere. The old suite of products were reinvented with Requirements Composer being the key offering for requirements management, which later evolved in to IBM® DOORS® Next®. There was a focus on Rich Text editing to better accommodate clients who were using documents and spreadsheets.
In 2007, Telelogic was acquired by IBM and my two worlds combined. It was great to partner with what was once the competition and I met some of my favorite colleagues during this time. Efforts were made to capture the best of both Rational and Teleologic and combine them in to one offering. The products evolved and grew more complex to address the many varied industries they were intended to support.
Version 3.0 – Change and growth
Often times, we see smaller companies who don’t anticipate the need for formal requirements management early on. They will either not track requirements or try and manage them using a spreadsheet or document. When faced with a regulatory audit, they quickly realize the need for a more formalized method and strategy for tracking their requirements. Equally as important, is showing how the requirements have been verified and validated. The informal means of tracking requirements can prevent scale and hinder the growth of a business. It is essential to plan early and strategize on an approach to formally track requirements across the lifecycle.
Requirements management software is needed across all industries and must accommodate a myriad of standards. It must be simple to use, but powerful. It must be customizable, but effective “out of the box.”
I’ve found the following key characteristics as essential needs for any good requirements management tool:
Usability and simplicity
Clear traceability and suspect tracking
Version and baseline tracking
Import, export, and reuse
Collaboration and reviews
Reporting and audit support
Verification and Validation
The tooling and feature set itself is important, but what is also needed is a company that can support their clients through proactive thought leadership, guidance and industry specific templates and material that increase time to value.
My version 3.0 requirements management journey has recently led me to Jama Software as a solutions architect supporting the aerospace and defense vertical. Jama Software develops the Jama Connect requirements solution. In addition to a great requirements management tool, they are industry experts, and provide expert thought leadership and best practice guidance to their clients. This level of knowledge is a key distinguishing factor when searching for a requirements management tool. I am happy to be part of this extremely energetic, client focused company and truly looking forward to this version of my career in requirements management!
Complying with FDA Design Control Requirements Using Requirements Management Principles
Mercedes Massana: So agenda for today is we’re going to talk a little bit about the design controls and what they are. We’re going to talk about requirements management and what that is. And then we’re going to talk about how the two relate to each other. Then we’ll discuss how we can build a good requirements management process and how that process can help us improve compliance to design controls.
Okay. So let’s get started. All right. So by the end of this presentation, hopefully you’ll have a good general working knowledge of design controls. You’re going to understand requirements management and how to evaluate and accept requirements, how to perform bi-directional traceability, how to use requirements attributes to help manage the requirements, and how requirements metrics can help you make better decisions. We’re going to learn how to manage and control requirements changes, and then how to use attributes, especially a requirements credit quality attribute to help us on manage and identify essential requirements and requirements that are critical to quality.
FDA Design Controls
Mercedes Massana: So let’s start with design control background. So design controls have been part of the FDA QSR since 1997. So it’s been a long time. The FDA initially implemented design controls to try to help medical device manufacturers identify deficiencies with design input requirements, to identify discrepancies between proposed designs and requirements, and increase the likelihood that the design transferred to production is going to translate into a device that is appropriate for the intended use and satisfies the user needs. And they did this in relation to having a lot of issues in the field with medical devices. So they thought design controls would improve the quality of the medical devices that were being approved.
In the FDA design control guidance, they state that developing a solid foundation of requirements is the single most important design control activities. So that kind of tells you how important FDA thinks design control requirements management is. So design controls is made up of several elements. There is design and development planning, design inputs, design outputs, design review, design verification, design validation, design transfer, design changes, and design history file.
Mercedes Massana: Now, most of those, even though requirements really falls under design inputs, and that’s what everybody understands by design inputs, most of these items relate to requirements in one way or another. So design outputs, we have to develop design outputs that will conform to design inputs. For design reviews, we’re going to review our design inputs to make sure that they’re appropriate and not conflicting or unambiguous. Design verification will confirm that design outputs meet the design input requirements. And design validation will confirm that the user needs and intended uses are met, which is their another form of design input.
And then design changes, obviously managing requirements changes is important. And obviously all our design inputs or all of our user needs documents or system requirements or product requirements documents will end up in the design history file. And then obviously our deliverables that user needs that we create, or system requirements, product requirements, all become part of our design history file.
Requirements Management
Mercedes Massana: So let’s talk about requirements management. So what is requirements? Why do we need requirements management? Why would we want to do this? Well, if your projects are late because you’re trying to introduce changes at the end, or if sometimes your developers can really figure out what the requirements may mean and they’re making their own interpretation, those are all issues that can be addressed through requirements management. In fact, it is said that approximately for IT projects, which encompass software obviously, that at least 50% of projects are late, or delivered with reduced functionality or over budget.
Mercedes Massana: If you have a good requirements management process, this will improve those statistics and make projects more successful. So what is a requirement? So for IEEE, a requirement is a property that a product must have to provide value to a stakeholder. That’s the IEEE definition. The FDA definition is a condition or capability needed by a user to solve a problem or achieve an objective. So couple of key items here is, something that is needed by somebody, right? So that tells you that anything that goes into your requirements has to have a purpose. Why is it there? And it’s needed to solve a problem. So it has to solve a problem for the user, right? So if it’s something that a software developer thinks is a cool feature, but nobody needs it, then it really shouldn’t be a requirement.
So requirements management process has four main goals. It tries to ensure that there is an understanding of requirements, but all the stakeholders, that they commit to those requirements or approve or agree that those are the requirements that need to be implemented. That we manage requirements changes. And we’ll talk what managing requirements changes means a little later. And then we identify inconsistencies between project work and requirements. And what that means is that you can’t have a project plan that says you’re going to be done in a year if you have 10,000 requirements to implement, right? So you have to have consistency between the requirements and the other deliverables of the project.
So to obtain an understanding of the requirements, first, we need to know who are we solving the problem for? Right? So we need to determine how we identify the stakeholders. So who are those requirements providers, right? Those are the stakeholders. We need to know how we’re going to evaluate the requirements, how we’re going to know if the requirements are good and complete. And then we need to know who needs to approve the requirements and when do requirements get approved. So that’s how we obtain an understanding of requirements.
Then a commitment to requirements is basically that agreement between the different stakeholders that says, if you develop these set of requirements, we’re going to have satisfied customers, that our agreement is usually made through approval of the requirements.
Managing requirements changes is, obviously the one constant in life is change. So requirements will also change. But it’s very important to manage changes so that the rest of the product reflects the impact of those changes, right? Nothing comes for free, and requirements changes usually are either going to cost more, and we’re going to have to add more resources or we’re going to have to add more scheduled, but something will have to be done in order to manage the impact of that change.
Requirements Traceability
Mercedes Massana: And then maintaining bidirectional traceability. This requires that requirements be traced forward from higher level requirements to lower level requirements and that every lower level requirement be able to be traced backwards to its parent or a higher level requirement. Additionally, other elements like design, tests and risks should also be included in our traceability. And later on, I’ll show you a fully elaborated trace matrix that shows the relationship between pretty much every deliverable that we’ll create as part of our development process.
All right. So what’s the connection between requirements management and design controls? So this table will show us a little bit of that. So these requirements management elements relate to design controls as follows. So design inputs are defined as the physical and performance requirements of the device that are used as the basis for device design. So the FDA tells us that design inputs must be appropriate. That we need to address incomplete, ambiguous or conflicting requirements. And that these requirements related to design inputs are addressed by the requirements management element and obtaining an understanding of requirements.
Design outputs are defined as the results of the design effort at each design phase and at the end of the total design effort. The FDA says that design controls must be able to evaluate the design outputs conformed to design inputs, that we must be able to establish acceptance criteria so that we can verify the design outputs conform to the design inputs. And then we identify the essential requirements or essential to proper function requirements. So again, requirements management can help us meet this part of the regulation.
FDA design controls also state that we must identify document, verify, validate and approve design changes before implementation. Additionally, the design control guidance specifies that the trace matrix is a form of verification. So both of these areas are also covered by requirements management. And here, we can see that there is definitely a relationship between FDA design controls and any requirements management process.
Congratulations! Your organization has gained regulatory approval and launched its medical device product. The ‘History’ in Design History File may elicit impressions that all those design and development requirements are now done and considered part of the past. However, several components of the DHF continue as a reference and evolve, including requirements and risk management. Here are 3 ways active management of requirements and risk continues after commercialization:
1: Post-market surveillance
Once your medical device is on the market, post-market surveillance programs, including complaint management processes, must now be exercised. That includes evaluating feedback, determining if it is a complaint, investigating complaints, and determining whether to initiate corrections or corrective actions. As part of this process, requirements and risk management are being used in 2 ways, 1) as a resource to evaluate complaints and 2) a living document to be updated with the experience gained.
As a resource, it is important to reference risk management files to determine if the frequency of occurrence and types of failure modes documented during design and development matches the infield data being gathered. A more frequently occurring failure or new failure mode indicates an investigation is warranted and re-evaluation of the risk. Depending on the outcome, corrective action may be needed.
For example, during design and development, it was determined that a sensor failure leading to customer annoyance occurred rarely, leading to a low risk rating at the time of market launch. The first year on the market, reports of this failure occurred rarely, matching the occurrence rates in the risk management file. Given the low risk and lack of trend, further failure investigation and corrective action were not taken. However, one year later, a change in supplier coincides with a change in occurrence from rarely to frequent, leading to a medium risk. This increase in risk prompts an investigation to determine why the sensor failure rate is higher and to determine corrective actions and controls with the new supplier.
As a living document, the risk management files are to be updated with the observed occurrence rates, new cause(s) of the failure mode of the sensor, mitigations and controls put in place, resulting verifications, and revised risk rating.
2: New Products
Another reason requirements and risk management continue once a product is commercialized is to aid in the development of new products, including line extensions, new models, and next generation platforms and portfolios.
The existing product’s requirements and risk management, supplemented with what is learned from post-market surveillance and other feedback from the field, provide the foundation for new products. A requirements and risk management tool like JAMA Connects® can simplify the management of requirements and risks shared between products to keep teams aligned and prevent requirements or risks being missed during the transfer from one product’s design history file to another. Likewise, line extensions can be more easily incorporated into an existing design history file if requirements and risk management have been properly updated as needed and are accessible.
3: Change Control Evaluation
Change control evaluations is another way management of requirements and risks continue after commercialization. Changes to a product and how it is manufactured occur for many reasons, including replacement of a component that has reached its end of life from a supplier, software upgrades to address bugs, duplication of a manufacturing line, and changes that address complaints.
Changes must be evaluated as to their impact on the form, fit and function of the product, and can have varying degrees of potential impact. Well managed and active requirements and risk management, with traceability to design outputs and verification, become a strong tool for organizations to evaluate the potential impact more quickly.
For example, say a temperature sensor was added as mitigation to prevent overheating of a medical device; overheating that could result in burns to the patient. The sensor, including the necessary accuracy, is listed as a control for the risk of overheating and burns. There’s also a corresponding design requirement, and the sensor and its specification are linked as design outputs. The supplier of the sensor has recently informed the medical device manufacturer that the sensor is reaching its end of life and will no longer be available in 6 months’ time. A change owner is assigned to identify and evaluate a new sensor. This person is most likely not the same engineer who originally designed and selected the first sensor. And that the original engineer may or may not still be with the organization, and may not remember why that sensor was selected. This is where having accessible and well managed requirements and risk management becomes important. The change owner can reference and look up the sensor, see the design inputs and risk with which it’s associated, and understand more quickly the criticality of the sensor and ensure the proper selection and testing are performed on a new sensor.
While change post-commercialization is inevitable, difficult change control management is not.
Management of requirements and risk extends through the entire life cycle of a medical device, including after a device has gained the necessary regulatory approvals and reached the market. Thus, take care in selecting the tools and developing the processes your organization uses for requirements and risk management.
magniX chooses Jama Connect for its ease of use, quick deployment, and to help modernize their requirements management program and demonstrate compliance with standards.
Headquartered in Everett, Washington – located just outside of Seattle – magniX is the leading developer of propulsion systems for electric aircraft, including motors, inverters, and motor controllers.
magniX is working to bring affordable, emission-free, and quieter flights to communities around the world.
More about magniX:
Founded in 2009
Expertise: Leading developer of propulsion systems for electric
aircraft, including motors, inverters, and motor controllers
Recent Awards for magniX:
2020 Fast Company Most Innovative Company in Energy
Finalist 2020 GeekWire Innovation of the Year award
Frost and Sullivan Technology Innovation Leadership Award
With big plans on the horizon, magniX set out to find a modern requirements management solution that could help them make their ideas a reality.
Initially, the team was using Microsoft Excel and Word to manage their requirements, but they quickly realized it was only a temporary solution. The limitations and risks of using static requirements in this manual process were becoming apparent.
As they began their search for a requirements management solution, they knew the following things were most important:
While the evaluation process was short and led to the selection of Jama Connect®, the magniX team seriously evaluated multiple systems.
Jama Connect stood out for the following reasons:
Jama Connect was a more modern, easy-to-use solution with the powerful features they required
Jama Connect allowed for the magniX team to easily customize the solution to meet their needs, without requiring complex custom scripts to be written
The interface in Jama Connect was intuitive
“The ability to easily customize Jama Connect to fit our needs without custom scripts is a major advantage over other solutions,” said Carlos Souza, Head of Energy Storage Systems at magniX. “Jama Connect just allows us to achieve more with less work.”
Ease of use and quick deployment
In addition to ease of use and quick deployment, ultimately, the magniX team selected Jama Connect because the solution:
Allows for end-to-end traceability that gives the magniX team the ability to control requirements from the product level down to implementation in one single database
Is powerful, intuitive, and easy-to-use requiring very little training to see wide adoption and ROI
Enables configuration control throughout all stages of development
“One of the main reasons we selected Jama Connect is the ability to provide configuration control for all the requirements and maintain them in one database. It allows everyone in the company to have visibility into the requirements and their status,” said Souza.
Jama Connect helps to form a digital thread through development, test, and risk activities — enabling the magniX team to have end-to-end compliance, risk mitigation, and overall process improvement. Moving from static requirements (in disparate teams, activities, and tools) to Living Requirements™ management was the key to them achieving real-time, cross-team collaboration and coordination. And, because of its easy, intuitive, modern user interface, broad adoption is made simple.
Jama Connect is very intuitive and easy to get up and running. We received training, and the rest was very fluid and straight forward,” said Souza. “Teaching others how to use the tool internally is very easy.”
Requirements management (RM) is a challenge for many companies, partly due to the ambiguity involved in software development. First, you must understand the client’s requirements. Second, you must match those requirements to critical processes.
RM is a component of requirements engineering (RE), which bridges the divide between a client’s needs and what developers create. When done well, RE has the ability to create a solid framework for software development, which is critical since poor software engineering requirements management is a root of many project failures.
A CIO magazine study found that “Analysts report that as many as 71% of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure.”
In 1999, NASA built the $125 million Mars Climate Orbiter probe. The probe failed because it entered orbit 100 kilometers too close to Mars. The source of the error was incompatible specifications; an important component of RE.
Understanding the details involved in requirements engineering and best practices can set you on the path to successfully meeting client expectations.
What is requirements engineering?
Clients have a long list of goals when creating new software, and RE provides a framework for meeting those goals. Important needs are inventoried and transformed into a detailed set of requirements. Requirements development dictates future development activities and creates a blueprint for success.
The terms requirements management and requirements engineering are often used interchangeably, but they are different. RM is one piece of requirements engineering, and getting it right makes all the difference.
RE ensures that the problem a client wants solved is clearly defined and the solution is both accurate and effective. Essentially, RE transforms a real-world problem into a highly functional software solution.
The 4 steps of the requirements engineering process
The requirements engineering process has many potential pitfalls. Strengthening your RE process enables you to avoid many common challenges. The process serves as a compass, guiding you in determining the exact deliverables and doing so with greater accuracy. All important parties are on the same page about what steps need to be taken to achieve the desired outcome. Strengthen your RE process by considering the following:
Elicit requirements. Elicitation is about becoming familiar with all the important details involved with the project. The customer will provide details about their needs and furnish critical background information. You will study those details and also become familiar with similar types of software solutions. This step provides important context for development.
Requirements specification. During the specification phase, you gather functional and nonfunctional project requirements. A variety of tools are used during this stage, including data flow diagrams, to add more clarity to the project goals.
Requirements verification and validation. Verification ensures the software is implementing the right functions. In contrast, validation ensures the software is built to the customer’s requirements. If the requirements don’t go through the validation stage, there is the potential for time-consuming and expensive reworks.
Requirements management. During RM, you’re matching all the relevant processes to their requirements. You will analyze, document and prioritize the requirements – and communicate with relevant stakeholders. Any requirements that need modification are handled in an efficient and systematic manner.
As you implement the different components of RE, it also helps you get a sense of what should be excluded from requirements. Understanding this will help you focus more accurately on developing requirements and better meeting client expectations.
What information should be excluded from the requirements?
Requirements should be viewed as addressing a problem, but not necessarily as providing a solution. A requirement should clearly state what you want to solve, not how you want to solve it. Let’s take a look at guidelines for good requirements:
The requirement accurately defines the need of the stakeholder.
The requirement is testable.
A requirement needs to be clear and understandable, without the risk of ambiguity. An important step in developing good requirements is the review process. Does the requirement accurately express the needs of the stakeholders? Make sure to build in enough client reviews so that you can get early feedback and adjust as needed.
There are many challenges that may occur as you develop your RE framework. Understanding potential issues can help you avoid them. Consider the following as you develop your processes:
Avoid scope creep. There is a temptation to add “just one tiny new requirement” to make the client happy. But these little changes add up and may have an impact on future activities, such as testing, documentation and more.
Resist the urge to “over-engineer.” Over-engineering can be tempting, especially when you want to make sure everything is just right for the client. But this overzealousness can backfire. Adding a little extra code because “I’m doing this, I may as well do that” might seem logical, these changes can create a ripple effect, putting requirements at risk in the future.
Build in enough feedback and reviews. Early feedback is essential to a project’s success. Build in frequent reviews and solid traceability to get feedback often and early.
Search for all the important stakeholders. You might think you’ve included all the important stakeholders, only to learn you missed one later on. Invest time early in the process to find any and all important stakeholders in order to avoid expensive reworks later in the process.
Identify potential resistance early in the process. Resistance can be an invisible but serious project problem. Learn to identify resistance early in the process so that you can work through it efficiently and early, getting everyone on the same page.
Awareness about these potential pitfalls can save you time, money and resources during the RE process. Also, look at your existing processes and whether they include enough traceability. Ensuring that deliverables meet requirements, for example, is much easier if every requirement is linked to at least one test. And traceability is an essential part of this process.
Engineers can then invest their energy into requirements that are failing the test and get the project back on track quickly.
Leveraging the right tools for success
Requirements engineering is critical to the success of a project because it tells everyone involved with the project what needs to be done. A project manager, who schedules tasks, can do so based on more accurate requirements. A requirements management software tool can greatly support successful RE, as it enables more efficient and optimized product and system development.
This type of tool can provide:
Clarity and visibility. Get broader visibility into what you’re building and why.
Live traceability. Ensure product quality and improve change management with complete traceability.
Decision tracking and fast reviews. Conduct virtual reviews of requirements, test cases, user needs and more.
Real-time collaboration. Immediately note and prioritize important decisions, pull in the required stakeholders and reference historical context to eliminate communication errors.
The right tool can help you transform RM as you easily track, review, sign off on and truly understand how and why you did certain things. As a result, you can streamline your product development process and increase efficiency, understand and respond to change, and establish a higher level of clarity and visibility.
See how Jama Connect can help with requirements engineering by downloading our solution overview.
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
Mitigate risk
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.
Planning Stage
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:
Unique Identifier
Rationale
Owner
Type
Definition status
Priority
Criticality
Compliance
Version number
Change history
Trace data
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.
Alternatively, working with baselines in a requirements management solution allows baselines to be defined as a subset of the requirements already stored in the database. This streamlines the process from prioritization through stakeholder sign off.
Requirements development stage
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 Live Traceability™ to:
Easily determine the impact of change
Automate compliance
Enable end-to-end process improvement
Increase productivity
Reduce product risk
Increase quality
Requirements analysis
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
The challenges above are real and mastering them can have significant impact on development timelines and budget. Developers in regulated industries — like automotive, aerospace, medical device, government, and industrial manufacturing — are further challenged by the need to prove compliance with regulations and standards.
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
Managing risk
Increasing efficiency and optimizing processes
Easily understanding and responding to change
Improving traceability
Streamlining and accelerating reviews
Enabling real-time collaboration and iteration
Saving time
Improving quality
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.
From our experience, and what we hear from customers, the most important features of a requirements management system are:
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.
Requirements analysis is a critical part of the requirements definition and management process in software development. The purpose of requirements analysis is to be sure all product requirements accurately represent stakeholder needs and requirements. When executed correctly, requirements analysis results in a set of product requirements that, when met, will result in a deliverable that matches stakeholder expectations.
What is requirements analysis?
The requirements analysis is the process of discovering stakeholder needs and requirements for a software application being developed. It confirms accurate capture, interpretation, and representation of the customers’, users’, and other stakeholder needs and transforming those needs into a set of requirements for a product. For optimal results, the set of product requirements must be verified that they have the characteristics of well-formed requirements (e.g. needed, unambiguous, complete, consistent, correct, feasible, verifiable) and validated that they represent the intent of the needs from which they were transformed.
Best practices for requirements analysis
Stakeholders can communicate their expectations in several forms – needs and requirements. 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.
It is important to define and understand the stakeholder needs and requirements before defining the product requirements to which the product will be designed and built to. 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. The resulting product requirements represents what the product must do in order for the needs to be met. If needs describe the “what,” product requirements define the “how.”
Requirements traceability is of the utmost importance to the requirements analysis process. It is used to ensure that each requirement clearly communicates the intent of their source. Without traceability, it’s nearly impossible to know if the software product meets stakeholder needs, drivers and constraints, goals, and objectives. Requirements analysis could be executed perfectly, but without requirements traceability to their source, there would be no way to prove you have the right set of requirements.
Therefore, a best practice of requirements analysis is to ensure that each requirement is traceable to all corresponding artifacts. These artifacts include not only their source but also downstream artifacts including the design, product verification planning and product validation planning.
Another equally important best practice for requirements analysis is to execute a predetermined process. Carefully performing each step can be the difference between a software product’s success or failure to meet stakeholder needs.
Generally, there are seven steps in the requirements analysis process.
Identify stakeholders: the first step is to pinpoint exactly who the key stakeholders are for the project. This includes internal and external customers, users, regulatory agencies, and stakeholder involved in the development of the product. It is the stakeholders that are the source of needs and requirements.
Elicit stakeholder needs and requirements: during this step of the requirements analysis process — also called needs and requirements gathering — teams work with the stakeholders to identify their needs and requirements.
Model needs and requirements: with the initial sets of stakeholder needs and requirements, teams can create visual representations or diagrams of the needs and requirements as part of their analysis to inform the definition of the product requirements, use cases, and user stories. These visual representations and diagrams are used to solicit feedback from stakeholders, iterate, resolve issues, conflicts, and inconsistencies before defining and baselining the product requirements.
Retrospective: the project team reviews the data and information gathered during elicitation, diagraming and modeling. Of particular interest is understanding the drivers and constraints to better understand feasibility and risks associated with developing the product, assess whether anything has been missed and establish a budget and schedule.
Define an integrated set of needs: The project team derives an integrated set of needs that represent the stakeholder expectations along with goals, objectives, and drivers and constraints, and stakeholder requirements.
Define product requirements: at this point, teams review the resulting integrated set of needs and stakeholder requirements and transforms them into a set of requirements for the product to which the product will be designed and built. It is important that the resulting requirements are high-quality requirements having the characteristics of well-formed requirements. It’s wise to make sure that all team members know how to write good requirements.
Sign off and baseline: the final step of the requirements analysis process is to get sign off agreement from all key stakeholders (or representatives from stakeholder groups) identified in step one for the integrated set of needs and resulting set of product requirements. This is a formal contract that lets everyone know what the product will be verified and validated against, the cost, and schedule. It helps eliminate surprises and scope creep later in the development process.
Common challenges during requirements analysis
These steps above will likely need repeating, as the most common challenge of requirements analysis is that requirements may change throughout the software development process. As the team implements various features, the above steps should be repeated for each feature; doing so will often result in additional needs and requirements. The risk of change can be reduced by following the above steps and getting sign off at the beginning of the project for not only the integrated product but for each feature to be provided by the software application.
One reason for change is a failure to include all relevant stakeholders. If the focus is just on the customers or users, needs and requirements associated with other stakeholders will be missed. Given the number of different stakeholders, there will be inconsistencies, conflicts, and issues. Failure to deal with these early, will result in change. The use of various visualizations, diagrams, and models before defining the integrated set of needs and product requirements helps ensure completeness, correctness, and consistency. Again, failing to do this before defining the set of product requirements will result in change and resulting costly and time-consuming rework.
In other situations, it may be that some stakeholders won’t know exactly what they need until they see the software in action, or project constraints may necessitate changes in the solution. In any case, agile teams are constantly iterating and updating design. This means the process of evaluating needs and requirements almost never ends. The diagraming and modeling step above is a great tool that can be used to interact with the stakeholders to better understand their needs. The goal is to be as comprehensive as possible the first time through to get a big-picture view to minimize change and resulting rework.
The pros and cons of various diagraming and modeling techniques
A variety of techniques are available during elicitation, diagraming, and modeling—some are more advantageous than others. Here we review some popular techniques and point out advantages and disadvantages of each.
Flowcharts
Flowcharts show the sequential flow and control logic of a set of related activities, and can be used to represent data flows, system (software application) interactions, both internally and externally, and more.
Easy to create and understand for all team members.
Highlights critical process attributes.
CON
Change management is time consuming, as flowcharts need to be redrawn to accommodate process alterations.
Complex processes result in dense flowcharts that can be difficult to understand.
Data flow diagrams
These show the flow of information through a system. Data flow diagram components include the process, flow, store, and terminator.
PRO
Can be created in the requirement elicitation step of the analysis process to define a project’s scope.
They can be understood by technical and nontechnical audiences.
CON
It can be time consuming to create, particularly for complex software applications.
Physical considerations are not included in a data flow diagram.
Role activity diagrams
Role-activity diagrams show business and software processes as a progression of actions conducted by role. Roles are identified by activities and grouped into responsibilities. They can be used for describing use cases, workflows, business processes, or software protocol.
PRO
Illustrate the individual steps in activities, as well as the order in which they are to be performed.
Supports communication across roles.
CON
Each workflow requires a new diagram else they become too unwieldy. This makes it difficult to get a full view of the system.
These diagrams do not provide detail about how objects behave or collaborate.
Unified Modeling Language creates diagrams used for modeling specification, development, visualization, and documenting in the requirements analysis process. UML diagrams can be two types of models: a behavioral model, which informs on what the software application will do, and a structural model, which provides insight on the parts that make up the system.
PRO
There are a variety of UML diagrams to choose from, like use case, sequence, interaction, class, and more.
Can be directly inputted to a requirements tool.
CON
UML diagrams must be synchronized with software code, which requires additional work and ongoing maintenance.
Complex processes result in overcomplicated and confusing diagrams.
Business process modeling and notation (BPMN)
BPMN is based on a flowchart technique like activity diagrams from Unified Modeling Language (UML). It uses a unique standard of notation to create graphs including flow objects, connecting objects, swim lanes, and artifacts. These help simplify understanding of the business process answering questions regarding who performs the activities and the data elements required to do so.
PRO
Designed to be understood by all business stakeholders yet represent complex process semantics.
Supported by most modeling tools.
CON
Only supports concepts of modeling applicable to business processes; non-process purposes are out of scope.
Gantt Charts
In requirements analysis, Gantt charts help with coordinating, planning, and tracking project tasks. Tasks to be performed are listed along the vertical axis. The horizontal axis lists the time allotted for the given task and the person or team performing the functions. Gantt charts give a visual representation of the project’s schedule and resources needed.
PRO
A single chart can track many activities, even those happening in parallel.
It provides a realistic view of how long the project will take and what resources are needed at various points in development.
CON
A single view of all the tasks is not available.
The time allotted for a task is not representative of the amount of work involved in its completion.
Complex software projects would require an exorbitant number of tasks making the Gantt chart extremely difficult to create and nearly impossible to update consistently.
Integrated definition for function modeling (IDEF) diagrams
IDEF is a family of modeling languages that cover a wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design, and knowledge acquisition.[i] The goal is to gain an understanding of an organization’s systems by exploring process function relationships to child/parent systems.
PRO
IDEF can be used in almost any context, industry, and technology area.
Diagrams are easy to digest for both technical and nontechnical team members.
CON
It can be difficult to integrate different IDEF techniques.
Designed as a business analysis tool, it is not a very good software application development methodology.
Gap analysis
Also known as need analysis, need assessment, or need-gap analysis, this technique helps analyze software application performance gaps to verify if business requirements are successfully met. Gap analysis conveys the difference between the current state and the target state, identifying where the project stands and what is yet to be done.
PRO
Gap analysis ensure the business requirements or data requirements have been met as desired.
It helps uncover which areas need focus or additional resources.
CON
Success depends on the skills of those performing the analysis, and while gaps may be uncovered, their true causes may be left unsolved.
Focus of the various diagraming and modeling techniques
Some requirements diagraming and modeling techniques are better for analyzing business needs and requirements while others are better suited for discovering user needs and requirements.
BPMN is strictly a technique for uncovering business needs and requirements which must be addressed within the set of product requirements, with excellent results. Gap analysis is also great method for understanding business requirements. As noted, it can help determine the difference between where a business is and where it wants to be. The result may initiate a series of user requirements to help the business close that gap.
While not covered above, a customer journey map is also beneficial for discovering business requirements. A customer journey map is a “voice-of-the-customer” VOC story that shows the customer’s relationship with the business over time. It helps identify sources of frustration on the part of the customer, which can inform user requirements to improve those pain points. Note: limiting this analysis to just a single class of stakeholders can result in missing needs and requirements. A more inclusive approach is “voice-of-the-stakeholders” VOX that shows relationship of all relevant stakeholders with the business over time. It helps identify sources of frustration on the part of all stakeholders, not just the customer, which can inform the definition product requirements to improve those pain points.
The discovery of user needs and requirements benefit from techniques like the data flow diagram. As mentioned, they can be created early and give a high-level of the data flow within a particular process. Use cases and user stories are also great tools for soliciting software requirements from a user perspective, as they maintain focus on what the user needs, not what the product does to meet those needs and wants.
Streamlining the requirements analysis process
The result of the requirements analysis phase of requirements definition and management, is the diagrams and models used as part of the analysis, an integrated set of needs, and a set of product requirements that are inputs to the design process. The set of product requirements define the features and intended behavior of the software application being created such that when implemented within the design, the stakeholder needs are met. Having a baselined set of product requirements serves to crystalize project specifics and mitigate wasted time and potential rework.
While some organizations will communicate this set of product requirements in a document form (e.g., a Software Requirements Specification (SRS)), the increasing trend is to manage the 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.
With Live Traceability™ and digital thread, Jama Connect helps teams collaborate in real time. This mitigates the risks of using documents for requirements analysis. It also enables traceability automatically so the hard work performed can be proven—even with the most complex, highly regulated software products.
G2 Names Jama Connect® the Leader in Requirements Management Software in their Summer 2021 Grid® Report
We engineer with customer success at the forefront of everything we do. At Jama Software, we are dedicated to providing a requirements management platform that enables our customers to effectively and efficiently eliminate silos, achieve compliance, and mitigate risk across the product development lifecycle. We are focused on building the ideal platform to help them set solid foundations and processes for building the innovative, complex products, systems, and software of the future. If we can help them do that, then we’re succeeding.
And based on our customers’ most recent reviews of Jama Connect on G2, it appears as though we are indeed succeeding. We are proud and honored that our customers have spoken again, and this time, Jama Connect was named, by customers, as the overall leader (#1) in requirements management software!
“Jama Connect is an application that easily connects people in engineering and managing requirements. The fact that it is easy to share information and execute processes even when the team is not co-located (geographically dispersed). Changes are properly tracked and people notified. It is also easy to organize, review and monitor the review process.”
-From review collected and hosted on G2.com, Senior Systems Engineer, Mid-Market
In addition to the honor of being named the leader in requirements management software, Jama Connect was listed as a leader for ALM software tools in their G2® Grid for ALM Suites for the 3rd consecutive reporting period.
Thank You to Our Customers
By receiving hundreds of detailed reviews from our customers, we have been named a leader in multiple G2 categories. We are proud to showcase that we were awarded several additional medals for Summer 2021, including:
Users Love Us – For products that have collected 20 reviews with an average rating of 4.0 stars.
Fastest Implementation – For products that had the shortest go-live time in their category.
Easiest Admin – For products that earn the highest Ease of Admin rating in their category.
High Performer – For products that have High Customer Satisfaction scores.
Leader – For products that are rated highly by G2 users and have substantial satisfaction and market presence scores.
Momentum Leader – For products that rank in the top 25% of their category’s products by their users.
“Efficiency, Visibility, Traceability, Peace of Mind.”
“One of the best requirements tools out there.”
“I’ve used Jama for over five years and it’s never once failed me.”
“Excellent customer support!”
-Additional comments from various reviewers collected and hosted on G2.com
The Users Love Us category, in particular, is a testament to our commitment to our customers. We live vicariously through the successes of our customers. We strive to provide the highest level of service possible and look forward to continuing to provide our clients with the support and expertise they need to reach and exceed their product development goals.
The “Fastest Implementation” badge is a reflection of our purposeful, high-velocity onboarding, which gets customers up and running quickly. Our in-house team of experts, core consulting, and training includes alignment and launch services, adoption services, and optimization services which help our customers achieve fast adoption and quick time to value when they implement Jama Connect.
“We came for a tool and gained a comprehensive solution with a strong partnership. It is a very well thought out and engineered solution with some very good “out of the box” regulatory reports. JAMA Connect is very intuitive and easy to use by our teams. Besides the tool solution, I also really appreciate the JAMA Software team that understands our core business and helps us along the way from a technical standpoint. Finally, the JAMA community website, as well as the regular webinars offered, are extremely value-add additional resources.”
We are so grateful to our customers who took the time to provide open and honest feedback and review their experiences using Jama Connect for requirements management. We work hard to provide our customers with the expertise, attention, and resources needed to meet their goals, and we’re proud to be recognized in these categories and as the overall leader in requirements management software.
So, from all of us at Jama Software to all of you, thank you!
G2 scores products and sellers based on reviews, gathered from their user community, as well as data aggregated from online sources and social networks. Together, these scores are mapped on their proprietary G2 Grid®, which can be used to compare products, streamline the buying process, and quickly identify the best products based on the experiences of your peers.
Requirements gathering is the process of understanding what you are trying to build and why you are building it. Requirements gathering is often regarded as a part of developing software applications or of cyber-physical systems like aircraft, spacecraft, and automobiles (where specifications cover both software and hardware). It can, however, be applied to any product or project, from designing a new sailboat to building a patio deck to remodeling a bathroom.
Three Main Subprocesses of Requirements Gathering
The key ingredients of the requirements gathering process are three overlapping subprocesses: requirements elicitation, requirements documentation, and requirements understanding.
Requirements elicitation is the process of asking for and collecting top-level requirements from all relevant stakeholders. Effort should be made to account for the needs of customers, their users, the internal stakeholders within your own company, and your key suppliers.
Requirements documentation organizes the input from the requirements elicitation process into whatever format is appropriate for your organization. This formatting may include:
User stories
Functional decompositions (especially for complex cyber-physical systems)
Feature descriptions
These will be collected in a top-level requirements specification like a product requirements document (PRD) or a system specification. The purpose of this top-level specification is to make those stories and descriptions available to all members of the project team.
Requirements confirmation is the process of making sure all stakeholders and team members have a common understanding of what you’re trying to build. This involves reviewing and refining the requirements. It will very likely require additional elicitation and revision of the documentation as well.
What are the Benefits of Requirements Gathering?
Beyond the obvious advantage of having requirements with which to work, a good requirements gathering process offers the following benefits:
Greatly improves the chances that customers and users will get what they wanted. Stakeholders often have difficulty putting into words exactly what it is that they need. You’re going to have to help them, and it’s going to take some digging.
Decreases the chances of a failed project. A frequently heard lament following unsuccessful projects is, “The requirements weren’t clear.”
Reduces the overall cost of the project by catching requirements problems before development begins. Requirements that are ambiguous or not fully understood often result in costly scrap and rework. Numerous studies have shown that the cost of fixing requirements errors rises exponentially over subsequent phases of development.
One of the reasons projects fail due to poor requirements is this: requirements gathering isn’t easy. Here are some of the main challenges:
Finding All the Right Stakeholders
Projects often have “hidden” stakeholders. It’s important to uncover them. The group you canvas should include more than just the obvious decision-makers. Don’t forget to talk to customer support reps, maintenance technicians, and others who come into direct contact with customers. They are themselves, in effect, users of your existing products.
“Disgruntled users who are forced to use a system every day that was designed without their input are a key ingredient for a failed project,” says Jordan Hirsch, Director of Innovation at Phase2 Technology.
Understanding What Stakeholders Really Want
Your stakeholders may not have a clear vision of what they want. They may not be able to tell you a complete story. They may have hidden pain points or desires, unstated goals, or assumptions. You’re going to have to ask a lot of probing questions and compare answers. You’re also going to have to go through several iterations of your process to arrive at a consensus.
Planning for Change
Throughout the requirements gathering process, you’re going to come across questions you forgot to ask and things stakeholders forgot to tell you. You’ll come up against shifting priorities and problems encountered during implementation.
It’s wise to have a plan for dealing with those changes. You’ll need to allow time for addressing problems, documenting new requirements, and conducting additional reviews.
The requirements gathering process consists of six steps. Three of those (steps three through five—the bulk of the process) we’ve already mentioned as the key subprocesses of requirements gathering. The full six steps are:
Identify the relevant stakeholders
Establish project goals and objectives
Elicit requirements from stakeholders
Document the requirements
Confirm the requirements
Prioritize the requirements
It is important to note that while these steps are typically initiated in the order listed, there is a great deal of overlap and iteration among them. It may, therefore, be better to think of them as subprocesses rather than steps as we look at each one individually.
Identify the Relevant Stakeholders
Find qualified representatives from each relevant stakeholder group. Depending on your project, these may include:
Customers stakeholders
Decision-makers
Users
System administrators
Other impacted customer departments
Internal stakeholders
Executives
Engineering
Marketing
Sales
Customer support (including on-site maintenance teams, if applicable)
Key suppliers
Distributers and other partners
Remember to search for “hidden stakeholders.” Ask probing questions in early meetings, before you begin eliciting requirements. Identify all stakeholder groups who need to be involved. Ideally, you want input from every groupwho has skin in the game; give them all the opportunity to state their needs.
Establish Project Goals and Objectives
What are you trying to achieve with this new product or project? What are the overall outcomes your customers want from the product? What are your company’s business goals? What are the actionable, measurable objectives you need to achieve to realize those goals and outcomes?
Write them down. State them clearly, and get all your stakeholders to sign off on them. Your goals and objectives will act as a framework for your decision-making.
Each requirement you write should help satisfy a project objective and accomplish a goal. If it doesn’t, you should either discard it or made it a candidate for a future release.
Elicit Requirements From Your Stakeholders
This is the first of three requirements gathering subprocesses which are highly iterative and overlapping. Even in an agile environment, you are likely to go through several cycles of elicitation, documentation, and review/confirmation before you achieve a workable specification to begin development.
Elicitation can be performed in several ways. Time-tested techniques include surveys, questionnaires, and interviews. Interviews and follow-up meetings will be prevalent during later iterations.
Be sure to listen actively during interviews. Ask probing questions and take copious notes. Afterward, organize your notes and follow up as necessary. Document each exercise or encounter thoroughly.
As soon as requirements begin to emerge from your elicitation process, begin documenting them.
Write them down and collect them in whatever format your organization has agreed upon. That could be a product requirements document (PRD) of your company’s design, a government-mandated system requirements specification, a vendor-supplied requirements management (RM) tool like Jama Connect, a spreadsheet, a database, or any other appropriate repository your entire team can access.
What’s most important is that the requirements documentation…
Can be easily navigated and understood by your team
Is available for review by all stakeholders
Provides a facility for traceability to other documentation.
Templates are extremely useful, both for the specification as a whole and for individual requirements. Solid, battle-tested templates and standardized formats help provide clarity and aid navigation.
Confirm the Requirements
Review the requirements with all stakeholders. Make sure the requirements clearly capture what was intended and that all parties have a common understanding of each of them. If you find any ambiguity in a requirement, revise it.
You should also validate your requirements through prototyping and testing, where possible. Modern prototyping tools make it fast and easy to create a working model of your specification. You can then use that model to perform feasibility, usability, and product concept testing.
Get stakeholder sign-off on individual requirements as you get them nailed down. Do the same for the specification as a whole during a final review.
Prioritize the Requirements
Most engineering development programs run into unexpected challenges along the way. Unanticipated obstacles are encountered. Schedules slip. Priorities change. It’s important to be able to adapt to those challenges and changes.
That’s why it is crucial to prioritize your requirements based on how each will impact your goals and objectives for your release.
Many product managers prioritize features by tagging them with labels, such as “must have,” “high want,” and “nice to have.” But it’s also important to rank order each requirement within those categories. There are two reasons for this.
The first is time to market. Schedules often slip. When they do, you may need to trim features and requirements to meet your release date. You don’t want your team implementing the easiest requirements first only to find that there’s not enough time to complete all your must-haves.
The second reason is that requirements evolve. During implementation, you’re likely to discover new needs. Some may be critically important and supersede existing requirements in terms of priority. You need to know where those new requirements fit in your pecking order. If you don’t, less important factors will determine what gets implemented first, which may have an adverse impact on your product’s success.
Beware of simple, broad requirements. Don’t assume you know exactly what they mean. Above all, don’t assume all your stakeholders interpret those requirements in the same way.
Broad statements like, “The site shall have a blog” can mask a host of underlying assumptions. Scrutinize such requirements. Ask lots of questions. How will posts be displayed? How should authors be managed? How about comments, categories, tagging? Should there be an RSS feed?… and so forth.
Cross-check the answers you receive. Then come up with a set of more specific, verifiable requirements that everyone can agree upon.
Focusing on HOW Instead of WHAT
Requirements address two things. The first is WHAT the product must do (the functional requirements). The second is the necessaryconstraints on how the product does what it does (the non-functional requirements).
Requirements should not address HOW the product does what it has to do. In other words, your specification should be as implementation-agnostic as possible, within the constraints of the non-functional requirements.
During requirements elicitation, try not to think about how you’re going to implement the product. Forget about the latest technology engineering is obsessed with, your software team’s tool du jour, and any features you think are missing from the product baseline. Focus instead on your stakeholders’ needs.
Listen to what your stakeholders are saying first. Then gather, review and refine your requirements. Finally, once you’ve done all that, find the gaps in your baseline, and determine which technologies will deliver what your customers and stakeholders really want.
Insufficient Consultation With Stakeholders
Perhaps the biggest mistake systems engineers and product managers make in gathering requirements is failing to adequately consult with their stakeholders. Stakeholder consultation has several facets.
First, it is critically important that you drill down (and follow up) with each stakeholder group to fully understand their needs. Failure to do so is one of the leading causes of requirements failures.
A second important facet is transparency. Clean up your notes and share them after every interview, meeting, and survey. The easiest way to do this is through a modern RM tool to which all team members have access. Tools like Jama Connect allow you to attach notes to the requirements themselves for traceability purposes. This greatly increases the speed of the process and simplifies the review task.
The third potential pitfall in this area is insufficient review. Be sure to hold reviews where stakeholders can review the requirements, provide feedback, voice objections, and defend their positions. Open discussions involving all concerned stakeholders can help uncover and correct requirements flaws and achieve consensus.
Finally, get all your stakeholders to sign off on the requirements to acknowledge that they understand them and that the requirements are sufficient for them to do their jobs. Be sure to make it clear to the stakeholder what his or her signature means.
Requirements Gathering for Agile Development
What’s different about requirements gathering for Agile?
First off, agile teams expect to move fast. So, their requirements management solutions must meet their developers’ need for speed.
Transparency is another priority. Requirements documentation must be constantly up-to-date, easily annotated, and provide clear traceability.
Both of these needs make Word documents and Excel spreadsheets poor RM choices for agile teams. Their static nature makes them tedious to update and cumbersome to share. Those drawbacks make it difficult to give everyone fast access to the latest configuration and keep them all on the same page. Plus, docs and spreadsheets don’t provide native features for annotation and traceability.
RM products like Jama Connect help Agile teams streamline requirements gathering and collaboratively manage requirements in real-time throughout the ALM product development process.
Are you working in an Agile development environment?See how Jama Connect can streamline requirements gathering and management by downloading our datasheet.
