Tag Archive for: requirements

This image shows a bullseye target, graph, and money to show that change impact analysis is beneficial and that best practices help make goals.

Best Practices for Change Impact Analysis

Impact analysis is a key aspect of responsible requirements management. It provides an accurate understanding of the implications of a proposed change, which helps the teams make informed business decisions about which proposals to approve.

The analysis examines the proposed change to identify components that might have to be created, modified, or discarded and to estimate the effort associated with implementing the change.

Skipping impact analysis doesn’t change the size of the task. It just turns the size into a surprise.  In product development surprises are rarely good news. Before a developer says, “Sure, no problem” in response to a change request, he or she should spend a little time on impact analysis.


RELATED: A Guide to Good Systems Engineering Best Practices: The Basics and Beyond


Impact Analysis Procedure

Impact analysis has three aspects:

  1. Understand the possible implications of making the change. Change often produces a large ripple effect. Stuffing too much functionality into a product can reduce its performance to unacceptable levels.
  2. Identify all the files, models, and documents that might have to be modified if the team incorporates the requested change.
  3. Identify the tasks required to implement the change, and estimate the effort needed to complete those tasks.

Traceability data that links the affected requirement to other downstream deliverables helps greatly with impact analysis. On complex projects with thousands of artifacts, to manually determine what and who is affected by a change is time-consuming and error-prone. Alternatively, you could adopt a product development solution like Jama Connect, which includes built-in functionality for end-to-end traceability and impact analysis, and automatically highlights the items and people that are impacted when a change occurs.


RELATED: When Evaluating Product Development Software Tools, Not All Cloud is Equal


Whichever route you take, understanding the impact enables teams to quickly and accurately respond to change requests. The team can be responsive while maintaining control over the scope and customer expectations.

Lastly, impact analysis is essential on projects where quality and safety are an issue such as in healthcare, automotive, and aerospace projects. In these situations, it’s critical to understand the specific set of requirements and features that need to be retested after a change is implemented.

Steps in a typical impact analysis process look like this:

  1. Identify the sequence in which the tasks must be performed and how they can be interleaved with currently planned tasks.
  2. Determine whether the change is on the project’s critical path. If a task on the critical path slips, the project’s completion date will slip. Every change consumes resources, but if you can plan a change to avoid affecting tasks that are currently on the critical path, the change won’t cause the entire project to slip.
  3. Estimate the impact of the proposed change on the project’s schedule and cost.
  4. Evaluate the change’s priority by estimating the relative benefit, penalty, cost, and technical risk compared to other discretionary requirements.
  5. Report the impact analysis results to all stakeholders so that they can use the information to help them decide whether to approve or reject the change request.

In most cases, this procedure shouldn’t take more than a couple of hours to complete. This may seem like a lot of time to a busy developer, but it’s a small investment in making sure the project wisely invests its limited resources. If you can adequately assess the impact of a change without such a systematic evaluation, go right ahead; just make sure you aren’t stepping into quicksand.


RELATED: A Guide to Good Systems Engineering Best Practices: The Basics and Beyond


Money Down the Drain

What can happen if you don’t take the time to perform impact analysis before diving into implementing a significant change request?

Imagine two developers on your team estimate that it will take four weeks to add an enhancement to one of your product lines. The customer approves the estimate, and the developers set to work. After two months, the enhancement is only about half done and the customer loses patience: “If I’d known how long this was really going to take and how much it was going to cost, I wouldn’t have approved it. Let’s forget the whole thing.”

In the rush to gain approval and begin implementation, the developers didn’t do enough impact analysis to develop a reliable estimate that would let the customer make an appropriate business decision. Consequently, you waste several hundred hours of work that could have been avoided by spending a few hours on an up-front impact analysis.

Learn how a requirements management solution eliminates many of the budget-draining headaches of product development in Karl Wiegers’ paper, “Getting the Most from a Requirements Management Tool.”

RELATED



Requirements Management Plan 

Product success depends upon the successful project management of the product’s requirements. Effective requirements management, in turn, requires thoughtful planning. 

 A requirements management plan describes how you will gather, analyze, document and manage the requirements of the project. It should describe how you intend to gather the high-level project and product requirements from project stakeholders, industry standards and governmental regulations, as well as the more detailed product requirements you will collect and develop over the project lifecycle. Your requirements management plan should also specify how you will manage changes to requirements after they have been approved. 

Your requirements management plan is a tool for communication. It provides all your project’s stakeholders with a common understanding of how the product’s requirements will be managed to ensure success. 

In this article, we’ll describe the requirements management planning and the recommended components of a requirements management plan. 

What is Requirements Management Planning 

Requirements Management Planning is the process of documenting how you will gather, analyze, document and manage the requirements of a project, manage changes to requirements once they have been approved, manage the configuration of the requirements documentation, and track verification of the project’s requirements. 

Components of a requirements management plan 

A solid requirements management plan will be composed of several components. Here, we’ll describe our recommended sections. Depending upon your industry and organization, not all of these sections may be applicable to your situation. 

Project overview 

Briefly describe the purpose of the project. Explain the need the product will fill for the customer or target market and how its development will benefit your company. Mention important goals for the project and any notable constraints that may have been imposed upon it.  

Roles and responsibilities 

This section lists the roles of those who will be involved with managing the requirements through the rest of the project lifecycle, along with the responsibilities of each role. 

Typical roles include: 

  • Project manager 
  • Lead analyst / lead requirements engineer 
  • Analyst / requirements engineer 
  • Stakeholder 

The project manager typically has overall responsibility for managing the scope of the requirements for the project.  

The lead analyst / lead requirements engineer may also be a lead systems engineer or lead developer. This role is generally given overall responsibility for requirements development and integrity.  

Analysts and requirements engineers assist the lead analyst / lead requirements engineer and are typically tasked with following the specified procedures for managing the subset of the project’s requirements for which they have been given responsibility. 

Other project stakeholders who provide input to the requirements base are generally given responsibility for reviewing the requirements at specified milestones. 

Tools 

In this section of your plan, describe any automated tools that will be used to manage the requirements. Provide a brief overview of how those tools will be used during the requirements management process, and reference any documented procedures governing the use of the tools.  

More detailed descriptions of how the tools shall be used in the various steps of the process should be provided in the sections of the plan that describe those steps. 

Requirements gathering 

Describe the process that you will use to elicit, analyze and document the requirements. Then, describe the requirements gathering techniques you will use and with what groups you will use them. 


RELATED POST: 11 Requirements Gathering Techniques for Agile Product Teams


Categorization and assignment 

Here, you will describe your process and procedures for dealing with various types of requirements. 

Describe how requirements will be categorized within your requirements management system. Typical categories include:  

  • Functional 
  • Non-functional 
  • Internal 
  • External 
  • Regulatory 
  • Performance 
  • Quality 
  • Training 
  • Support 
  • Maintenance 

 The difference between functional and non-functional requirements—what the product must do versus any constraints on how the product must be constructed—normally impacts how the requirement will be verified. For more information on non-functional requirements and their impact on product development, click here. 

Internal requirements will generally be driven by the needs of stakeholders within your organization. External requirements will include those driven by customers, market forces, government regulations industry standards, etc. 

A requirement’s category will dictate, in part, how it is assigned for development, implementation and verification. Your plan should describe your policies and procedures for assigning requirements to subsystems or components or by work breakdown structure (WBS). 

Prioritization 

Companies will prioritize the fulfillment of some requirements over others. Reasons for high prioritization may include market demand, regulatory compliance, contractual obligation, or internal stakeholder need. 

That’s why it’s important to plan and document how you will prioritize requirements for development and release. Keep in mind that you will likely describe in detail your rules for prioritizing requirements in your Product Requirements Document. 

Traceability 

Describe your overall process for tracing requirements throughout the product lifecycle: from gathering, through decomposition, development, implementation and verification. Mention the tools to be used to accomplish the traceability process. 

Requirements and their attributes need to be tracked throughout the project lifecycle to ensure fulfillment. Attributes to be tracked may include: 

  • Name
  • Type 
  • Project unique identifier 
  • Source (stakeholder, document, parent requirement, etc.) 
  • Children (lower level requirements derived from the requirement) 
  • Assigned element of the WBS where it will be addressed 
  • Verification method (if your project requires a variety of methods) 
  • Verification reference (to the procedure that will verify the requirement) 
  • Compliance reference (applicable regulations/paragraphs) 

RELATED POST: What Is Requirements Traceability and Why Does It Matter for Product Teams


Change management 

As a project evolves, requirements will need to be added or modified. Therefore, your requirements management plan should include a section that describes your policies and procedures for change control. 

Change management (or change control) generally involves documenting each proposed requirements change in a change request. Once written, the change request is analyzed by affected stakeholders for any possible impact on project objectives or other requirements. The change request then goes before a change control board where it is either accepted (to be implemented) or rejected (and either revised or dropped). Your procedures for change control (raising, reviewing, tracking and approving change requests) should be described or referenced in this section. 

Configuration management 

Describe how you will monitor and control changes to your requirements documentation. Configuration management deals primarily with how documents will be revised and released during a project. 

For many projects, depending upon your organization, this section may be combined with the Change Management section just described. For very large projects, you may want a separate Configuration Management section. If you have a separate Configuration Management Plan you’ll probably want to reference it and keep this section brief. 

Verification 

Finally, describe the methods and metrics you will use to verify requirements. Specify how their achievement will be measured, tested, etc.  

If you use a variety of verification methods to verify different types of requirements, you will likely want to give a brief explanation of the procedures for each and how each type of verification is documented.  

Benefits of requirements management planning 

As mentioned earlier, your requirements management plan is a tool for communication. It helps your analysts, systems engineers and developers get up to speed and stay on the same page when it comes to managing your project’s requirements. Plus, it gives higher-level stakeholders a warm, fuzzy feeling that your product’s requirements will be properly managed to ensure your product’s success. 

For more in-depth information… 

Requirements management and requirements management planning can be greatly simplified through the use of a state-of-the-art requirements management tool like Jama Connect. For a deeper dive, visit our Essential Guide to Requirements Management

requirements-management-hub



Requirements and Risk Management


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.


RELATED POST: Product Development Process: How Confident Are You That You Are Not at Risk?


Beyond Commercialization

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.

 



Ease of Use and Quick Deployment


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:

    • Moving to a modern, cloud-based RM tool
    • Creating a centralized requirements repository
    • Demonstrating compliance with aviation standards

RELATED POST: Five Key Design Control Practices that Improve Compliance and Help Develop Better Products


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.


RELATED POST: Requirements Management – Living NOT Static


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.”

 


To learn more about magniX’s outcome and future with Jama Connect, read the full story here.

 


Requirements and Risk Management

In this post, we will discuss why start-up medical device companies should prioritize requirements and risk management before a quality management system.

As a medical device product development consultant, I often see start-up companies having trouble deciding what to prioritize – design controls and risk management or the quality management system (QMS).  And what they mean specifically is, which software systems should the company invest in first – the requirements and risk management solution that will aid in building a regulatory compliant design history file, or the electronic-QMS system to establish the FDA required and ISO 13485-compliant QMS?

From my experience over the past 15 years, here are the 3 reasons why I advise start-ups to prioritize requirements and risk management over an eQMS system.

1. Design controls and risk management processes start earlier

For best product, schedule, and compliance success, incorporating design controls should be done proactively instead of reactively.  Companies are typically developing their medical device from day 1.  This is compared to other QMS processes that may not be used until years later when the product is being transferred to manufacturing and being commercially distributed.  A few of these other processes include non‑conforming materials, device master record, product change control, and complaint management.

Thus, purchasing a full eQMS system earlier than necessary results in paying for functionality that may not be used for years.  That is of low value to the start-up closely watching its funds.

In contrast, as the medical device is being developed from the onset of the company, the benefits of requirements and risk management solutions can be realized very quickly and much sooner than a full eQMS system.

2. Requirements and risk management is often unwieldy

Unless your device is ‘simple,’ for example no software, no electro-mechanical parts, low-risk Class 1 devices; thoughtful consideration should be given to the processes and solutions that will manage the various requirements and risk management for your medical device development.  Organizing all the user needs, design inputs, regulatory requirements, requirements from industry standards, system requirements, sub-requirements, and risk management can quickly become unwieldy without proper management.

In my experience, even a Class II electro-mechanical device can easily approach a thousand line items to manage and connect.  Add on embedded software or a digital interface, and that number can easily jump to multiple thousands of line items or more, depending on the complexity of the medical device.  A solution like Jama Connect® has immediate value to ensure all items are linked, traced, verified, and validated for a regulatory complaint design history file and medical device file.

3. In the early years, a company can create and manage a regulatory compliant QMS without an all-electronic system

Does forgoing the eQMS mean settling with a non-compliant QMS?  No.  A company can implement a regulatory compliant QMS without an eQMS system.  SOPs can be implemented in stages, prioritized on the stage of the company.  These SOPs, along with a cloud-based document sharing repository, is often sufficient in those early product development years.  As the company approaches transfer to manufacturing and commercial distribution, then is the time to evaluate whether it’s time to transition to an eQMS system.

Summary

In summary, these are the three reasons I advise start-ups to prioritize requirements and risk management first before an eQMS system.  This path allows for the development of a successful product and complaint design history file, as well as establishing the rest of the quality management system, all in a practical manner that maximizes value and meets regulatory expectations.

 


non-functional requirements
In this post, we look at non-functional requirements are tracked by agile product teams and how they impact the product development cycle.


Imagine that you’re in the market for a new car. As you shop, you have a couple of non-negotiable features or attributes in mind, such as saving destinations within the car’s built-in GPS navigation system or that the car must be black. Although you may consider these to be “must-have” features, they would be considered non-functional requirements tied to the user experience.

What are Non-Function Requirements (NFR)?

Non-functional requirements are global constraints on a software system e.g., development costs, operational costs, performance, reliability, maintainability, portability, robustness etc.

A requirement that does not relate to functionality, but to attributes such as reliability, efficiency, usability, maintainability, and portability.

In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.

Non-functional requirements may be found in adverbs or modifying clauses, such as “The system prints invoices quickly” or “The system prints invoices *with confidentiality.”

Software has non-functional requirements that are essential to creating a positive experience for the user. And if you miss the mark on these requirements, you may have scheduling delays, budget setbacks and unsatisfied clients.

A project that lacks non-functional requirements may also lack clarity, which can result in vague project scope and a disconnect between the designer and client expectations.

Non-functional requirements bridge the gap between what developers believe customers want and what customers really want.

One study found that 60 to 80 percent of the cost of software development involves rework. And when the non-functional requirements are done well, you may eliminate 50 to 80 percent of product defects.

So, now that we’ve defined non-functional requirements, how do you integrate them effectively into your product development process?

Non-functional requirements focus on the “ilities” of the product

The “ilities” of a product include quality, reliability, manufacturability, usability, serviceability, upgradeability, etc. See SEAri MIT for more information.

Non-functional requirements focus on the user experience. A non-functional requirement is a statement defining a system quality, constraint, or external interface. For example, you might want to build a system that can manage expansion in the future. But saying so isn’t enough. You need to be specific. Instead, you might define that as “building a system that can manage at least 50,000 users over the next 24 months, so customers don’t experience the frustration of system crashes.”

Additionally, a non-functional requirement may:

  • Follow any legal or adherence rules.
  • Define quality attributes of the software.
  • Ensure performance in key areas such as reliability, availability, scalability, and more.
  • Focus on the user experience so the system is easy to operate and the risk for potential rework is minimized.

Just as with car shopping, not everyone needs the same features to make their user experience great. You might want warming seats in a new car, but somebody else might want a third row of seats. So, the non-functional requirements that you define for your project will vary based on client expectations. A list of potential categories, however, can give you a starting point to consider which non-functional requirements need to be on your list.

What are the different types of non-functional requirements?

Think about non-functional requirements as buckets that hold attributes important to the user experience. Remember, it’s not what a product will do (which are its functional requirements), but it’s what a project will be.

If you have selected the right buckets and measured the right things, then you can feel confident that you’re handing over a product that will meet customer expectations – because you’ve clearly defined these expectations up front. Everyone is on the same page, which is even further enhanced when you centralize your requirements management, which we’ll touch on shortly.

For now, let’s look at some of the potential categories for non-functional requirements:

  • Performance and scalability. What are the required response times, benchmark specifications, and other attributes related to performance? How fast does the system provide results, and how will the performance change with higher workloads?
  • Operating constraints. Operating constraints may include any required software requirements, system requirements, and run-time constraints that need to be considered in product development.
  • Platform constraints. Most projects include some sort of platform constraints. Clearly define these upfront.
  • Modifiability. How much effort is required to make changes to the software? Defining this upfront can help the customer better plan for any potential changes.
  • Portability requirements and capability. How difficult will it be to move the software to a different platform? What hardware and operating system does the software run on? Does it conflict with other processes or applications within these environments? Clearly define these elements.
  • Reliability. How often does the software fail? Outline any consequence of software failure and strategies for detecting errors, plans for error correction, and more.
  • Security. Security focuses on the requirements for protecting the system and data. How much time and effort does it take to break into the system, and how can you mitigate these exposures?
  • Usability. Usability is focused on the user experience. How difficult is it to learn and operate the system, and how can you improve any potential uses?
  • Legal. There may be legal issues around data privacy, intellectual property rights and more.

Categories vary by project, yet some common categories include availability, capacity, reliability and security. Using a few of the more common ones to start and then expanding to other areas can help you build a template for new product development projects.

Functional vs. non-functional requirements: What’s the difference?

Attributes of Functions vs Nonfunctional Requirements

Functional requirements are focused on how the software needs to perform or the desired behavior of the system. For example, if a specific condition is met, a system will send a new user a welcome email. A functional requirement is focused on what the system does when a requirement is met. Other functional requirements might involve business rules, reporting requirements, audit tracking, and more.

A non-functional requirement focuses on properties and characteristics of the product that are generally passive. Non-functional requirements are focused on attributes such as privacy, portability, reliability, stability, and more.

What is a non-functional requirements document?

Non-functional requirements are one component of the software requirements specification document (SRS document). This document focuses on what the software is expected to do and how it’s expected to perform. It also addresses what is required in terms of functionality from a user perspective.

The SRS documents include a few sections, such as:

  • Overview of the system. The overview includes high-level details about the system. Any useful terms are defined upfront in a glossary-like format.
  • General description. This section outlines any assumptions about the project and the overarching vision or theme.
  • Specific requirements. This section is where the functional and non-functional requirements are included.

If you haven’t written an SRS document before, or if you want to improve on your existing document, check out examples as a starting point. These also provide inspiration for how non-functional requirements examples flow into the entire document.

What templates exist for tracking and managing a non-functional requirement?

Software and hardware teams collaborate throughout the entire development process as they define functional and non-functional requirements. However, this collaboration becomes problematic when teams use different tools. Centralizing requirements management allows you to save time, align more effectively, and ensure the quality and compliance of product development. Using a single solution enables you to effectively:

  • Experience a single source of truth. A single source of truth offers greater visibility throughout the entire product development cycle.
  • Benefit from real-time iteration. Working within a requirements management platform that has visibility and communication across all development teams enables more informed decisions and improves collaboration abilities.
  • Enjoy stronger visualization. You can more effectively visualize how tests trackback to requirements, resulting in higher quality and compliance.
  • Reuse validation requirements. Reuse validated requirements to quickly replicate features across products.

Centralizing requirements management allows you to build stronger and more effective non-functional requirements, which improves product development. A single source of truth empowers you to connect data, conversations, and decisions – all within a single system.

The result is that you can collaborate and communicate critical pieces of information around product development, resulting in less rework, fewer missed deadlines and happier clients.

See How Jama Connect Streamlines Tracking and Tracing Requirements. 



Requirements Management
EDITOR’S NOTE: This post on requirements was originally published here, by Medium, and this article was adapted from Software Requirements, Third Edition, by Karl Wiegers and Joy Beatty. If you’re interested in software requirements management, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.

Creating a Culture that Respects Requirements

The leader of a corporate requirements organization once posed a question. “I’m experiencing issues in gaining agreement from some of our developers to participate in requirements development,” she said. “Can you please direct me to any documentation available on how developers should be engaged in the requirements process so I can help them understand the value of their participation?”

In another organization, a business analyst experienced a clash between developers seeking detailed input for an accounting system and an IT manager who simply wanted to brainstorm requirements without using any specific elicitation techniques. “Do readers of your book risk cultural conflict?” this BA asked me.

These questions exemplify the challenges that can arise when trying to engage business analysts, developers, and customers in a collaborative requirements partnership. You’d think it would be obvious to a user that providing requirements input makes it more likely that she’ll get what she needs. Developers ought to recognize that participating in the process will make their lives easier than being hit on the head by whatever requirements document flies over the proverbial wall. Obviously, not everyone is as excited about requirements as the typical business analyst is.

Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary.

Get Buy-In for a New Process

It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.

It’s possible the resisters haven’t been exposed to solid requirements practices. Or they might have suffered from poor implementation of requirements processes, perhaps working on a project that produced a large, incomplete, and ignored requirements specification. Those experiences would leave anyone feeling frustrated.

Perhaps the resisters don’t understand and appreciate the value of those practices when performed effectively. They might not realize the price they have paid for having worked in a casual and unstructured environment in the past. That price mostly shows up as unexpected rework that leads to late deliveries and poor software. Such rework is buried in the daily activities of the project participants, so they don’t recognize it as a serious inefficiency.

If you’re trying to get developers, managers, and customers on board, make sure everyone understands the past pain the organization and customers have experienced because of requirements problems. Find specific examples to demonstrate the impact in case individuals haven’t felt the pain themselves.


RELATED: Three Reasons You Need a Requirements Management Solution


Quantify the Costs of Requirement Problems

Express the cost in units that are meaningful to the organization, be it dollars, time, customer dissatisfaction, or lost business opportunities. Development managers often aren’t aware of how badly requirements shortcomings hurt their teams’ productivity. So show them how poor requirements slow down design and lead to excessive — and expensive — course corrections.

Even if you don’t have data available to quantify the costs of requirements problems, every organization has an anecdotal legacy of project failures. People remember systems that were dead on arrival, rejected by users as unacceptable. Isn’t it strange how project teams never feel they have the time to devote to getting the requirements right, and yet they always find the time, staff, and money to fix systems that were deeply flawed because of requirements errors? Use such stories from the corporate folklore to help steer the culture to recognize that, without solid requirements, failure is highly likely.

Developers are stakeholders in the project, but sometimes their input isn’t solicited and they become the “victims” of the requirements that are thrust upon them. Therefore, they benefit from providing input that will make the requirements documentation as useful and meaningful as possible. I like to have developers review requirements as they are evolving. That way they know what’s coming and can spot areas that need more clarity.


RELATED: The Business Value of Better Requirements Management


Get Input from Developers, QA, and Testers

You also need developer input when specifying internal quality attributes that aren’t visible to users. Developers can offer suggestions no one else might have thought about: easier ways to do certain things; functionality that would be very expensive to implement; unnecessary imposed design constraints; missing requirements, such as how exceptions should be handled; and creative opportunities to take advantage of technologies.

Quality assurance staff and testers are also valuable contributors to excellent requirements. Instead of waiting until later in the project, engage these sharp-eyed people in the iterative review of requirements early on. They’re likely to find many ambiguities, conflicts, and concerns with the requirements as they are developing their test cases and scenarios from the requirements. Testers can also provide input on specifying verifiable quality attribute requirements.

Management Needs to Lead the Charge

Management plays a dominant role in shaping an organization’s culture. The leadership must understand the need for the organization to have effective business analysis and requirements engineering capabilities as strategic core competencies. Yes, project-specific and localized grassroots efforts are important. But without management commitment, the improvements and benefits likely won’t be sustained after the project ends or after a reorganization. It doesn’t help if your senior people say they “support” the improvements but then revert to the same old processes the minute there is a fire.

Behaviors — not pronouncements —are evidence of a commitment to quality. Figure 1 lists ten signs that your organization’s management is truly committed to excellent requirements processes.

Requirements Management

Figure 1. Some behaviors that indicate management’s commitment to excellent requirements processes.

Resistance to process or culture change can indicate fear, uncertainty, or lack of knowledge. If you can discern the source of the resistance, you can confront it with facts, reassurance, clarification, and education. Show people how their constructive participation in the requirements process not only is in their personal best interest but also will lead to collectively better results. Everyone wins when they work together toward a common objective.


To learn more on the topic of requirements management, we’ve curated some of our best resources for you here.

SEE MORE RESOURCES

How to Choose the Right Tool for ASIL D Requirement Management ISO 26262 / IEC 61508

Editor’s Note: This posts on tool selection around ASIL D requirement management for ISO 26262 / IEC 61508 was originally published here by LHP Engineering Solutions and written by Steve Neemeh. When the options for choosing a requirements management tool are endless, what factors should you be looking at to help make your decision? This article provides some concrete considerations you may use to guide your selection.

requirement management

 


Which tools should I use for ASIL D requirement management ISO 26262 / IEC 61508?

There are a multitude of requirements management tools in the marketplace (e.g., IBM DNG, Siemens Polarion, Jama Software, Helix). How does an organization make the important decision of which is best for its needs when the options are endless or when using Microsoft Word/Excel or Google Docs for requirements management can be considered? Is there even one tool that can meet all of the organization’s needs? This blog will describe why selecting a tool based on one specific departmental need, such as requirements management, might be impractical.

To begin the search, here are five items that might be considered:

1. Cost of Tools
  • The range of costs can vary significantly. For a small organization, some of the larger toolchains may not be affordable. On the other hand, some of the smaller tools may not address parts of requirements management that are critical for ASIL D development.
2. Size and Distribution of the Organization
  • How many engineers need the tools and in how many locations? Some license agreements are floating so utilization could be optimized if the tools are used across multiple time zones (e.g. India and USA).
3. Number of Requirements and Requirements Hierarchy
  • Are there 100 safety-critical requirements or 5,000? Out of these requirements, how many of them are related to software, hardware, or test cases? How large is the HARA and how many safety goals are there? This will define the size of the requirements hierarchy.
4. Existing tools
  • The selection and integration of a new tool will inevitably impact the use of the exiting toolchains.
5. Full ISO 26262 workflow
  • Refer to V diagram.
requirements management ISO 26262 / IEC 61508

LHP’s requirements management V diagram for the Application Lifecycle Management toolchain

 

When researching tools for an organization, it is a common discovery that there is not one tool that meets all of the needs. The tools industry has not caught up with the complexity of the safety lifecycle. What is found in the marketplace are versions of Application Lifecycle Management (ALM) tools, but what is really needed is an LHP ecosystem-based Safety Lifecycle Management (SLM) toolchain. This SLM is based on guidelines for safety-critical development as defined in the 700+ pages of requirements, work products, and methods in standards such as ISO 26262 or the Safety of The Intended Functionality (SOTIF).

What is the Workflow for Functional Safety, ASPICE, and Other Safety-Critical Applications?

The V diagram covers the foundational items that need to be considered in addressing a standard like ISO 26262: project management, task management, and change management. In this particular case, four tools have been considered: ANSYS Medini, Jama Software, Atlassian JIRA, and National Instruments. All four tools provide partial solutions to meeting the needs of functional safety.

  • ANSYS Medini: HARA and systems-level modeling, as well as hardware metrics calculations (Parts 3 & 5 of ISO 26262)
  • Jama Software: Requirements management (required by ISO 26262, emphasized in Part 8)
  • Atlassian JIRA: Project management and change management
  • National Instruments Tools: Automated test and test scripting

By combining the engineering best practices with the tools’ strengths and considering an organization’s main drivers, a workflow can be defined; one that optimizes tool usage and reduces the load on engineers. Ultimately, to be successful within safety-critical development, an organization needs to develop against a standard while also reducing the labor associated with engineering and testing.

Without the latter, the cost and time for development escalate exponentially. Are engineers going to copy and paste data across tools? Are they going to have multiple versions of the same information across different toolchains? As the complexity of systems increases, a non-optimized toolchain can paralyze an organization and its development process.

In the absence of a commercial off-the-shelf fully-compliant SLM tool, the solution of integration tools can provide the same functionality. For this purpose, the tools provide methods of connectivity with REST (Representational State Transfer) API. An example of a REST API between Jama Software and JIRA is shown in the appendix.

Conclusion

When selecting a requirements management tool, it is crucial to consider the needs of the organization as a whole, the safety workflow, and the customization and connectivity for optimization of the tools. In a typical implementation of a safety-critical system, most organizations just consider one, or parts of one, of these critical items, causing large rework and tool spend that can otherwise be avoided.

Take-a-Ways
  • There is no one tool that meets the needs of requirements management in compliance with functional safety.
  • The tool capability varies greatly based on cost, and there is feature overlap between tools.
  • The holistic organization, not just a single department, needs to be involved in making the tool selection. The needs of each department: management, engineering, IT, manufacturing, regulators, and even certification agencies all must be considered.
  • The tool must be appropriate for the size and scale of the organization.
  • There are methods of automating data transfer that significantly reduce labor and cost on development programs (as shown in the appendix).
  • Successful organizations are going to get ahead by creating efficient workflows that allow them to release products faster and more economically in the new electric vehicle/autonomous vehicle (EV/AV) world of transportation.

Appendix: More Details About REST API

Both Jama Software and JIRA provide access to their cloud resources via Representational State Transfer (REST API). REST is a web-based application programming interface that exposes a set of Uniform Resource Locators (URLs) with which to carry out Create, Read, Update, Delete (CRUD) operations in the tool. LHP Engineering Solutions has implemented a Domain Object Model (DOM) connection for both Jama Software and JIRA with a third integration piece to connect the two. The integration piece is a configurable application that implements the customer use cases.

REST API integration

Benefits of Using REST API
  • Ease of implementation
    • REST is a standard specification of how to access web resources
    • All web and cloud-based tools expose REST APIs
    • Returns data, as well as metadata, which allows for conditional and iterative processing
    • Implemented in a JAVA wrapper making it configurable and portable to any system
  • Customizable authentication feature
    • Simple user and password authentication if desired
    • Simple user and access token authentication if more security is desired
    • OAuth authentication is also available but not required
  • Portability of output to Web and other tool frameworks
    • XML/JSON that any tool can consume
    • XML/JSON are standard serialized data formats for web resources
    • Web applications typically take XML/JSON as input files for data exchange, data migration, report building, etc.
REST API Complexities
  • Requires a non-standard mapping of attributes from Jama Software to JIRA and vice-versa. Each customer mapping will need to be customized.
    • The REST specification defines what the API should do but not how it should do it. No standardization of data schema. Therefore, tools will have disparate data models.
    • Attribute A in Tool A must be mapped via a mapping file to Attribute B in Tool B etc. This goes for attributes, links, attachments, and all data elements in each data model.
    • A UI will have to be developed to allow for the mapping creation and management.
Standard Feature Set of REST API
  • Mapping and transfer of attributes and attachments from one tool to the other
    • Data models are mapped as closely to 1:1 as possible
    • UI to build and manage mappings
  • Scheduled and on-demand synchronization
    • Synchronization data between toolsets via UI
    • Synchronize data between toolsets by scheduling a task
  • Intermediate transformations (e.g., risk calculations)
    • Calculating or transforming the data from the source tool before reaching the target tool
  • Linking from one tool to the other via hypertext links
    • URLs from source resources to target resources and vice versa for traceability
  • Reports
    • Since the REST APIs produce a consumable output, any reporting tool that can consume XML/JSON can be used to produce reports.
      • Jama Software reports
      • JIRA reports
      • Requirements gap analysis
      • Test coverage gap analysis
      • Requirements Traceability Matrix
      • Bug reports
      • Customized reports

We’ve compiled a list of helpful resources for requirements management in automotive development, click the button to learn more!
SEE MORE RESOURCES

 

Defining Project Scope

Every product development team talks about project scope and team members often complain about unending scope creep. The vision and scope document (often including a use case diagram and a context diagram), otherwise known as the MRD (marketing requirements document) or business case, is a key deliverable in defending against scope creep. You don’t necessarily need a standalone vision and scope document for a small project. Any project of any size, though, will benefit from such strategic guidance, even if it’s just a paragraph or two at the beginning of the requirements specification. 

Vision and Project Scope

defining project and use case diagrams-1

Both the vision and the scope are components of the project’s business requirements. I think in terms of the product vision and the project scope. I define the product vision as: “A long-term strategic concept of the ultimate purpose and form of a new system.” The product vision could also describe the product’s positioning among its competition and in its market or operating environment. 

A well-defined scope sets expectations among the project stakeholders. It identifies the external interfaces between the system and the rest of the world. The scope definition helps the project manager assess the resources needed to implement the project and make realistic commitments. The scope statement defines the boundary of the project manager’s responsibilities. 

Your scope definition also should include a list of specific limitations or exclusions—what’s out. Obviously, you can’t list everything that’s out of scope because that would include every detail in the universe except for the tiny sliver that is in scope for your project. Instead, the limitations should identify capabilities that a reader might expect to be included in the project, but which are not included. I know of a project to build a Web site for a national sports team that included the following exclusions for the initial release: 

  • There will be no virtual or fantasy games via the Web. 
  • There will be no ticketing facilities on the site. 
  • There will be no betting facilities available. 
  • The demographic details for newsletters will not be collected. 
  • Message boards are out of scope for phase 1. 

Some stakeholders involved with this project might have expected these capabilities to be included. Itemizing them as exclusions makes it clear that they won’t be. This is a form of expectation management, an important contributor to project success. 


Related: Project Management Best Practices  

Context Diagram

The venerable context diagram dates from the structured analysis revolution of the 1970s. Despite its antiquity, the context diagram remains a useful way to depict the environment in which a software system exists. Figure 1 illustrates a partial context diagram for a hypothetical corporate cafeteria ordering system. The context diagram shows the name of the system or product of interest in a circle. The circumference of the circle represents the system boundary. Rectangles outside the circle represent external entities, also called terminators. External entities could be user classes, actors, organizations, other software systems to which this one connects, or hardware devices that interface to the system. 

The interfaces between the system and these external entities are shown with labeled arrows, called flows. If the “system” is strictly an electronic system involving software and perhaps hardware components, flows will represent data or control signals. However, if the “system” includes both a software application and manual operations, flows could also represent the movement of physical objects. Two-headed flows indicate update operations involving the data object on the flow. 

defining project and use case diagrams-2

The context diagram depicts the project scope at a high level of abstraction. This diagram deliberately reveals nothing about the system internals: no information about functionality, architecture, or look-and-feel. Nor does it explicitly identify which features or functionality are in scope and which are not. The functional behavior of the system is merely implied by the labeled flows that connect the system to the external entities. Even the flows are labeled at a high level of abstraction, just to keep the diagram’s complexity manageable. 

Despite the limited view that the high level of abstraction imposes, the context diagram is a helpful representation of scope. It serves as a tool to help the project stakeholders communicate about what lies outside the system boundary. 


RELATED: High Cost of Poor Requirements Management

Use Case Diagram

Use cases are a powerful technique for exploring user requirements. The Unified Modeling Language (UML) includes a use case diagram notation. Figure 2 shows a partial use case diagram for our cafeteria ordering system. The rectangular box represents the system boundary, analogous to the circle in a context diagram. The stick figures outside the box represent actors, entities that reside outside the system’s context but interact with the system in some way. The actors correspond approximately (exactly, in this example) to the external entities shown in rectangles on the context diagram. 

defining project and use case diagrams-3

Unlike the context diagram, the use case diagram does provide some visibility into the system. Each oval inside the system boundary box represents a use case. The use case diagram shows the interactions of the system with its users and some connections between internal system operations, albeit at a high level of abstraction. 

The arrows on the use case diagram indicate which actors participate in each use case. In Figure 2, the arrow from the Patron to the oval labeled “Submit Feedback” means that the patron actor can initiate the Submit Feedback use case. The arrow from Submit Feedback to the Menu Manager actor indicates that the Menu Manager participates somehow in the execution of Submit Feedback. Arrows on the use case diagram do not indicate data flows as they do on the context diagram. In addition to showing these connections to external actors, a use case diagram could depict logical relationships and dependencies between use cases. 


RELATED: Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)

The use case diagram provides a richer scope representation than the context diagram because it provides a high-level look at the system’s capabilities, not just at its external interfaces. There is a practical limitation, though. Any sizable software system will have dozens of use cases, with many connections among them and between use cases and actors. Attempting to show all those objects inside a single system boundary box quickly becomes unwieldy. Therefore, the analyst needs to model groups of related use cases as packages or to create multiple use case diagrams. 

Many analysts have found the context diagram and use case diagram to be helpful ways to represent and communicate a shared understanding of a project’s scope. In Part 2 of this series, I’ll describe two other techniques for defining scope, feature levels and system events. 

Check out Part 2, Defining Project Scope: Feature Levels and System Events 

Check out Part 3, Defining Project Scope: Managing Scope Creep 


Download our eBook, Best Practices Guide for Requirements and Requirements Management, to learn the fundamentals of requirements and how effective requirements management can keep your projects on time and on budget.

READ THE EBOOK


This is an updated version of a 2014 article by Karl Wiegers. You can read the archived original here https://www.jamasoftware.com/blog/context-and-usecase-diagrams-defining-scope/.


Recently, we explored the results of a Forrester Research report that concluded that highly regulated industries can benefit from an Agile approach to requirements management. In today’s post, we’ll dig deeper into how customers in all industries can benefit from a collaborative platform that helps them manage requirements throughout complex development cycles.

According to a recent report from Engineering.com, in spite of growing product complexity and intense regulations, the majority of design teams don’t have a dedicated requirements management (RM) solution in place. About half use a tool that’s not purpose-built for requirements management, while almost a third have no system in place at all, relying instead on email and shared documents.

Only 15% of teams surveyed by Engineering.com had invested in a dedicated RM solution — but that number should be (and will be) much higher, as more organizations come to understand the long-term value of successful requirements management.

Here are three reasons why your organization needs a RM solution.

Poor requirements management leads to product failures.

Engineering.com reports that more than four out of five design teams have experienced product failure due to substandard requirements management. Failures included exceeding cost requirements and losing time to market, but most teams experienced more than one failed outcome, like a product that was late to market and cost more than expected to build.

The report also showed that organizations using dedicated requirements management platforms in regulated industries not only received fewer instances of warnings, recalls, fines and production stoppages than those that didn’t, but nearly half reported experiencing none of those problems at all.

Teams without the right requirements management tool will ship products that haven’t met requirements.

As product complexity increases, teams without comprehensive RM solutions report shipping products that don’t meet all requirements. There are several reasons why teams report that their products were shipped with missing requirements, many of which can be linked to increased product complexity, including more frequent use of microprocessors, the need to adopt different materials, and demand for embedded software.

Shipping a product that doesn’t meet requirements can lead to reprimands from regulatory agencies or even product recalls, which can permanently damage your brand reputation and position in the market.

Products and systems are only getting more complex, driving the need for the right requirements solution.

More complexity means more time spent tracking requirements. To quote from the Engineering.com report, “Many of the respondents who increased the complexity of their products acknowledged spending excessive time tracking requirements due to poor requirements management. Those needing to connect products (IoT) and add more microprocessors suffered the most, quickly followed by those needing to embed software and reduce product size.”

Image courtesy of Engineering.com

Products are getting smarter, and development teams need intuitive, powerful RM solutions to manage that rising complexity. As the Engineering.com report concludes: “It is clear from the data that the products most design teams are creating are becoming more complex. Yet, they have not thought of investing in the tools available that would help them manage the requirements this complexity demands.”

To dive deeper into the relationship between rising product complexity and effective requirements management, download the full report: Design Teams: Requirements Management & Product Complexity.”