requirements management Archives

Tag Archive for: requirements management

Product development and delivery is more complex today than ever before. Modern products are multifaceted and multidisciplinary, with hardware, software, and various engineering approaches coming together in the name of superior customer experience. Many industries — medical device, automotive, and aerospace and defense, for instance — also require that complex product developers adhere to rigorous safety standards and regulations. Companies have to work effectively and efficiently if they’re going to keep their competitive advantage.

Despite this, many teams are still using Word and Excel to manage requirements for these very complex products. This means they’re missing real-time collaboration and insights, end-to-end traceability, and integration with product testing, to say the least.

Learn why designing a reliable test strategy requires broad, strategic thinking by downloading our paper, “Verify, Validate, Trace & Test”

A recent report from Engineering.com found that while 90% of design and engineering teams agreed that products had become more complex in the last five years, a mere 15% relied on a dedicated requirements management solution. The rest still rely on a purely documents-based approach, even though using these tools to exclusively design, manage, and execute requirements presents an array of problems, including version-control issues, poor communication, inefficient collaboration, and lack of coordination.

The study found that the implications of poor requirements management were not to be taken lightly. Without a dedicated solution, teams were stuck with ineffective requirements management and were more likely to face product outcome failures (83% of respondents) and reprimands by regulatory agencies (62% of respondents).

On the other hand, the report found that not only did organizations using a dedicated requirements management platform in regulated industries receive fewer warnings, recalls, fines, or reprimands than those that didn’t, nearly half reported experiencing none of these issues at all.

Download our whitepaper to learn about the five biggest challenges of requirements management and how to conquer them.

Word documents that are hundreds of pages long, Excel spreadsheets packed with thousands of lines — sharing these ever-evolving files among multiple stakeholders and disparate teams throughout the development and testing process is cumbersome, frustrating, and time-consuming — not to mention risky. And with the market demanding flawless products delivered at record speeds, innovators can no longer afford that kind of inefficiency.

Using a dedicated requirements management solution, however, allows teams to stop wasting time and start innovating. For example, our customer, MediSync, reports that investing in Jama Connect has saved 80% of the time that would have otherwise been spent on meetings, sorting through versioned Word documents and emails, and consolidating feedback in review cycles.

To learn more about the growing number of organizations adopting product development solutions to manage the complexity of connect systems, download our eBook, Your Guide to Selecting the Right Product Development Platform.

Word and Excel undoubtedly serve a purpose. For early-phase documentation and for coordinating small, simple projects, they remain effective tools. But as product development grows more complex, teams need solutions that provide purposeful collaboration; connect globally-distributed team members; and accurately capture and facilitate feedback, decision making, and context for requirements under review.

To learn more about the limitations of a document-based approach and how to get the most out of your requirements management tool, download our eBook.

To learn more about requirements management, we’ve compiled a handy list of additional resources for you!

SEE MORE RESOURCES

The Jama Support Community is a forum for Jama Software users to interact and collaborate with other users and with Jama support engineers. It’s full of resources for everyone from novices to masters, including tutorials and webinars, help guides and FAQs, feature requests and announcements and a robust knowledge base. For today’s post, we spoke with one of our Jama Support Community power users — frequent contributors with great questions and powerful insights into using Jama — about how their organization uses Jama and the value they’ve seen from the Support Community.

Srilatha Kolla works on the DevOps team at at Hill-Rom Cary in the Raleigh, North Carolina area. Hill-Rom’s Clinical Workflow Solutions team develops medical devices that protect patients by anticipating the care they will need and communicating that information to their healthcare providers.

The process of developing these Class II and Class III medical devices is heavily regulated by the FDA, and Kolla’s team needed to achieve full traceability in order to satisfy these requirements. Hill-Rom was using IBM Rational DOORS for their requirements and test case management prior to 2012, but it didn’t meet their traceability needs, among other shortcomings.

Kolla, who started her career as a developer at IBM, was on the Quality Engineering team at Hill-Rom when they began looking for a superior solution. Her QE team evaluated several options before choosing Jama Connect™ in 2012.

Since then, Kolla has moved to the DevOps team, where she’s responsible for deploying and managing processes to help development, requirements and quality engineering teams build, test and release products that are safer and more reliable. Her team is closely involved from the requirements stage to coding, testing and verification of the product, and she’s responsible for managing the solutions, including Jama Connect, that her team depends on.

Kolla’s DevOps team serves as the Jama administrator at Hill-Rom, but the development, requirements and quality engineering teams, she says, also “live in Jama Connect day in and day out.” Among the organization-specific best practices her team has developed is a multi-project structure, which works better for them than a single, more complex project structure.

As an FDA-regulated company, Kolla says, Hill-Rom values Jama Connect for its traceable requirements and test case management: “That’s what we depend on highly.” She’s also a fan of the Review Center in Jama Connect. The Review Center enables teams to collaborate without hunkering down in the same room or emailing a Word document back and forth. Stakeholders can also review and sign off on requirements within the Review Center, which comes in handy when you need to reach consensus between team members quickly.

Kolla began using the Jama Support Community to get her questions answered. She wanted to see how other people were using Jama to address the same product development challenges her team was facing. As Kolla says, “We’re definitely not the only ones using this platform.”

Like many Jama customers, Kolla’s team uses Jama Connect in conjunction with Jira, so she turns to the Support Community to ask relevant questions about Jama’s functionality and interconnectivity with Jira, Microsoft Office and other tool suites. Given her team’s focus on traceability, Kolla has often sought Jama-related input from other users on things like item management, defects, Test Center, Trace View, Coverage Explorer, Reuse and Filters.

Stay tuned for more posts on how Jama users are leveraging the Jama Support Community to get the most out of the platform. In the meantime, connect with Sri and other fellow Jama users on the Jama Support Community.

As 2019 gets further underway (it’s February already?), we’re thinking about the changes we can expect from the requirements management space this year. Last week, we wrote about the Engineering.com report we sponsored, which found that while more than 90% of design and engineering teams agreed that their products had become more complex over the last five years, only 15% relied on a dedicated requirements management solution.

That got us wondering how teams will change their approach to requirements management over the next five years.

To get a feel for requirements management trends in 2019 and beyond, we spoke with three experts at Jama Software:

Michael Jastram, Solutions Architect in Customer Success, based in our Amsterdam office
Robin Calhoun, Senior Product Manager, based in our Portland, Oregon headquarters
Steve Gotsch, Director of Product Management, also based in Portland

Here are their predictions for the requirements management trends to watch this year.

Requirements management will grow more complicated – and more essential.

Requirements management continues to be a priority for product development teams and will only become more complicated as a result of increasingly complex product designs and more hardware/software integrations. The growing complexity of requirements will drive the need for dedicated tools that save time, reduce errors and streamline collaboration and review cycles.

In the requirements management space, says Jastram, “things are changing faster and faster. Transformation is taking place on many levels, and they all affect requirements: at the organizational level, at the regulatory level and obviously on the product level. This trend is driven primarily by complexity, and Jama is addressing that complexity through its platform.”

Requirements management is growing into requirements modeling.

Jastram thinks requirements modeling is becoming “a huge trend,” though he doesn’t see it becoming mainstream in more heavily regulated industries for several years.

Requirements modeling is already a familiar concept in software, where it’s leveraged to test the system or application under development to establish a clear relationship between tests and requirements. Jastram notes that companies like Boeing and Airbus are already building “all-encompassing system models of their products,” but that “these are exceptions and not the rule.”

Systems modeling helps teams focus on the system’s external behavior, apart from its internal design; describe stakeholder needs with more precision; reduce gaps and inconsistencies in requirements; and cut down on the work associated with requirements change.

When it comes to managing requirements, Jastram suggests that modeling can help teams deal with the huge complexity of today’s – and tomorrow’s – products: “This will be a really big thing for the first company that does it right,” he says.

More organizations will invest in requirements management solutions.

As the Engineering.com study revealed, not everyone is using a dedicated requirements management tool, but companies are increasingly aware of the importance of managing risk and improving their development process.

According to Calhoun, “Managing risk is becoming more common with more companies focusing on medical devices and the continued confluence of hardware and software.”

This increase in complexity and in the amount of data that must be incorporated throughout the development process drives the need for companies to find a stronger way to manage requirements. Our product team thinks of requirements as the “steel thread” that ties together all the data throughout the product or application lifecycle.

As the Engineering.com report also noted, heavily regulated industries like medical devices, automotive, and aerospace and defense are more likely to depend on dedicated requirements tools. For less heavily regulated industries, Jastram notes, investing in requirements management may seem prohibitive, especially if teams don’t understand the value they can realize by transitioning away from a document-based approach.

Instead of emailing versioned documents back and forth, less regulated industries can derive huge value from using a requirements management platform to support their product development processes. These tools enable more efficient communication between users and stakeholders, streamline the review process, speed time-to-market and establish traceability to ensure you’re building the product you set out to build.

Requirements management practices globally are aligning, as US companies look to EU markets as examples.

Gotsch notes that there’s “an effort to better align practices globally using risk and FMEA and the Germany auto industry as an example.” Jastram agrees, adding that requirements management in the German automotive and aerospace industries is “considered fairly mature,” while Gotsch and Calhoun acknowledge that US companies have sometimes been notorious for doing product development on the fly. However, Calhoun says, this fly-by-the-seat-of-your-pants approach isn’t how the most valuable and successful companies work.

“US companies are maturing in their approach to requirements in the software and hardware space as complexity and interactivity grows,” Calhoun says. “The lessons from EU markets are becoming more the norm: more standards, more tools, more regulations and more predictability.”

Requirements management tools will change to meet the expectations of younger teams.

Calhoun and Gotsch predict that requirements management tools will become more intuitive and efficient, in part to meet the expectations of a younger workforce. “The younger generation of the workforce is (still) coming up in experience and influence,” Calhoun says. “There’s an increasing need for enterprise tools to begin catering to their expectations — which are efficient, modern and fast — to attract and keep talent. Companies no longer have the aging workforce’s willingness to work around inefficiencies.”

The best tools and platforms will be value-driven, not feature-driven.

Jastram, who worked in software development and requirements management before earning a PhD with an emphasis in requirements modeling, says the most successful requirements solutions of the future will be value-driven.

Rather than incorporating feature after feature, the best platforms will add value across the product development lifecycle by understanding and supporting business practices. Jastram cites Risk Management Center for Jama Connect™ as a value-based feature that supports and accelerates the work teams are already doing, rather than rolling out feature after feature that, in Jastram’s words, “look good on paper, but don’t really help your practice.”

To learn more about the changing landscape of product development and requirements management, check out the report we sponsored: Design Teams: Requirements Management & Product Complexity.

Many questions need to be answered throughout the development process, and quickly. But teams often don’t have the right approach to data collection, storage or analysis to enable fast, data-driven decisions.

One tactic is to dump a bunch of data from disparate tools into a spreadsheet in an attempt to glean insights. Not only is this a heavy, manual process, but the resulting data is not always complete, consistent or up to date. And it also doesn’t capture the full context of what’s happening behind the numbers.

All the while, timelines are slipping, release dates are approaching and costs are rising.

In a recent webinar, we explored how proper data collection and analysis can make your development process more predictable. We also discussed the current state of product development (based on data from McKinsey), and the underlying causes of costly overruns and how to avoid them.

In addition to underestimating complexity, which you can read about in “How to Decrease Overruns in Complex Product Development,” a lack of consistent data is another significant cause of overruns.

Why a Lack of Data Causes Overruns

When teams lack consistent data, things like benchmarking and consistency across projects and products is either lacking or altogether absent. This also makes it much more difficult to make informed decisions.

Yet, data-driven decisions are exactly what’s needed to ensure you’re building the right thing, the right way and that it will get to market on time.

Without reliable data, team leaders often put their faith in historical information that may be from less complex or completely different projects, or worse, simply go with their gut feelings.

This can bring about severe development issues in even the most successful companies, and cause even veteran project managers to make costly mistakes.

So, what can you do to achieve consistent and reliable data to make your development process more predictable?

Get Answers to Essential Questions

To enable predictability and accurate data analysis, you need a purpose-built Predictive Product Development solution, like the Jama Product Development Platform.

By importing data from Jama Connect™ and Jira Software, for example, Jama Analyze™ allows you to get data-driven answers to the onslaught of questions that arise during complex product development.

Here are just a few questions you can answer with Jama Analyze:

Does this product satisfy customer and stakeholder requirements and marketing goals?
Can we prove we’ve met these requirements?
Are we going to deliver on time? How confident are we?
Are changes being made to any of our items throughout the process?
How good is our team at finding defects before they hit the public?
How long do things stay in each status?

Having these key performance indicators (KPIs) at your fingertips empowers you to set the right expectations and have necessary conversations if those expectations don’t align with the data you’re seeing.

Ultimately, measuring and tracking these metrics will help you make better, more profitable products.

Increasing product complexity and greater speed-to-market pressures are impacting the way products are built. From the adoption of Agile methodologies to new solutions, companies are transforming their process to keep pace.

Since requirements management is so integral to the creation of quality products, it makes sense to wonder how it might change, say, 10 years from now.

In a recent webinar, we asked three leading requirements experts — with fingers firmly on the pulse of product development — for their predictions on the future of requirements.

There Will Be Fewer Requirements

Colin Hood, principal at Colin Hood Systems Engineering, envisions a future with fewer requirements and faster time to development.

He believes the companies that will survive in the future will spend less time writing the perfect requirement specification. Instead, he believes they will move into prototyping more quickly in order to get fast feedback and show stakeholders what they understood from the requirements.

Additionally, Hood thinks there is nothing wrong with the requirements process itself, only in people’s interpretation of the process.

Full traceability is mandatory, but he says, “That doesn’t mean we have to trace every little atom of the requirement specification. We can have meaningful blocks [of requirements] and trace to these.”

Taking this approach in the future, he believes, will make the process far more pragmatic and assist with quicker development.

Requirements and Models Will Coexist

Christer Fröling, Scandinavian Marketing Lead at the Reuse Company, has a slightly different take.

In Fröling’s future, there aren’t necessarily fewer requirements, but there is a greater focus on the right requirements.

He also challenges the widely-held notion that teams either use requirements or models, as he believes tomorrow’s successful developers will use both in combination.

He hopes to see more from industry tools to aid this advanced process, namely knowledge management, voice recognition and artificial intelligence.

Fröling believes these technologies can help speed the writing requirements phase, enable enhanced communication about requirements and help interpret them in an effective way.

Modeling Will Enhance and Speed Development

Michael Jastram, Sr. Solutions Architect at Jama Software, agrees with Fröling that we won’t need to decide between requirements or models. He also sees a more pragmatic future like Hood’s, and believes model-based systems engineering is the means to this collective future.

Jastram explains that modeling includes entity relationship modeling, which is compatible with the traditional requirements approach. Furthermore, models make it much easier for machines to understand requirements and provide support during product development. In combination, this can help achieve the future Fröling envisions, in which requirements and modeling coexist to improve the overall development process.

And while models don’t require fewer requirements, they can decouple features making them self-standing. “That will make it much easier to create modular elements that can be reused and are robust enough to help us accelerate development,” Jastram says. The result resembles the more pragmatic “blocks” of requirements Hood predicts.

There’s no question that technological disruption is changing the development process. Hear more from these requirements experts on what that means for us now and going forward, including how to know when a requirement is obsolete, by watching our webinar, Disrupting Requirements: Finding a Better Way.

Improving your requirements management process can have major impacts on your development process. Some of the benefits include improving your efficiency, speeding time to market, and saving valuable budget and resources.

Requirements are the information that best communicates to an engineer what to build, and to a quality-assurance manager what to test.

A requirement has three functions:

* Defines what you are planning to create

* Identifies what a product needs to do and what it should look like

* Describes the product’s functionality and value

Requirements vary in complexity. A requirements management plan could be rough ideas sketched on a whiteboard or structured “shall” statements. It can be text, detailed mockups or models, and can be part of a hierarchy with high-level requirements broken down into sub-requirements. It may also be detailed specifications that include a set of functional requirements describing the behavior or components of a product.

High-level requirements are sometimes referred to simply as “needs” or “goals.” Software development practices might refer to requirements as “use cases,” “features” or “functional requirements.” Agile development methodologies often capture requirements as “epics” and “stories.” Regardless of the terminology, requirements are essential to the development of all products. Without clearly defining requirements, companies risk creating incomplete or defective products.

Throughout the process, there can be many people involved in defining requirements. A stakeholder might request a feature that describes how the product will provide value in solving a problem. A designer might define a requirement based on how the final product should look or perform from a usability or user interface standpoint. A business analyst might create a system requirement that adheres to specific technical or organizational constraints. Regardless of your unique goals, however, it is imperative that you implement proven requirements management best practices.

Four Requirements Management Best Practices

Today’s sophisticated products and software applications often take hundreds or thousands of requirements to sufficiently define the scope of a project or a release. Teams must be able to access, collaborate, update and test each requirement through to completion because requirements naturally change and evolve over time during the development process. They must also understand the four fundamentals of a requirements management workflow:

1. Good Requirements

A good requirement should be valuable and actionable. It should provide a pathway to a solution, and everyone on the team should understand what it means. Good requirements need to be concise and specific, and should answer the question, “What do we need?” rather than, “How do we fulfill a need?” With accurate requirements, stakeholders can understand their part of the plan. If they lack this knowledge, and if requirements are unclear or vague, the final product could be defective or fail.

Learn more about writing high-quality requirements by grabbing our white paper.

2. Collaboration and Buy-In

It’s difficult to get a company to agree on requirements, particularly for large projects with many stakeholders. In practice, it’s not necessary to achieve consensus through compromise. It’s more important to have team buy-in (before or after management approves the project) so the development process can move forward. With buy-in, the team backs the best solution, makes a smart decision and does what is necessary to move forward with the requirements management process.

Team collaboration is key to establishing good requirements. Collaborative teams work hard to make sure everyone has a stake in the project and provides feedback. When there is a commitment and understanding of project goals, team members tend to support other’s decisions. It’s when developers, testers or other stakeholders feel “out of the loop” that communication issues arise, people get frustrated and projects get delayed.

Connecting teams, such as engineering and business, can lead to better products. Let us show you how.

3. Traceability and Change Management

Requirements traceability is a way to keep everyone in the loop. It organizes, documents and keeps track of all requirements, from initial idea to testing. A simple metaphor for traceability is connecting the dots to identify the relationships between items within a project. The following figure shows an example of a common downstream flow.

Companies should be able to trace each requirement back to its original business objective throughout the development process, not merely after it’s complete. By tracing requirements, companies can identify the ripple effect changes have, see if they have completed a requirement and if they tested it properly. With traceability, and by managing changes effectively, managers gain the visibility to anticipate issues and ensure continuous quality.

Traceability also makes sure the product meets all the vital requirements that come from different stakeholders. By tracing requirements, all team members stay connected to each other and to all interdependencies. And by managing changes well, a company can avoid scope creep — unplanned changes that occur when requirements are not clearly captured, understood and communicated. The benefit of good requirements is a clear understanding of the product and the scope involved. This leads to a better development schedule and budget, which prevents delays and cost overruns.

Improve the quality of your products with our five tips for traceability.

4. Quality Assurance

Getting requirements right the first time means better quality, faster development cycles and higher customer satisfaction with the product. Concise, specific requirements can help companies detect and solve problems earlier rather than later, when they are much more expensive to fix.

Research has shown that project teams can eliminate 50 percent to 80 percent of project defects by effectively managing requirements. In addition, according to Borland Software (now Micro Focus), it can cost up to 100 times more to correct a defect later in the development process, after it’s been coded, than when it’s still in written form.

By integrating requirements management best practices into their quality assurance process, companies can help teams increase efficiency and eliminate rework. According to the Carnegie Mellon Software Engineering Institute, 60 to 80 percent of the cost of software development is in rework. In other words, development teams are wasting the majority of their budgets on efforts they didn’t perform correctly the first time.

Discover how improving your requirements adds to your bottomline with our white paper.

Requirements management best practices can appear to be a complex topic, but at its core, it’s a simple concept. It helps teams answer the question: Does everyone — from business leaders to product managers and project leaders to developers, QA managers and testers — understand what is being built and why?

When everyone is collaborating and has full context and visibility into the discussions, decisions and changes involved in product development, they maintain high quality and almost always ensure success.

Go deeper into improving your products through better requirements with our webinar, “Best Practices for Writing Requirements.”

To learn more about requirements management, we’ve compiled a handy list of other valuable resources for you!

SEE MORE RESOURCES

As Karl Wiegers accurately states in his paper on writing better requirements, “quality is in the eye of the reader … No matter how fine the author thinks the requirements are, the ultimate arbiters are those who must base their own work on those requirements.”

Avoiding ambiguity when writing requirements is essential to building the product you want built. In our recent post, “Five Ways Ambiguous Language Will Ruin Your Requirements,” we shared examples of ambiguity in requirements writing and gave expert tips to help clarify.

Here are four more sources of ambiguity, plus additional best practices to save your requirements — and your product.

Negative Requirements

Negative or inverse requirements create a lot of unnecessary ambiguity. Positive requirements in active voice are much easier to understand. Here are some before and after examples of increased clarity when moving from negative to positive.

Abbreviations i.e. and e.g.

Some readers might misconstrue the use of i.e. and e.g. The abbreviation i.e. stands for the Latin phrase id est, which means “that is.” The abbreviation e.g. stands for the Latin phrase exempli gratia, which means “for example.”

These two abbreviations are so commonly confused — either on the part of the writer or the reader — that they are best avoided altogether in favor of explicitly saying what you mean.

A/B Construct

Some requirements writers use the A/B construct, as in, “data should be recorded in an audit/history table.” This construct is rarely used in formal writing because it is so vague it could be interpreted in a variety of ways. Some examples include:

A is the same as B. In this case, they are synonyms and you should stick to one term consistently.
Both A and B. In this case, use the explicit conjunction “and.”
A or B. In this case, use the explicit conjunction “or.”

Adverbs

Words that end in -ly often are ambiguous. They might describe some desirable property of the product, but exactly what is desired is left to each reader’s interpretation. Here are a few examples:

“Allows the user to edit his interests and possibly search results …” Should the user be able edit the search results or not?
“Optimize upload and download to perform quickly.” Is five seconds considered quick?
“Offer significantly better download times.” State exactly how much better or give a range for precisely what the download time should be.
“Subscribers who are changing content selection (effectively a subset of the currently subscribed subscribers) …” Are they a subset or not?
“Exposing information appropriately …” What’s considered appropriate?

Be specific when describing the intended product’s characteristics so all readers share a common vision of the desired result when they’re done.

Read Karl Wiegers’ paper, “Writing High-Quality Requirements,” to learn what else goes into crafting successful requirements.

When a requirement can be interpreted in more than one way, problems ensue. In his paper, “Writing High-Quality Requirements,” expert Karl Wiegers gives examples of ambiguity issues in requirements and best practices to successfully clarify them. Here are five sources of ambiguity and tips to overcome.

Complex Logic

Boolean logic offers many opportunities for ambiguities and missing requirements. Try using a decision tree to reveal gaps and ensure clarity.

Omissions

When requirements lack important pieces of information, it’s unlikely that all readers will interpret them in the same way unless they make precisely the same assumptions. Be sure to include trigger causes that lead to the behavior and indicate what is required to happen because of or after the behavior. Further, specify the action as well as the reverse operation as part of the requirement. For example:

“The system shall display the user’s defined bookmarks in a collapsible hierarchical tree structure.”

Changes to:

“The system shall display the user’s defined bookmarks in a collapsible and expandable hierarchical tree structure.”

Boundaries

Boundary values in numerical ranges are common sources of ambiguity, and they are a good place to look for missing requirements. One easy way to resolve boundary confusion is to show the information in a table. If you see a number represented in two ranges, you know something needs fixing. Conversely, if there is no value in one of the table’s cells, you can quickly identify the missing requirement.

Synonyms

Using synonyms to describe the same thing across different requirements unnecessarily introduces ambiguity. Will the reader automatically know you mean the same thing or might they assume them to be different? If they are truly identical, use the same word consistently. If there are differences, even subtle ones, place such definitions in a shared glossary so team members understand the terms and use them consistently.

Pronouns

Pronouns can be a source of headaches in a requirements specification. Be certain that the antecedent is crystal clear whenever you employ a pronoun. If you use a word such as this or that, there should be no confusion in the reader’s mind about what you’re referring to.

Learn more requirements best practices from expert Karl Wiegers. In his paper, “Writing High-Quality Requirements,” he explains they begin with proper grammar, well-constructed sentences and a logical organization.

In today’s hyper-competitive marketplace, companies are releasing products faster than ever before. However, that increased emphasis on time to market doesn’t change the expectations: producing quality products while, when necessary, conforming to all relevant safety and quality standards.

Finding that critical balance between speed and quality is essential for product teams, which is where requirements management comes into play. Unfortunately, a lot of teams don’t take the time to flesh out requirement details – or they have the opposite problem and provide too many details, and confuse requirements with design specifications. Here are some examples and recommendations to make sure you’re getting the most value from your requirements.

Scenario 1: I need more details!

In this situation, teams fall into a trap of not taking the time to define requirements. For example, a marketing team — which tend to think more strategically — will often give high-level problem statements directly to an engineering team, which typically thrive on details.

What happens next is either:

1. Engineering team builds a product that doesn’t solve the high-level problem

Engineering team will bombard the marketing team with requests for additional information until both sides are frustrated and late on delivery

Neither scenario results in a smooth development process, and both can breed mistrust between teams whose ultimate goal is the same, in spite of their differing roles.

Well-formed and reviewed requirements clear the path for a quality product that meets market needs and expectations.

They ensure each team member is on the same page, and that everyone involved knows exactly what they’re building and why.

Scenario 2: Too many details – I can’t innovate!

In this case, the team members responsible for authoring requirements can sometimes cram too many design details into the requirements themselves. For example, I once saw a requirement that read: “the button shall be red and shall be located in the top-right corner of the console.”

First off, that’s actually two requirement statements – but either way – it’s describing implementation detail and, taken on it’s own, I have no idea of “what” the button should do or “why.” Is this supposed to dispense a soda from a vending machine or fire a missile from a battleship?!?

Requirements like these create friction within engineering teams, limiting their ability to innovate while getting bogged down with overly specific instructions.

Engineering teams should ideally be free to iterate and innovate the design rather than simply doing what they’re told. The requirements should focus on the need and keep teams aligned on “what” is needed and “why” while engineering experts figure out “how” to implement.

Recommendation: Establish a Common Taxonomy and Trace Model

An important step in striking the right level of detail in your requirements is establishing common terms in your product development process.

Many teams use different terms to refer to the same thing (e.g. “specification” – this term means so many different things across different teams).

Having a glossary or standard that clearly delineates important terms and deliverables facilitates clarity throughout the development process and reduces the confusion referenced above.

Using a traceability model establishes appropriate hierarchy and helps break down high-level problems to detailed requirement needs. It also can facilitate test coverage of requirements. This clarity is especially important when dealing with life-critical systems, such as medical devices or autonomous vehicle systems. In these cases, missing requirements or inadequate design and testing can quite literally cost lives.

Finally, teams should be able to differentiate Requirements from Design. In other words, the “Need” vs the “How.” Bundling both together inside requirements can lead to added complexity, unnecessarily constrained design, and friction between teams.

Quickly bringing a quality, safe product to market is a challenge. Requirements and design are both key elements to doing so. Making sure teams strike the right level of detail in the requirements is critical in avoiding confusion and reducing friction in the process.

For a deeper dive on separating requirements and design specifications, check our this webinar, “Best Practices for Writing Requirements.” Jama also offers Requirements 101 workshops – please inquire if you’re interested in improving the requirements process in your organization!

A version of this blog post first appeared on requirementdoctor.blog.

I’ve met a lot of folks who have an unhealthy belief in requirements management as the sum total of requirements work needed.

For example, whenever I ask if someone works with requirements, almost immediately the conversation turns into two things: either a discussion on tooling (IT support in the shape of a relational database for tracing different requirement statements to and from each other) or a conversation around the need to change to more Agile ways of working using methods like User Stories, Personas, Modeling, etc.

The thing is, I asked if someone works with requirements. Not about tools or development processes or methods.

What are requirements?

Requirements are capabilities that a product must meet to satisfy a stakeholder’s need to solve a specific problem. The stakeholder’s needs can come from a number of sources, including compliance to a standard or regulation, a business need, a technical situation, market need, competition, etc.

So, why are so many discussions around tooling or Agile methods?

My sense is that:

A: People don´t know that requirements are really used for

B: They don’t understand why they work with requirements in the first place.

If we consider the definition of the discipline of Requirements Engineering (i.e., all things associated with requirements) it’s this:

“Requirements Engineering (RE) refers to the process of defining, documenting and maintaining requirements in the engineering design process.”

So, when I put requirements and process together, I end up with the notion of being able to understand a need and/or problem, defining it in a suitable way (notation technique, language and “chunks”) and maintaining this clearness throughout the project to solve the specific need and problem.

That’s the boiled down version.

That means to get from point A (the problem) to point B (the solution), I need to do a lot of clever stuff to understand, define, build, prove and deliver B to satisfy A.

The way of working (that endless discussion about development methodologies) is of lesser importance here. You still need to validate in some way that you have understood the problem before you start to building a solution.

To solve complex things, I need to develop suitable pieces of this puzzle and give these to the people helping me. To do this, I typically need clear pieces of information that, together with the other components, completes the picture.

I need to describe this specific, correct and unambiguous piece of information. This basically becomes a Christmas tree in shape, with the original need at the top, which is broken down and developed into those well-known requirement types of functions, constraints and capabilities we are used to seeing.

Each broken down requirement is derived to satisfy its originator one floor up in the hierarchy. For this, we need to keep control over the links that become one of the results of this activity.

How can we otherwise know what will become the consequence of a change?

But is requirements management enough?

So, back to the question on a requirements management tool. Is it enough to have a tool for managing those requirements and links?

No, absolutely not! Have your heard the phrase “garbage in, garbage out?”

If you only focus on the management part of requirements engineering, you’ll create an over reliance on the tool to show when a link requires an overview due to a change somewhere.

Haven’t you forgot one thing?

Requirements are stated by humans for humans, and the knowledge captured because of a decision to state a new requirement in the first place must be captured in the original sentence.

A badly-formulated requirement is therefore the parent of a lot of new requirements, with all of them inheriting the bad genes:

Why requirements quality is important

Don’t get me wrong. Requirements management IS important, I agree 100%.

One needs to be able to trace requirements to do impact analysis on suggested changes, do testing in a clever and incremental way and basically have an idea when to be done with the project, but…

Wrong information derived and traced into more low-quality information will lead to disaster.

A recent study showed that of all failed projects investigated, more than 40% concluded that failure was because of bad requirements or being unable to understand the true stakeholder’s need in the first place.

If you are lucky, your project won’t fail due to bad requirements. Maybe you’ll “only” get a lot of late design changes, angry test teams, frustrated project managers, failed financial goals and unhappy customers.

You better stop saying that you are good at requirements ONLY because you own a RM tool!

Without good engineering practices to discover and formulate the correct and consistent requirements and making that specification complete (to describe full need of functions, qualities and constraints), you will still have huge problems, RM tool or no RM tool. Garbage in is, and will always be, garbage out.

PS: The rest of the people in that study who didn’t blame the requirements for their recent project failure, blamed the project manager. Just so you know. The story continues and so will the failed projects…

Register now to join the author of this blog post, Christer Fröling, and Jama Software for a webinar, “Garbage In, Garbage Out: How Poor Requirements Inhibit Systems Development.”