Tag Archive for: Strategic SEO Content Project

When we buy a new cell phone or TV or computer, do we buy-in for what it is?

Of course not. We buy it for what it will do for us.

Likewise, when companies or governments buy new systems or new enterprise software products, they couldn’t care less about the products themselves. What they care about is how those products will help them accomplish their goals, make them more efficient, and positively impact their bottom line or use of budget.

It’s what the product does that’s important.

In general, the first step in determining what a product does—what its functions are—is to determine its functional requirements.

What are functional requirements? And what is their role in product development?

In this article, we’ll answer those questions, provide examples of typical functional requirements and types of requirements, and offer tips for crafting good functional requirements and good functional requirement specifications.

What are functional requirements in product development?

A functional requirement is a statement of what a product (system, subsystem, system component, device or software program) must do.

Types of functional requirements include prescriptions of (rules for):

Operations and workflows the product must perform (i.e., the functional details of the product’s features)
Formats and validity of data to be input and output by the product
User interface behavior
Data integrity and data security requirements
What the product must do to meet safety and other regulatory requirements
How the system validates user access/authorization for use and modification of the system

The difference between functional requirements and non-functional requirements

The term functional requirements implies there must also be a group classified as non-functional requirements. That is indeed the case. Here are definitions of both:

A functional requirement is a statement of what a product (system, subsystem, device, or software program) must do.

Example: The control system shall prevent engine overspeed.

A non-functional requirement is a statement of what a product is or how it will be constructed, or a constraint on how the product will be designed or will behave.

Example: Serial-digital communication between the system’s subsystems shall be accomplished via MIL-STD-1553B bus(es).

Functional Requirements

As mentioned, functional requirements state what the product must do. In other words, they define the operation of the product. As such, they should normally be stated in terms of what the product’s outputs do in response to its inputs.

In product development, functional requirements are typically decomposed into more detailed requirements at progressive levels of the design process. Their fulfillment is verified and validated through functional testing (software testing, integration testing, etc.). Functional requirements are always mandatory; they must be met by the product unless the requirement is changed.

Non-functional Requirements

Non-functional requirements state constraints on the design and construction of the product. They are often dictated by contractual or regulatory requirements, which may include, among others:

Standardization requirements
Compatibility requirements
In-service support requirements
End-of-life disposal requirements.

Non-functional requirements are not often decomposed into more detailed requirements. They are typically verified by inspection of the product and its documentation. Non-functional requirements will be mandatory if dictated by contractual or regulatory requirements. They may not be mandatory, however, if dictated by marketing goals or other internal objectives, as often occurs in consumer product development.

RELATED POST: Nonfunctional Requirements vs. Functional Requirements – What’s the difference?

Forms and examples of functional requirements

Functional requirements can come in many forms. Some forms, however, are better than others. A general requirements engineering (RE) best practice is to write requirements that are as clear and concise as possible.

Engineer Alistair Mavin, developer of the Easy Approach to Requirements Syntax (EARS), has identified five requirements archetypes—and a simple template for each—that can be used to craft clear, concise requirement statements that cover practically all functional specification needs.

Ubiquitous Requirements

The first of these archetypes is the ubiquitous requirement.

Ubiquitous functional requirements are always active. They are not invoked by an event or input, nor are they limited to a subset of the system’s operating states.

Template: The <system name> shall <system response>.

Example: The control system shall prevent engine overspeed.

State-driven Requirements

State-driven functional requirements are active throughout the time a defined state remains true. In Mavin’s EARS method, state-driven requirements are identified with the keyword WHILE.

Template: WHILE <in a specific state> the <system name> shall <system response>.

Example: While the aircraft is in-flight and the engine is running, the control system shall maintain engine fuel flow above ?? lbs/sec.

Event-driven Requirements

Event-driven functional requirements require a response only when an event is detected at the system boundary. In other words, they are triggered by a specific event. The EARS method identifies event-driven requirements with the keyword WHEN.

Template: WHEN <trigger> the <system name> shall <system response>.

Example: When continuous ignition is commanded by the aircraft, the control system shall switch on continuous ignition.

Optional Feature Requirements

Optional feature functional requirements apply only when an optional feature is present as a part of the system. These requirements are identified by the EARS method with the keyword WHERE.

Template: WHERE <feature is included> the <system name> shall <system response>.

Example: Where the control system includes an overspeed protection function, the control system shall test the availability of the overspeed protection function before aircraft dispatch.

Unwanted Behavior Requirements

Unwanted behavior functional requirements cover all undesirable situations. Good systems engineering (SE) practice anticipates undesirable situations and imposes requirements to mitigate them.

Unwanted behavior requirements are often imposed when the system must respond to a trigger under less than optimum conditions. The EARS method uses the keyword combination IF/THEN to identify requirements aimed at mitigating unwanted behavior.

Template: IF <trigger>, THEN the <system name> shall <system response>.

Example: If the computed airspeed is unavailable, then the control system shall use modeled airspeed.

Complex Requirements

Often, a specific set of one or more preconditions (states or optional features) must be present before the occurrence a specific event for that event to trigger a required system response. In such cases, the EARS templates may be combined, using a combination of the keywords.

Complex requirements can be composed for desired behavior or for unwanted behavior. The EARS method provides a template for each.

Template: (Desired behavior) Where <optional feature>, while <precondition(s)>, when <trigger> the <system name> shall <system response(s)>.

Template: (Unwanted behavior) Where <optional feature>, while <precondition(s)>, if <trigger> then the <system name> shall <system response(s)>.

Example: While the aircraft is on the ground, when reverse thrust is commanded, the control system shall enable deployment of the thrust reverser.

Tips for writing good functional requirements

Writing clear, accurate functional requirements is a valuable engineering skill that requires some practice to develop. That’s why many engineering organizations compile guidance on writing requirements, like the Guide for Writing Requirements published by the International Council on Systems Engineering (INCOSE).

An exhaustive list of such guidelines is beyond the scope of this article, but here are six important tips to bear in mind when composing functional requirements:

1. Be consistent in the use of modal verbs

A modal verb, modal or modal auxiliary is a word such as “shall,” “must,” “will,” or “should” which is used with a main verb to express ideas such as necessity, intention, expectation, recommendation, or possibility.

In engineering specifications, modal verbs are used to distinguish between binding requirements, non-binding recommendations, and the expected behavior of the system’s operational environment. As such, it is important that requirements authors be consistent in their use of modal verbs and that they convey to developers, testers, quality assurance engineers, and regulatory authorities exactly how each modal verb is intended to be interpreted within their specification.

The use of modal verbs in specifications has long been a subject of debate in the SE/RE community. The consensus, however, is that “shall” and “must” are the best modal verb choices for expressing requirements, while “will” should be used to express expected external behavior or declarations of purpose. Non-binding recommendations or provisions can be expressed with “should” or “may.”

Also, many organizations use the word “must” to express constraints and certain quality and performance requirements (non-functional requirements). The use of “must” allows them to express constraints without resorting to passive voice and to easily distinguish between functional requirements (expressed with “shall”) and non-functional requirements (expressed with “must”).

It is good SE/RE practice to define exactly how certain terms will be used within the document itself, and how they should be interpreted when found in non-requirements documents referenced by the document. This is usually done in a dedicated section toward the beginning of the specification.

2. Tag each requirement with a unique identifier

Another SE/RE best practice is to tag each requirement with a unique ID number or code.

In fact, requirement identifiers are often a requirement themselves. Systems purchased under a contract between a customer and a supplier—as in the case of most government-purchased systems, for example—are normally developed following an accepted industry standard like IEEE/EIA 12207 as a stipulation of the contract. Such standards typically require that each requirement in every requirements document be tagged with a project unique identifier (PUI).

Assigning unique identifiers to requirements conveys a big benefit to the system developer.

Tagging each requirement with a PUI facilitates and simplifies traceability between requirements at successive design levels and the tests that verify them. Brief identifiers make it easy to build traceability tables that clearly link each requirement to its ancestors in higher-level documents, and to the specific tests intended to verify it. Traceability tables simplify the process of demonstrating to the customer and internal stakeholders that the system has been developed to, and proven to comply with, the agreed top-level requirements.

Automated requirements management tools typically include an automatic method of assigning unique identifiers, which streamlines this process.

3. Write only one requirement in each requirement statement

Beware of long, complex requirement statements that include the word “and” and more than one modal verb.

When trying to define a complicated functionality, it’s easy to fall into the trap of describing it all in a single paragraph or, worse yet, in a single sentence. Take the time to analyze long requirement statements. If they contain the word and or multiple “shalls” or other modals, they likely contain more than one requirement. Re-write them to obtain two or more simple requirement statements, each with its own shall. Then, give each its own unique identifier.

4. Write requirements statements as concisely as possible

Another reason to analyze and re-write long requirements, even those with a single shall, is that long requirements are more likely to be misinterpreted than short, concise requirements.

It is good SE/RE practice to write requirements that are as concise as possible. Requirements templates, like the EARS patterns described earlier, can be of great assistance in meeting this objective.

5. Make sure each requirement is testable.

Each time you write a new functional requirement, you should ask yourself the following question:

How will the successful implementation of this requirement be verified?

Writing requirements with a specific test scenario in mind helps ensure both design and test engineers will understand what they have to do.

The specific test case will influence how detailed the requirement will need to be. High-level requirements are often tested by inspection or through user testing and thus may be broad in scope. Lower-level requirements that will be verified through software testing or system integration testing will necessarily be specified to a finer degree of detail.

For example, a best practice for ensuring testability is to specify a maximum reaction time for any output the software must produce in response to a specific input condition, as in this example:

3.8.5.3.1: The Engine Monitor shall set <Overtemp Alert> to TRUE within 0.5 seconds when <Engine Temp> equals or exceeds 215° F.

6. Clearly segregate requirement statements from rationale and other explanations.

In requirement specifications, it’s useful to include the rationale for the requirement, its relationship to other requirements, and other explanation to provide context for developers and testers.

Context can help prevent misinterpretation by clearing away possible ambiguities. It can help others fully understand the intent of the requirement and provide feedback that can help refine the requirement and make it even more unambiguous.

But contextual information should not be included in the requirement statement itself. It’s important to segregate the two to keep the requirement itself clear and concise, and to avoid making the additional information subject to implementation and test. It’s a best practice to put contextual implementation in a separate paragraph that does not contain a unique identifier.

A good Functional Requirements Document template or Requirements Management tool can make this goal easier to achieve.

What is a Functional Requirements Document?

A function requirements document (FRD)—also known as a functional requirements specification, functional specification, or functional specification document—is a more technically detailed follow-on to the higher-level Product Requirements Document (PRD).

The FRD describes what is needed by the system user, typically in terms of the system’s outputs as functions of its inputs. It is built to provide precise functional requirements—along with guidance to developers and testers—following analysis and decomposition of the requirements in the PRD.

An FRD does not define the inner workings of the system to be developed or how the system’s functions will be implemented. Instead, it focuses on what various external agents (users, peripherals, other systems or subsystems) should observe when interacting with the system. It communicates:

To developers: what they need to build
To testers: what tests they need to perform
To stakeholders: a detailed description of what they’re going to get

For highly complex systems, functional requirements may be decomposed through a series of functional specifications that may include:

System specification
Subsystem specifications
System component specifications
Software requirements specifications

In some industries and organizations, the functional specification will normally be part of a larger specification that also contains the non-functional requirements applicable to the system or subsystem to be designed. Nevertheless, those non-functional requirements will typically be segregated from the functional requirements.

Tips for compiling a good FRD

Putting together a cohesive, usable and easily navigable and FRD can be a challenge. Here are a few guidelines that can be helpful.

1. Organize the document in a hierarchical structure

To make your FRD easy to understand and use, organize it using a hierarchical structure. Suitable hierarchies can include (among others):

Mission/phase/function
Function/subfunction
Feature/use case

A hierarchical specification structure provides several benefits, including:

Helps contributors focus on each specific domain that needs to be addressed
Helps contributors easily find areas they need to modify when adding functionality to an existing system
Helps users (developers, testers) quickly drill down to the exact functional area they are looking for

2. Standardize your requirements language

Spoken languages are full of words that have multiple definitions and which evoke subtle shades of meaning, depending on context. While great for self-expression, such broad flexibility can lead to confusion and disagreement when it comes to specifying and interpreting requirements.

A good way to reduce ill-definition and misinterpretation of requirements is to standardize some of the language used to express them. Create a glossary of standardized terms toward the beginning of your requirements document. In this glossary, define exactly how certain terms will be used within the document itself, and how they should be interpreted when found in non-requirements documents referenced by the document.

Strictly defining terms and adhering strictly to your definitions will not only reduce confusion among those tasked with interpreting your requirements; with practice, using standardized language will also save you time in writing requirements.

3. Use a good FRD template or a dedicated RM platform

When building any type of structure, it’s wise to start from a solid foundation or a proven model. When building a functional requirements document, it’s best to start from a good template.

A good template will include standardized sections such as:

Guidelines for the use of modal verbs
Glossary of standardized terms
Guidelines for documenting requirements
Guidelines for managing requirements documentation
Other guidelines your organization follows

Standardized sections—or “boilerplate”—promote and facilitate consistency across projects, which is a major benefit of templates. These sections tend to remain little changed from project to project, and from team to team within a company. They evolve only slowly over time with changes in methodology and lessons learned. Thus, they provide a stable platform for consistent requirements development, employee education, and communication with customers.

There are many general FRD templates available on the web. If you develop commercial products you may find one of the following can be tailored to your company’s practices and procedures:

If your company develops systems or software for the U.S. Department of Defense, on the other hand, you might prefer a system specification template built to MIL-STD-961E (Department of Defense Standard Practice: Defense and Program-Unique Specifications Format and Content). QRA Corp offers one on their website: https://qracorp.com/requirements-document-templates/.

The drawbacks of templates

One caveat to the last tip: using a template in a general documentation platform has a couple of drawbacks. First, documenting requirements in Word, Excel or Google Docs tends to make collaboration cumbersome. Second, those platforms are not built to support clear and systematic requirements traceability.

Gartner says that one of the main reasons companies struggle to achieve adequate visibility and traceability in their requirement specifications is reliance on general document software rather than a collaborative requirements management platform.

“The most widely adopted tools for requirements continue to be general document software such as Microsoft Office or Google Docs (40% to 50% of the market) due to cost, availability, and familiarity. Yet these often lead to poorly managed requirements, thus eliminating and exceeding any cost benefit the tools themselves have. Requirements end up captured in a variety of documents and spreadsheets supplemented by post-it notes in unmanaged versions with no traceability or reuse. This creates a more costly user acceptance testing cycle, both in the time to execute as well as remediation of issues found late in the process, where they are far more costly to address.” – Gartner Research

Successful development, verification, and validation of good functional requirements are critical to product success. To achieve these goals system, software, hardware, test, and integration teams all must work closely together to assure the project’s functional requirements, non-functional requirements, test cases, and verification/validation procedures are all adequately defined. Visibility and traceability are critical to this process.

A good requirements management (RM) platform will provide fields, formatting, and structural relationships to facilitate:

Portability of boilerplate sections from project to project
Requirements definition and identification
Traceability to higher-level (parent) and lower-level (child) requirements
Traceability to test cases

Beyond those basic facilities, a state-of-the-art RM platform will also facilitate team collaboration by allowing all users access to your latest requirements baseline and all pending changes to it. This makes requirements tracking, traceability, and test coverage assurance far easier to accomplish than can be done using a document or spreadsheet.

Learn more about how Jama Connect streamlines tracking and tracing requirements. See the solution.

Requirements management (RM) is a challenge for many companies, partly due to the ambiguity involved in software development. First, you must understand the client’s requirements. Second, you must match those requirements to critical processes.

RM is a component of requirements engineering (RE), which bridges the divide between a client’s needs and what developers create. When done well, RE has the ability to create a solid framework for software development, which is critical since poor software engineering requirements management is a root of many project failures.

A CIO magazine study found that “Analysts report that as many as 71% of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure.”

In 1999, NASA built the $125 million Mars Climate Orbiter probe. The probe failed because it entered orbit 100 kilometers too close to Mars. The source of the error was incompatible specifications; an important component of RE.

Understanding the details involved in requirements engineering and best practices can set you on the path to successfully meeting client expectations.

What is requirements engineering?

Clients have a long list of goals when creating new software, and RE provides a framework for meeting those goals. Important needs are inventoried and transformed into a detailed set of requirements. Requirements development dictates future development activities and creates a blueprint for success.

The terms requirements management and requirements engineering are often used interchangeably, but they are different. RM is one piece of requirements engineering, and getting it right makes all the difference.

RE ensures that the problem a client wants solved is clearly defined and the solution is both accurate and effective. Essentially, RE transforms a real-world problem into a highly functional software solution.

The 4 steps of the requirements engineering process

The requirements engineering process has many potential pitfalls. Strengthening your RE process enables you to avoid many common challenges. The process serves as a compass, guiding you in determining the exact deliverables and doing so with greater accuracy. All important parties are on the same page about what steps need to be taken to achieve the desired outcome. Strengthen your RE process by considering the following:

Elicit requirements. Elicitation is about becoming familiar with all the important details involved with the project. The customer will provide details about their needs and furnish critical background information. You will study those details and also become familiar with similar types of software solutions. This step provides important context for development.

Requirements specification. During the specification phase, you gather functional and nonfunctional project requirements. A variety of tools are used during this stage, including data flow diagrams, to add more clarity to the project goals.

Requirements verification and validation. Verification ensures the software is implementing the right functions. In contrast, validation ensures the software is built to the customer’s requirements. If the requirements don’t go through the validation stage, there is the potential for time-consuming and expensive reworks.

Requirements management. During RM, you’re matching all the relevant processes to their requirements. You will analyze, document and prioritize the requirements – and communicate with relevant stakeholders. Any requirements that need modification are handled in an efficient and systematic manner.

As you implement the different components of RE, it also helps you get a sense of what should be excluded from requirements. Understanding this will help you focus more accurately on developing requirements and better meeting client expectations.

What information should be excluded from the requirements?

Requirements should be viewed as addressing a problem, but not necessarily as providing a solution. A requirement should clearly state what you want to solve, not how you want to solve it. Let’s take a look at guidelines for good requirements:

The requirement accurately defines the need of the stakeholder.
The requirement is testable.

A requirement needs to be clear and understandable, without the risk of ambiguity. An important step in developing good requirements is the review process. Does the requirement accurately express the needs of the stakeholders? Make sure to build in enough client reviews so that you can get early feedback and adjust as needed.

RELATED POST: Nonfunctional Requirements vs. Functional Requirements – What’s the difference?

Common mistakes to avoid

There are many challenges that may occur as you develop your RE framework. Understanding potential issues can help you avoid them. Consider the following as you develop your processes:

Avoid scope creep. There is a temptation to add “just one tiny new requirement” to make the client happy. But these little changes add up and may have an impact on future activities, such as testing, documentation and more.
Resist the urge to “over-engineer.” Over-engineering can be tempting, especially when you want to make sure everything is just right for the client. But this overzealousness can backfire. Adding a little extra code because “I’m doing this, I may as well do that” might seem logical, these changes can create a ripple effect, putting requirements at risk in the future.
Build in enough feedback and reviews. Early feedback is essential to a project’s success. Build in frequent reviews and solid traceability to get feedback often and early.
Search for all the important stakeholders. You might think you’ve included all the important stakeholders, only to learn you missed one later on. Invest time early in the process to find any and all important stakeholders in order to avoid expensive reworks later in the process.
Identify potential resistance early in the process. Resistance can be an invisible but serious project problem. Learn to identify resistance early in the process so that you can work through it efficiently and early, getting everyone on the same page.

Awareness about these potential pitfalls can save you time, money and resources during the RE process. Also, look at your existing processes and whether they include enough traceability. Ensuring that deliverables meet requirements, for example, is much easier if every requirement is linked to at least one test. And traceability is an essential part of this process.

Engineers can then invest their energy into requirements that are failing the test and get the project back on track quickly.

Leveraging the right tools for success

Requirements engineering is critical to the success of a project because it tells everyone involved with the project what needs to be done. A project manager, who schedules tasks, can do so based on more accurate requirements. A requirements management software tool can greatly support successful RE, as it enables more efficient and optimized product and system development.

This type of tool can provide:

Clarity and visibility. Get broader visibility into what you’re building and why.
Live traceability. Ensure product quality and improve change management with complete traceability.
Decision tracking and fast reviews. Conduct virtual reviews of requirements, test cases, user needs and more.
Real-time collaboration. Immediately note and prioritize important decisions, pull in the required stakeholders and reference historical context to eliminate communication errors.

The right tool can help you transform RM as you easily track, review, sign off on and truly understand how and why you did certain things. As a result, you can streamline your product development process and increase efficiency, understand and respond to change, and establish a higher level of clarity and visibility.

See how Jama Connect can help with requirements engineering by downloading our solution overview.

Whether you’re just learning the basics of requirements management, looking to improve your current requirements management process, or interested in benchmarking your process against industry leaders, you’re in the right place.

This article covers what requirements management is, why managing requirements matters, what the requirements management process entails, and how to manage requirements when creating complex, highly regulated products.

What is a need?

A need is an agreed-to expectation for a product or system to perform some function or possess some quality within specified constraints with acceptable risk. Needs communicate what the stakeholders need and expect from a product or system in order for a given problem or opportunity to be addressed.

What is a requirement?

A requirement is the result of a formal transformation of one or more needs or parent requirements into an agreed-to obligation for a product or system to perform some function or possess some quality within specified constraints with acceptable risk.

There are different types of needs and requirements that range from a business focus to a user focus to a technical focus.

Business needs and requirements, sometimes referred to as stakeholder needs and requirements, are those derived from the business processes or elicited from the stakeholders including customers, users, and other stakeholders involved in the project. The stakeholder needs represent what the stakeholders need the product to do to address the problem or opportunity the product is to address; stakeholder requirements are stakeholder-own product requirements that communicate what the stakeholders require of the product to meet their needs. Stakeholder needs are expressed in natural language without the use of “shall”, while stakeholder requirements are communicated with “shall” to make sure they are treated as binding requirements the product will be verified to meet.

Given there are multiple stakeholders, there will be multiple sets of stakeholder needs and requirements. It is up to the project team to elicit these needs and requirements, resolve conflicts, inconsistencies, and other issues. The results will be an integrated set of needs from which the product requirements will be transformed from. The resulting product requirements represents what the product must do in order for the needs to be met. Product requirements are sometimes referred to as system requirements, software requirements, or technical requirements.

What is requirements management?

Requirements management is the process of gathering, analyzing, verifying, and validating the needs and requirements for the given product or system being developed. Successful requirements management ensures that completed deliverables meet the expectations of the stakeholders. Requirements can be managed using documents, however, complex systems or products in highly regulated industries mitigate risk by using trusted requirements management tools.

Why is requirements management important?

Requirements management is important because it empowers everyone to clearly understand stakeholder expectations and confidently deliver a product that has been verified to meet the requirements and validated to meet the needs.

Requirements management is a sophisticated process that includes many moving parts and diverse groups of people. Typically, the product management department, specifically the product manager, is responsible for the requirements management process. They work with the stakeholders, including business teams, customers, users, developers, testers, regulators, and quality assurance.

Additionally, a product may have only 100 requirements, or it may have several thousand. This depends on its complexity and level of regulation. With all these elements at play, success hinges on the ability to get everyone on the same page, working toward the same goal.

Therefore, the business value of managing requirements is huge, as successful requirements management is key to project success. Benefits of requirements management include:

Enhance understanding of stakeholder needs, requirements, and expectations and the problem or opportunity the product is to address
Gain clarity on scope, budget, and schedule
Minimize costly and time-consuming rework
Increase product quality
Mitigate risk
Improve likelihood of delivering the right product, within budget and schedule with the required quality.

The importance of requirements management is intensified, however, when building complex or highly regulated products. This is because more time and budget are invested in development. The cost of getting it wrong — be it money, time, or reputation — is too great to risk. Hence, developers in regulated industries, or those who develop products with a lengthy list of needs and requirements, tend to rely on requirements management tools, like Jama Connect® to keep their projects in order.

Requirements management vs. project management

While it may seem that requirements management and project management are synonymous, there is a difference. Simply, project management is getting the product built within budget and schedule with the available resources. Requirements management is making sure the product is the right product built right.

The goal of the product development process is to create a successful product that meets stakeholder, customer, and market needs. The requirements management piece of product development includes managing the needs and requirements so that the product meets stakeholder expectations. Therefore, needs and requirements along with budget and schedule set the scope for the project.

However, the domain of project management encompasses tasks like providing budget, personnel, and resources needed to develop the product.

Stages of the requirements management process

So, how do you manage requirements? The most successful teams work from a defined requirements management process. Defining the requirements management process is important because requirements change throughout a project. When this happens, that change needs to pass through the same, repeatable process.

There are four main stages of the requirements management process — planning, development, system verification, and system validation — each with important considerations to the overall project. Change management, while not a stage itself, affects nearly every phase of the requirements management process.

Planning Stage

The product development methodology—waterfall, agile, or Scrum—helps decide how requirements move through the process. Waterfall models are typically linear with development moving from one process area to another with a completed product delivered with the required features and functionality. Agile development, including Scrum, is iterative in nature. In requirements management, agile teams, and those using the Scrum approach, may be working on different sets of requirements concurrently, delivering a product in increments, each increment adding value with additional features or functionality.

No matter which methodology is employed, the RMP is the documented process the team uses throughout product development. It contains information like stakeholder roles and responsibilities, which needs and requirement artifacts will be defined, how traceability will be competed and managed, how needs and requirements baseline will be handled, how interactions (interfaces) with external systems and users will be managed, how changes will be managed, how the product will be verified to meet the requirements, and how the product will be validated to meet the needs.

A successful Requirements Management Plan is visible to and has sign off from stakeholders, as it sets the course and expectations for all stakeholders throughout the product development journey.

Needs and Requirements artifacts

Part of the RMP is defining the needs and requirements artifacts that will be created during the requirements management process.

Needs and requirements artifacts include the data and information concerning the needs and requirements and related information. Examples include diagrams, and models, integrated set of needs, set of product requirements, use cases, design documents, testing plans and procedures. Requirements artifacts are used throughout the product development lifecycle to:

Describe the product being built
Identify the actions needed to develop the product
Capture the actions performed during development
Define the testing needed for system verification and system validation
Assist with stakeholder review, communications, and engagement

While some organizations will communicate this information in a document form (e.g., a Software Requirements Specification (SRS)), the increasing trend is to manage the needs and requirements within a requirements management software application.

The reason organizations are moving towards a data-centric practice of product development is that is hard, for any document-based approach to be flexible and scalable enough for complex agile projects. This is especially true for highly regulated industries that must prove compliance. Due to numerous factors—lack of consistent updating, human error, incomplete data, version control, the need to establish and maintain traceability, etc.—documents simply cannot be relied upon determine whether a need or requirement is fulfilled.

Agile product teams working on complex products in highly regulated industries will have much more success using a requirements management software application to streamline the requirements analysis phase of requirements definition and management. Modern requirements definition and management solutions, like Jama Connect®, define, establish traceability, manage, and validate complex product requirements automatically, which simplifies not only requirements analysis, but the overall requirements definition and management process.

It is imperative that needs and requirements and needs and requirements artifacts are linked to each other and to additional related artifacts. This can be difficult to achieve using documents, as the manual nature lends itself to myriad errors. This is especially true in the case of complex or highly-regulated products where traceability is a prerequisite for proving compliance.

Needs and Requirements attributes

To keep track of the requirements in a given project, each requirement should have a specific list of attributes. Requirements attributes are used to ensure that requirements are organized and uniquely identified across all requirements artifacts. The attributes also aid in managing the sets of needs and requirements, enabling reporting and dashboards to be defined to provide accurate and timely status of the project.

It is a best practice that the following requirement attributes are included for all needs and requirements:

Unique Identifier
Rationale
Owner
Type
Definition status
Priority
Criticality
Compliance
Version number
Change history
Trace data
Verification status (for requirements)
Validation status (for needs)

Needs and Requirements Baseline

A needs and requirements baseline is a point-in-time look at a committed set of agreed-upon, reviewed, and approved needs and requirements, or planned functionality and features to be included in the product. The purpose is to provide information to stakeholders so they can make informed decisions on and possibly modify the planned functionality and features using change requests.

The RMP defines a baseline strategy including timing and frequency of creation, needs and requirements prioritization (deciding which requirements should be included), publishing, change management, requirements verification, and requirements validation. In this context needs and requirements verification address the quality of the needs and requirements statements as well as the existence and correctness of the traceability. Needs validation is confirmation with the stakeholders that the integrated set of needs clearly communicates the intent of the stakeholder in terms of what the need the product to do. Requirements validation is confirmation with the stakeholders that individual requirements and the set of requirements clearly communicate the intent of the needs they were transformed from. The quality of the requirements is dependent on the quality of the needs from which they were transformed.

Establishing a requirements baseline is important because it implies that:

Scope has been defined and agreed to – Critical to control scope creep!
Formal change control begins
Staffing levels and budgets are set
Schedule commitments are made

Typically, baselines are stored in software requirements specification (SRS) documents. However, a complex system might need a variety of software, hardware, and interface requirement specifications to encapsulate the baseline’s components. This can be cumbersome to maintain during initial development and downright impossible during change management.

Alternatively, working with baselines in a requirements management solution allows baselines to be defined as a subset of the requirements already stored in the database. This streamlines the process from prioritization through stakeholder sign off.

Requirements development stage

The development stage is conducted using the organization’s requirements analysis process.

The needs and requirements development stage incudes eliciting needs and requirements from the identified stakeholders, properly defining and refining them, and analyzing them to ensure clarity and resolve issues and conflicts. Without successful needs and requirements development there would surely be gaps between what the stakeholders expect and what is ultimately delivered. The result of which could be disastrous.

Eliciting needs and requirements

Also called needs and requirements gathering, eliciting needs and requirements is the act of working with users, customers, and internal business stakeholders to identify stakeholder needs and requirements and get an understanding of the product or system requirements.

Needs and requirements definition

Needs and requirements definition is the time when the gathered needs and requirements are re-written in a clear and traceable way that enables effective communication throughout the product development lifecycle.

There are many do’s and don’ts for writing needs and requirements, but the following are basic characteristics of quality needs and requirements:

Necessary
Unambiguous
Feasible
Verifiable
Correct
Traceable
Appropriate

A needs and requirement’s traceability is very important. At the end of the day, needs and requirements traceability is the only way to know if a need or requirement has been fulfilled by the design and built product. Bidirectional traceability—the ability to perform both forward and backward traceability, usually made possible via requirements management tools like Jama Connect—allows teams to understand why a specific need or requirement exists and easily analyze the impact of changes.

Furthermore, products in regulated industries must demonstrate traceability to prove compliance with standards and regulations. Therefore, when writing requirements, it’s paramount that each requirement maps to all corresponding artifacts.

A requirement’s traceability is very important. At the end of the day, requirements traceability is the only way to know if a requirement is fulfilled. Bidirectional traceability—the ability to perform both forward and backward traceability, usually made possible via requirements management tools like Jama Connect—allows teams to understand why a specific requirement exists, easily analyze the impact of change, and help prioritize requirements.

Furthermore, products in regulated industries must demonstrate traceability to prove compliance. Therefore, when writing requirements, it’s paramount that each requirement maps to all corresponding artifacts.

Many teams use a requirements traceability matrix (RTM) to track requirements and manage the scope of a requirements change. The RTM is static and maintained manually. The problem is that change is ubiquitous in the product development process. When change happens, teams must manually search the RTM document for all related upstream and downstream needs and requirements, dependent requirements and verification and valdidation tests that may be affected by the change.

Scouring through an excel spreadsheet for each change may not be that daunting if there are only one hundred or so needs and requirements. However, if the product has hundreds or thousands of needs and requirements—think complex, regulated products—managing the scope of change becomes a cumbersome and time draining exercise fraught with risk.

Requirements management tools are designed to streamline the process—even for highly complex, regulated products. Jama Connect, specifically, uses the benefits of Live Traceability™ to:

Easily determine the impact of change
Automate compliance
Enable end-to-end process improvement
Increase productivity
Reduce product risk
Increase quality

Requirements analysis

Sometimes, there is a gap between what stakeholders say they want and what they actually want. The purpose of requirements analysis is to ensure all business, software, and product requirements accurately represent stakeholder needs and requirements. The goal of requirements analysis is to get a clear understanding of stakeholder needs so the deliverable matches stakeholder expectations.

System Verification Stage

System verification means determining if the finished product meets the baselined product requirements. This is different than system validation (discussed below), which evaluates whether the product satisfies the stakeholder needs. are both important but system verification always comes first.

Planning for this stage starts when the product requirements are being defined. Planning includes, determining which system verification events are needed to confirm that product requirements are fulfilled.

To ensure successful system verification, the following attributes should be defined for each product requirement before the requirements are baselined, to set the expectations for the tests and quality assurance work that needs to be done and reduce the risk of rework efforts later.

Success criteria (what must be proven to show the requirement was met)
Method (test, demonstration, inspection, or analysis)
Strategy (approach to be used, operating environment, test environment, system configuration, etc.)

System Validation Stage

System validation means determining whether the product satisfies the stakeholder needs. are both important but successful system validation is what leads to product acceptance for its intended use, by the intended users, in the actual operational environment. For highly regulated products, approval for use is dependent on successful system validation. Final product acceptance by a customer also depends on successful system validation.

Planning for system validation starts when the integrated set of needs are being defined. Planning includes, determining which system validation events are needed to confirm that needs are fulfilled. One approach is to define a set of attributes that address system validation for each need.

To ensure successful system validation, the following attributes should be defined for each need before the needs are baselined, to set the expectations for the tests and quality assurance work that needs to be done and reduce the risk of rework efforts later.

Success criteria (what must be proven to show the need was met)
Method (test, demonstration, inspection, or analysis)
Strategy (approach to be used, operating environment, test environment, system configuration, etc.)

Challenges with requirements management

Requirements management has its share of challenges. As change management is so prevalent in the requirements management process, it’s a big hurdle teams need to address at the beginning of the project.

When building products that have thousands of requirements and countless changes, teams can spend hours circulating, editing, and tracking changes in an attempt to maintain traceability and simply keep development on track.

This is especially challenging when maintaining the needs and requirements in document form. Version control issues are one challenge that results from change. Versioning problems can arise on the artifact itself, for example someone might be giving feedback on SRS version one but there is already an SRS version two with different, additional edits. But version control can even be more granular, within the document as well. For example, requirement one might be on version three, which is linked to test B on version two.

Add that to consolidating feedback from multiple stakeholders via email or meetings, analyzing the impact of change across various versions of requirements artifacts, and communicating the correct changes and statuses to the right people. It’s a nightmare just thinking about how to keep it all straight.

The following are the top five challenges of requirements management:

Last-minute feedback
Decision rehashing
Change tax
Attention deficit
Mismatched expectations

It’s easy to recognize that problems are compounded when managing requirements using documents, or legacy systems based on documents, instead of a purpose-built requirements management tool. Most of these challenges, and more, can be overcome by switching from a document-centric to a data-centric approach to requirements management.

How to successfully manage requirements in complex products and highly regulated industries

The challenges above are real and mastering them can have significant impact on development timelines and budget. Developers in regulated industries — like automotive, aerospace, medical device, government, and industrial manufacturing — are further challenged by the need to prove compliance with regulations and standards.

Standards and Regulations can be a source of a large number of requirements the product must be compliant. Often not all of the requirements in a regulation or standard apply to your specific product. Often standards and regulations contain requirements not only on a product, but on the organization developing the product, as well as requirements concerning system verification and system validation (acceptance, certification, and qualification).

In addition, often requirements within standards and regulations are written poorly and ambiguously. As part of identifying drivers and constraints at the beginning of the project, the project team needs to identify which standards and regulations apply to their product and which requirements in those standards and regulations apply as well. Then they must write well-formed product requirements to address the intent of those requirements that will result in a product that is compliant with the applicable standards and regulations.

Regulations are not requirements. Requirements must be written to adequately satisfy the regulatory standards. A keen understanding of the standards or regulations is paramount in writing requirements that will lead to a product’s compliance. Once written, a regulatory requirement should be attributed as such in all requirements artifacts. This can be done be assigning a “compliance” attribute. This provides all team members visibility throughout development, which assists with decision making and change analysis.

In addition to expert knowledge of the standards and regulations, the following are needed to maintain product compliance when building a product:

Collaboration between teams
Single source of truth for defining, verifying, and validating compliance requirements
Standard frameworks aligned to standards and regulations
Traceability across all development activities and resulting artifacts.
Simplified audit preparation and data exports

Reporting is key when faced with a compliance audit. Teams must know what data is required for the audit and how to easily access it when needed. Often, audit trails are an afterthought in which teams are scrambling to pull together data from several sources. This is a dangerous practice, though, because it can risk delivery timelines and delay launch, or risk failing to launch altogether. Any teams that must show compliance, must eliminate this risk with a digital, detailed audit trail that can be easily exported whenever needed. Establishing and managing traceability is critical to be able to maintain the audit trail.

Many leaders in regulated industries rely on requirements management tools to reduce the risk of failure to comply with standards and regulations during the product development process. Jama Connect, for example, can track standards and regulations and compliance when building products. These industry leaders leverage Jama Connect to keep them at the forefront of innovation:

Benefits of requirements management tools

The advantages of requirements management tools are many. A modern solution can eliminate the risks and inefficiencies of documents and legacy systems.

A valuable requirements management system, like Jama Connect, can bridge engineering siloes throughout the development process, including test and risk activities. An effective tool helps improve the product development process by:

Ensuring quality and compliance
Managing risk
Increasing efficiency and optimizing processes
Easily understanding and responding to change
Improving traceability
Streamlining and accelerating reviews
Enabling real-time collaboration and iteration
Saving time
Improving quality

There are many requirements management tools available, but only a few that can help reap all the benefits listed above. When thinking about the most important features in a requirements management system, first think about what’s being built. The industry and complexity level will help inform the features that will be best for your team. This guide to buying a requirements management tool may also help.

From our experience, and what we hear from customers, the most important features of a requirements management system are:

Live bidirectional traceability
Real-time collaboration communication
Efficient and scalable review process
Simplified test and quality assurance management
Always-on risk analysis
Reusable requirements and baseline catalogs
Standardized validation and functional safety kits
Comprehensive visibility and compliance reporting
Fast implementation
Flexible configuration
Easy-to-use interface/administration
Automated integrations
Quality assessment of requirements and traceability

The good news is that you don’t have to pick and choose. Jama Connect helps navigate complexity and provides end-to-end compliance, risk mitigation, and process improvement with all the features listed above—and more.

See how Jama Connect can streamline complex requirements management.

Requirements analysis is a critical part of the requirements definition and management process in software development. The purpose of requirements analysis is to be sure all product requirements accurately represent stakeholder needs and requirements. When executed correctly, requirements analysis results in a set of product requirements that, when met, will result in a deliverable that matches stakeholder expectations.

What is requirements analysis?

The requirements analysis is the process of discovering stakeholder needs and requirements for a software application being developed. It confirms accurate capture, interpretation, and representation of the customers’, users’, and other stakeholder needs and transforming those needs into a set of requirements for a product. For optimal results, the set of product requirements must be verified that they have the characteristics of well-formed requirements (e.g. needed, unambiguous, complete, consistent, correct, feasible, verifiable) and validated that they represent the intent of the needs from which they were transformed.

Best practices for requirements analysis

Stakeholders can communicate their expectations in several forms – needs and requirements. The stakeholder needs represent what the stakeholders need the product to do to address the problem or opportunity the product is to address; stakeholder requirements are stakeholder-own product requirements that communicate what the stakeholders require of the product to meet their needs. Stakeholder needs are expressed in natural language without the use of “shall”, while stakeholder requirements are communicated with “shall” to make sure they are treated as binding requirements the product will be verified to meet.

It is important to define and understand the stakeholder needs and requirements before defining the product requirements to which the product will be designed and built to. Given there are multiple stakeholders, there will be multiple sets of stakeholder needs and requirements. It is up to the project team to elicit these needs and requirements, resolve conflicts, inconsistencies, and other issues. The results will be an integrated set of needs from which the product requirements will be transformed. The resulting product requirements represents what the product must do in order for the needs to be met. If needs describe the “what,” product requirements define the “how.”

Requirements traceability is of the utmost importance to the requirements analysis process. It is used to ensure that each requirement clearly communicates the intent of their source. Without traceability, it’s nearly impossible to know if the software product meets stakeholder needs, drivers and constraints, goals, and objectives. Requirements analysis could be executed perfectly, but without requirements traceability to their source, there would be no way to prove you have the right set of requirements.

Therefore, a best practice of requirements analysis is to ensure that each requirement is traceable to all corresponding artifacts. These artifacts include not only their source but also downstream artifacts including the design, product verification planning and product validation planning.

Another equally important best practice for requirements analysis is to execute a predetermined process. Carefully performing each step can be the difference between a software product’s success or failure to meet stakeholder needs.

The requirements analysis process

Generally, there are seven steps in the requirements analysis process.

Identify stakeholders: the first step is to pinpoint exactly who the key stakeholders are for the project. This includes internal and external customers, users, regulatory agencies, and stakeholder involved in the development of the product. It is the stakeholders that are the source of needs and requirements.
Elicit stakeholder needs and requirements: during this step of the requirements analysis process — also called needs and requirements gathering — teams work with the stakeholders to identify their needs and requirements.
Model needs and requirements: with the initial sets of stakeholder needs and requirements, teams can create visual representations or diagrams of the needs and requirements as part of their analysis to inform the definition of the product requirements, use cases, and user stories. These visual representations and diagrams are used to solicit feedback from stakeholders, iterate, resolve issues, conflicts, and inconsistencies before defining and baselining the product requirements.
Retrospective: the project team reviews the data and information gathered during elicitation, diagraming and modeling. Of particular interest is understanding the drivers and constraints to better understand feasibility and risks associated with developing the product, assess whether anything has been missed and establish a budget and schedule.
Define an integrated set of needs: The project team derives an integrated set of needs that represent the stakeholder expectations along with goals, objectives, and drivers and constraints, and stakeholder requirements.
Define product requirements: at this point, teams review the resulting integrated set of needs and stakeholder requirements and transforms them into a set of requirements for the product to which the product will be designed and built. It is important that the resulting requirements are high-quality requirements having the characteristics of well-formed requirements. It’s wise to make sure that all team members know how to write good requirements.
Sign off and baseline: the final step of the requirements analysis process is to get sign off agreement from all key stakeholders (or representatives from stakeholder groups) identified in step one for the integrated set of needs and resulting set of product requirements. This is a formal contract that lets everyone know what the product will be verified and validated against, the cost, and schedule. It helps eliminate surprises and scope creep later in the development process.

Common challenges during requirements analysis

These steps above will likely need repeating, as the most common challenge of requirements analysis is that requirements may change throughout the software development process. As the team implements various features, the above steps should be repeated for each feature; doing so will often result in additional needs and requirements. The risk of change can be reduced by following the above steps and getting sign off at the beginning of the project for not only the integrated product but for each feature to be provided by the software application.

One reason for change is a failure to include all relevant stakeholders. If the focus is just on the customers or users, needs and requirements associated with other stakeholders will be missed. Given the number of different stakeholders, there will be inconsistencies, conflicts, and issues. Failure to deal with these early, will result in change. The use of various visualizations, diagrams, and models before defining the integrated set of needs and product requirements helps ensure completeness, correctness, and consistency. Again, failing to do this before defining the set of product requirements will result in change and resulting costly and time-consuming rework.

In other situations, it may be that some stakeholders won’t know exactly what they need until they see the software in action, or project constraints may necessitate changes in the solution. In any case, agile teams are constantly iterating and updating design. This means the process of evaluating needs and requirements almost never ends. The diagraming and modeling step above is a great tool that can be used to interact with the stakeholders to better understand their needs. The goal is to be as comprehensive as possible the first time through to get a big-picture view to minimize change and resulting rework.

The pros and cons of various diagraming and modeling techniques

A variety of techniques are available during elicitation, diagraming, and modeling—some are more advantageous than others. Here we review some popular techniques and point out advantages and disadvantages of each.

Flowcharts

Flowcharts show the sequential flow and control logic of a set of related activities, and can be used to represent data flows, system (software application) interactions, both internally and externally, and more.

PRO

Multiple formats: linear, cross-functional, top-down.
Easy to create and understand for all team members.
Highlights critical process attributes.

CON

Change management is time consuming, as flowcharts need to be redrawn to accommodate process alterations.
Complex processes result in dense flowcharts that can be difficult to understand.

Data flow diagrams

These show the flow of information through a system. Data flow diagram components include the process, flow, store, and terminator.

PRO

Can be created in the requirement elicitation step of the analysis process to define a project’s scope.
They can be understood by technical and nontechnical audiences.

CON

It can be time consuming to create, particularly for complex software applications.
Physical considerations are not included in a data flow diagram.

Role activity diagrams

Role-activity diagrams show business and software processes as a progression of actions conducted by role. Roles are identified by activities and grouped into responsibilities. They can be used for describing use cases, workflows, business processes, or software protocol.

PRO

Illustrate the individual steps in activities, as well as the order in which they are to be performed.
Supports communication across roles.

CON

Each workflow requires a new diagram else they become too unwieldy. This makes it difficult to get a full view of the system.
These diagrams do not provide detail about how objects behave or collaborate.

RELATED POST: Nonfunctional Requirements vs. Functional Requirements – What’s the difference?

Unified Modeling Language (UML)

Unified Modeling Language creates diagrams used for modeling specification, development, visualization, and documenting in the requirements analysis process. UML diagrams can be two types of models: a behavioral model, which informs on what the software application will do, and a structural model, which provides insight on the parts that make up the system.

PRO

There are a variety of UML diagrams to choose from, like use case, sequence, interaction, class, and more.
Can be directly inputted to a requirements tool.

CON

UML diagrams must be synchronized with software code, which requires additional work and ongoing maintenance.
Complex processes result in overcomplicated and confusing diagrams.

Business process modeling and notation (BPMN)

BPMN is based on a flowchart technique like activity diagrams from Unified Modeling Language (UML). It uses a unique standard of notation to create graphs including flow objects, connecting objects, swim lanes, and artifacts. These help simplify understanding of the business process answering questions regarding who performs the activities and the data elements required to do so.

PRO

Designed to be understood by all business stakeholders yet represent complex process semantics.
Supported by most modeling tools.

CON

Only supports concepts of modeling applicable to business processes; non-process purposes are out of scope.

Gantt Charts

In requirements analysis, Gantt charts help with coordinating, planning, and tracking project tasks. Tasks to be performed are listed along the vertical axis. The horizontal axis lists the time allotted for the given task and the person or team performing the functions. Gantt charts give a visual representation of the project’s schedule and resources needed.

PRO

A single chart can track many activities, even those happening in parallel.
It provides a realistic view of how long the project will take and what resources are needed at various points in development.

CON

A single view of all the tasks is not available.
The time allotted for a task is not representative of the amount of work involved in its completion.
Complex software projects would require an exorbitant number of tasks making the Gantt chart extremely difficult to create and nearly impossible to update consistently.

Integrated definition for function modeling (IDEF) diagrams

IDEF is a family of modeling languages that cover a wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design, and knowledge acquisition.[i] The goal is to gain an understanding of an organization’s systems by exploring process function relationships to child/parent systems.

PRO

IDEF can be used in almost any context, industry, and technology area.
Diagrams are easy to digest for both technical and nontechnical team members.

CON

It can be difficult to integrate different IDEF techniques.
Designed as a business analysis tool, it is not a very good software application development methodology.

Gap analysis

Also known as need analysis, need assessment, or need-gap analysis, this technique helps analyze software application performance gaps to verify if business requirements are successfully met. Gap analysis conveys the difference between the current state and the target state, identifying where the project stands and what is yet to be done.

PRO

Gap analysis ensure the business requirements or data requirements have been met as desired.
It helps uncover which areas need focus or additional resources.

CON

Success depends on the skills of those performing the analysis, and while gaps may be uncovered, their true causes may be left unsolved.

Focus of the various diagraming and modeling techniques

Some requirements diagraming and modeling techniques are better for analyzing business needs and requirements while others are better suited for discovering user needs and requirements.

BPMN is strictly a technique for uncovering business needs and requirements which must be addressed within the set of product requirements, with excellent results. Gap analysis is also great method for understanding business requirements. As noted, it can help determine the difference between where a business is and where it wants to be. The result may initiate a series of user requirements to help the business close that gap.

While not covered above, a customer journey map is also beneficial for discovering business requirements. A customer journey map is a “voice-of-the-customer” VOC story that shows the customer’s relationship with the business over time. It helps identify sources of frustration on the part of the customer, which can inform user requirements to improve those pain points. Note: limiting this analysis to just a single class of stakeholders can result in missing needs and requirements. A more inclusive approach is “voice-of-the-stakeholders” VOX that shows relationship of all relevant stakeholders with the business over time. It helps identify sources of frustration on the part of all stakeholders, not just the customer, which can inform the definition product requirements to improve those pain points.

The discovery of user needs and requirements benefit from techniques like the data flow diagram. As mentioned, they can be created early and give a high-level of the data flow within a particular process. Use cases and user stories are also great tools for soliciting software requirements from a user perspective, as they maintain focus on what the user needs, not what the product does to meet those needs and wants.

Streamlining the requirements analysis process

The result of the requirements analysis phase of requirements definition and management, is the diagrams and models used as part of the analysis, an integrated set of needs, and a set of product requirements that are inputs to the design process. The set of product requirements define the features and intended behavior of the software application being created such that when implemented within the design, the stakeholder needs are met. Having a baselined set of product requirements serves to crystalize project specifics and mitigate wasted time and potential rework.

While some organizations will communicate this set of product requirements in a document form (e.g., a Software Requirements Specification (SRS)), the increasing trend is to manage the requirements within a requirements management software application.

With Live Traceability™ and digital thread, Jama Connect helps teams collaborate in real time. This mitigates the risks of using documents for requirements analysis. It also enables traceability automatically so the hard work performed can be proven—even with the most complex, highly regulated software products.

See How Jama Connect streamlines requirements analysis and requirements management.

[i] https://www.idef.com/

Behind every successful product and product launch lies a complicated process that can involve multiple oversight agencies, cross-functional teams, and stakeholders. Within an organization’s governance, risk management, and compliance (GRC) framework, product teams must pursue market innovation while remaining in compliance. Staying in compliance with the vast array of rules, procedures, and contract clauses that govern product development can be a full-time job, and lack of management can lead to delays and failures that result in lost revenue, damaged reputation, or even legal action.

With so much on the line, every development project should have a process within the GRC framework to monitor compliance risk and compliance activities along the way. Unfortunately, compliance management can be difficult to integrate into the full design process, and compliance delays can hold up a product launch. Product teams often need a better way to integrate compliance management into the development process. Those teams that include compliance management in their processes can reduce the risk of failure—and potentially improve their speed to market.

What is compliance management, and how does it help product teams ship on time?

Compliance can refer to a variety of different laws, guidelines, standards, processes, procedures, or other controlling documents, including contracts. Compliance management refers to the intentional process by which designated team members or compliance officers monitor and control design, development, launch, and fulfillment to ensure that all legal, contractual, and procedural requirements are met.

Ideally, compliance management involves both people and a system that is fully integrated across functions of the organization. The more integrated the compliance management in the development lifecycle, the more likely it is to detect potential compliance issues before they cause long-term harm to companies or consumers.

A fully integrated compliance management system can help your product team ship on time or early by keeping all compliance factors top of mind during the design, development, and fulfillment process. When teams are ensuring compliance throughout the entire development lifecycle, unforeseen delays and consumer issues are less likely to derail product success.

To fully integrate compliance management, teams need a development process that includes touchpoints for assessing compliance. The process should include activities such as:

Standard operating procedures
Safety and security procedures
Reporting and documentation
Internal and external audits

Integrating all of these activities will help ensure that teams are fully prepared to establish compliance with applicable standards, regulations, and laws before launch, reducing the possibility of costly delays or failures.

RELATED: A Guide to Understanding ISO Standards

What is compliance control?

Compliance control is a set of guidelines and policies designed to provide a framework for compliance to product teams and stakeholders. These guidelines and policies apply to everyone involved in compliance management—from board of directors to compliance officers or compliance managers to team members.

Common internal compliance controls can include the following:

Published standards, policies, and operating procedures
Training and documented completion of training
Internal audits
Contracts

External compliance controls are those that originate anywhere outside the company:

Laws and regulations
Industry standards
External audits
External risk assessments

What is a compliance management system?

A compliance management system is a program that integrates written documents, processes, functions, controls, tools, and anything else that helps organizations comply with regulations and reduce risks to consumers that arise due to violation of applicable law. While a comprehensive compliance management system will include appropriate tools such as software, it will also clearly define the roles of various stakeholders, including:

Team members
Compliance officers or compliance managers
Board of directors
Internal auditors

The compliance management system will also define processes for:

Assessing and responding to consumer complaints
Addressing results of a compliance audit
Providing relevant compliance training as appropriate
Keeping informed of regulatory change
Taking corrective action when products are found in violation

Why is maintaining compliance so important for product teams working in regulated industries?

Former US Deputy Attorney General Paul McNulty has stated, “If you think compliance is expensive, try non-compliance.” In any industry, non-compliance can lead to fines, product failures, and lawsuits—not to mention the cost of lost reputation, customers, and business.

For teams working in regulated industries, maintaining compliance is especially important as there are often unique safety and regulatory issues at hand. In industries such as automotive, aerospace, and medical devices, one product that fails to meet regulatory or legal standards could potentially lead to the kind of product failure that results in loss of property or human life.

Studies by the Ponemon Institute reveal that non-compliance can cost as much as 2.65 times what compliance costs. What’s more, the institute found that non-compliance costs increased by 45% between 2011 and 2017.

What are best practices for compliance management?

While the specific practices for compliance management will vary according to industry, there are some best practices for compliance management that any product team can use to ensure a successful product launch.

Identify compliance officers: If your company doesn’t have a dedicated compliance officer, identify someone on your team who can at least serve as an ad hoc compliance officer. Identifying the right person (or people) early in the development process will give a central point of contact so that no one is wondering who is in charge of compliance.
Learn relevant requirements: All members of the team should at least have a familiarity with the regulatory and legal environment around product development. In addition, everyone should subscribe to government and industry mailing lists or websites to stay up-to-date on changes to regulations. One study found that regulatory monitoring saved companies an average of $1.03 million.
Create a central repository of requirements: Rather than simply documenting requirements that are relevant only to one team or project, companies should create a central source of information for all compliance requirements, including internal procedures and standards. With one central source for all teams to access and contribute to, teams are less likely to miss requirements in the development process.
Establish traceability between requirements and standards, regulations, and other relevant compliance documents: By documenting traceability between the compliance requirements and project artifacts, product teams create a robust analysis tool that can provide invaluable detail and information for audits and reviews.
Implement tools that support compliance management: While there’s no substitute for having human input and control over compliance management, there’s no question that having the right tools can make compliance a more manageable task. The right tool will support product teams by providing a central source for traceability, requirements management, analysis, documentation, and all related activities.

What makes a compliance program effective?

A comprehensive and effective compliance program will:

Reduce costs: When teams have a program in place for comprehensive compliance management, it’s almost inevitable that the team or company will save money overall.
Improve risk management: Evaluating and assessing risks throughout the lifecycle will improve risk management across the development lifecycle. Good compliance management will help teams identify and assess risks early in the development process.
Keep product development well within organizational GRC framework: An effective compliance program will keep development in compliance with internal controls and the overall organizational GRC framework.
Improve speed to market: When compliance is fully integrated into product design and development, the risk of delays drops, and chances of shipping on time or early increase.

What tools and software can help product teams maintain compliance during the application lifecycle?

A compliance management solution is an important piece of any compliance management system. Within the overall framework of a compliance management system, a compliance management solution will support workflows, self-assessments, surveys, and issue remediation. In addition, intuitive dashboards and charts can provide real-time insights into compliance processes.

How can Jama help teams working in highly regulated industries, like medical and aerospace, maintain compliance during the application lifecycle?

Jama Connect gives product teams the tools they need to integrate compliance management into the design lifecycle. By tracking requirements and giving teams the traceability they need, Jama Connect simplifies compliance management by integrating it fully into the application lifecycle. To learn more about Jama Connect, contact us for a demo.

If you’ve worked in product development for any time at all, you’ve probably heard the term “ISO” used in conjunction with the terms “standards” and “compliance” (along with a variety of four- and five-digit numbers).

But what does that all mean, and how does it affect you? In this article, we will provide you with a basic guide to understanding ISO standards.

What is ISO and What are ISO Standards?

The International Organization for Standardization is a nongovernmental organization. It consists of a network of standards bodies from 165 member countries (currently), with one body representing each member country. The American National Standards Institute (ANSI), for example, represents the United States. The organization maintains a central office in Geneva, Switzerland, to oversee this network.

Because “International Organization for Standardization” is a mouthful and would have different acronyms in different languages, the organization’s founders chose ISO—derived from the Greek ‘isos’, meaning equal—as its official abbreviation. As the group’s website proclaims: “Whatever the country, whatever the language, we are always ISO.”

ISO’s purpose is to help unify standards on an international basis. ISO standards are designated by the term ISO followed by a number, like ISO 9001. In some cases, ISO standards share a numeric code with an industry association, as in the case of ISO/IEC 12207. IEC stands for the International Electrotechnical Commission, which prepares and publishes international standards for electrical, electronic, and related technologies.

Nearly 800 ISO technical committees and subcommittees are tasked with standards development. As of June 2021, ISO has published some 23,886 international standards covering almost all aspects of technology and manufacturing.

What Are the Benefits of ISO Standards?

ISO forms a bridge that links the public and private sectors. Many of its member institutes are either departments of their national governments or mandated by them. Other member organizations are rooted solely in the private sector, having been set up by industry association partnerships within their country. ISO helps these diverse bodies reach consensus on solutions that meet both the requirements of business and the broader needs of society.

ISO standards help make the world a safer place and give consumers confidence that the products they buy are safe, reliable, and of high quality. Regulators and governments count on ISO standards to help develop better regulation, knowing they have a sound basis thanks to the involvement of globally recognized experts.

Finally, compliance with ISO standards gives companies an advantage in the marketplace. ISO certification provides assurance to potential customers that the company adheres to industry best practices. In many industries, companies require that their suppliers are certified to certain relevant ISO standards.

How Does ISO Design New Standards?

The ISO process for creating a new standard begins when an alliance of industry associations or consumer groups submits a request. ISO then recruits subject matter experts and industry stakeholders to form a technical committee or subcommittee. This committee executes a two-round drafting process and then takes a formal vote on the second draft. This second draft is called the Final Draft International Standard (FDIS). If the FDIS is approved, it is certified by the central secretariat, and ISO publishes it as an official international standard.

As technologies and best practices evolve, industry associations may request an update of an ISO standard. Different versions of the standard are distinguished by the year the revision was published appended to the standard designation. For example, the latest version of ISO 9001 is ISO 9001:2015.

What ISO Standards Are Related to Product Development?

ISO 9001

The ISO 9000 family of quality management standards is easily the most popular set of industry standards in the world. Of these, ISO 9001 is the only one to which companies can be certified.

ISO 9001 describes how to put a Quality Management System (QMS) in place to better prepare your organization to produce quality products and services. Today, over one million companies in more than 170 countries are certified to ISO 9001:2015.

ISO/IEC 12207

ISO/IEC 12207, Systems and software engineering – Software lifecycle processes aims to define all the processes required for developing and maintaining software systems, including the outcomes and/or activities of each process.

First introduced in 1995, ISO/IEC 12207 establishes a common framework for software life cycle processes with well-defined terminology that can be referenced by the software industry. It defines the processes, activities, and tasks to be applied during the acquisition of software products or services, as well as during the supply, development, operation, maintenance, and disposal of software products and to the software portion of firmware, as well.

ISO/IEC 12207 also provides a process that can be employed for defining, controlling, and improving software life cycle processes.

ISO 8887

ISO 8887 specifies the requirements for the preparation, content, and structure of technical product documentation (TPD) of the design output for the cycles of manufacturing, assembling, disassembling, and end-of-life processing of products. It describes the TPD needed at the critical stages of the design process.

Beyond those requirements, the standard also identifies and describes methods and conventions appropriate to the preparation of documentation necessary to realize a design, including the application to multiple life cycles. ISO 8887 also incorporates guidance on the ultimate reusing, recovering, recycling, and disposing of the components and materials used.

ISO/TS 16949

Based on ISO 9001, ISO/TS 16949 is a technical specification (TS) aimed at the development of a quality management system that provides for continual improvement within the automotive industry. First published in 1999, it emphasizes defect prevention and the reduction of variation and waste in the automotive industry supply chain and the assembly process.

According to the British Standards Institution (BSI), the ISO/TS 16949 standard was created by the International Automotive Task Force (IATF) to help streamline this process. It focuses on the avoidance of errors and defines the requirements for the development, production, and installation of automotive-related products. Today, certification is required by almost all Tier 1 companies, many of whom require their Tier 2 and Tier 3 suppliers to certify. As a result, over 50,000 certifications have been issued to date against this standard.

ISO 26262

ISO 26262, Road vehicles – Functional safety applies to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars. Introduced in 2011, this standard addresses possible hazards caused by malfunctioning behavior of E/E safety-related systems, including the interaction of these systems.

With the increased number and interaction of electronic systems within passenger vehicles, this standard is being adopted rapidly within the automotive industry.

ISO 13485

Unlike many ISO standards, ISO 13485, Medical Device Quality Standards, is a single document and does not belong to a family. It was originally published in 2003 and revised in 2016.

ISO 13485 puts a quality management system in place for the production of medical devices and equipment and is very specific to the health industry. It is often implemented with ISO 9001 to show that an organization is qualified to do business in the medical device field.

ISO 13485 is a regulated standard against which over 25,000 certifications have already been issued.

How ISO Affects the Product Development Process

Product developers sometimes ask, “What are the differences between standards and requirements?”

According to Merriam-Webster, a requirement is “something wanted or needed; a necessity” or “something essential to the existence or occurrence of something else.” Other definitions include “a necessity or prerequisite” and “something required or obligatory.”

Webster’s defines a standard as “something set up and established by authority as a rule for the measure of quantity, weight, extent, value, or quality” or “something established by authority, custom, or general consent as a model or example.” In other words, a standard is a principle, example, or measure used for comparison—a benchmark used to evaluate suitability for a purpose.

To meet a requirement, a thing, person or organization must do exactly what the requirement says. To meet a standard, a thing, person or organization must meet the minimum requirements of the standard and align with its intent. Standards typically allow some leeway for tailoring to individual organizational practices and obligations.

As mentioned earlier, many corporate and governmental customers want their suppliers to adhere to certain ISO standards, especially in industries that are multi-tiered or highly regulated. Certification to applicable standards is often a contractual requirement within those industries.

Is ISO Compliance Required by Law?

The ISO standards themselves are not legally binding. There are no laws that compel companies to meet or be certified to any ISO standards.

However, national regulators may refer to ISO standards as examples of good practice. For example, a building regulation might say you must comply with certain local regulations and that one way of complying with those is to comply with a given ISO standard.

Also, while not legally bound, many companies find certification to certain ISO standards is a necessity if they wish to compete for contracts within their industry or with specific customers.

Want the inside scoop? See what users are saying about Jama Connect

What is ISO Certification?

In this guide, we’ve talked frequently about ISO compliance and ISO certification. So, what’s the difference?

Compliance simply means that your product or process conforms to the requirements of the ISO standard. ISO certification, on the other hand, is the result of a formal procedure and thus a bit more complicated.

ISO itself does certify companies directly. Instead, specific certification bodies perform the task of auditing and then certifying an organization’s compliance with a given ISO standard. These bodies, often known as registrars, must themselves be certified under a separate standard, ISO/IEC TS 17021.

During the certification process, the registrar audits the organization to ensure that its operations are in compliance with processes outlined in the current ISO standard. Where inconsistencies or “non-conformities” are found, the organization must typically create a program for correcting these problems before the registrar will issue a certificate.

Once an organization is granted certification, it receives a certification mark that can be used on its company stationery, websites, etc.

When it comes to ISO standards governing ongoing business practices, like ISO 9001 for example, approval is typically valid for a period of three years. After that, the company must recertify to the current form of the standard.

Applying ISO Standards in Lifecycle and Requirements Management

What tools can help meet ISO standards in the realm of product lifecycle management? Jama Software provides several.

First and foremost of these is our flagship product, Jama Connect. For example, let’s say your organization is seeking certification to ISO 9001. To achieve that certification, you need to demonstrate you have put in place a defined, repeatable process for assuring quality. Jama Connect is a tool built specifically for requirements management and requirements traceability. Not only does Jama Connect simplify the tracking and tracing of requirements, it also makes it simpler and easier to maintain and demonstrate a robust quality process. That’s because Jama Connect automates so much of your requirements management process.

We’ve also built guides that will help you build compliance with specific ISO standards. If you work in the automotive sector, you may want to check out our guide for ISO 26262 compliance. Likewise, if you work in the medical device field, be sure to get a copy of our Guide to ISO 13485 for Medical Device Development.

Finally, to learn more about choosing the right requirements management tools to help your company attain or maintain ISO certification, download our Requirements Management Buyer’s Guide.

Requirements gathering is the process of understanding what you are trying to build and why you are building it. Requirements gathering is often regarded as a part of developing software applications or of cyber-physical systems like aircraft, spacecraft, and automobiles (where specifications cover both software and hardware). It can, however, be applied to any product or project, from designing a new sailboat to building a patio deck to remodeling a bathroom.

Three Main Subprocesses of Requirements Gathering

The key ingredients of the requirements gathering process are three overlapping subprocesses: requirements elicitation, requirements documentation, and requirements understanding.

Requirements elicitation is the process of asking for and collecting top-level requirements from all relevant stakeholders. Effort should be made to account for the needs of customers, their users, the internal stakeholders within your own company, and your key suppliers.

Requirements documentation organizes the input from the requirements elicitation process into whatever format is appropriate for your organization. This formatting may include:

User stories
Functional decompositions (especially for complex cyber-physical systems)
Feature descriptions

These will be collected in a top-level requirements specification like a product requirements document (PRD) or a system specification. The purpose of this top-level specification is to make those stories and descriptions available to all members of the project team.

Requirements confirmation is the process of making sure all stakeholders and team members have a common understanding of what you’re trying to build. This involves reviewing and refining the requirements. It will very likely require additional elicitation and revision of the documentation as well.

What are the Benefits of Requirements Gathering?

Beyond the obvious advantage of having requirements with which to work, a good requirements gathering process offers the following benefits:

Greatly improves the chances that customers and users will get what they wanted. Stakeholders often have difficulty putting into words exactly what it is that they need. You’re going to have to help them, and it’s going to take some digging.
Decreases the chances of a failed project. A frequently heard lament following unsuccessful projects is, “The requirements weren’t clear.”
Reduces the overall cost of the project by catching requirements problems before development begins. Requirements that are ambiguous or not fully understood often result in costly scrap and rework. Numerous studies have shown that the cost of fixing requirements errors rises exponentially over subsequent phases of development.

Some Key Challenges of Requirements Gathering

One of the reasons projects fail due to poor requirements is this: requirements gathering isn’t easy. Here are some of the main challenges:

Finding All the Right Stakeholders

Projects often have “hidden” stakeholders. It’s important to uncover them. The group you canvas should include more than just the obvious decision-makers. Don’t forget to talk to customer support reps, maintenance technicians, and others who come into direct contact with customers. They are themselves, in effect, users of your existing products.

“Disgruntled users who are forced to use a system every day that was designed without their input are a key ingredient for a failed project,” says Jordan Hirsch, Director of Innovation at Phase2 Technology.

Understanding What Stakeholders Really Want

Your stakeholders may not have a clear vision of what they want. They may not be able to tell you a complete story. They may have hidden pain points or desires, unstated goals, or assumptions. You’re going to have to ask a lot of probing questions and compare answers. You’re also going to have to go through several iterations of your process to arrive at a consensus.

Planning for Change

Throughout the requirements gathering process, you’re going to come across questions you forgot to ask and things stakeholders forgot to tell you. You’ll come up against shifting priorities and problems encountered during implementation.

It’s wise to have a plan for dealing with those changes. You’ll need to allow time for addressing problems, documenting new requirements, and conducting additional reviews.

RELATED POST: Nonfunctional Requirements vs. Functional Requirements – What’s the difference?

A 6-Step Requirements Gathering Process

The requirements gathering process consists of six steps. Three of those (steps three through five—the bulk of the process) we’ve already mentioned as the key subprocesses of requirements gathering. The full six steps are:

Identify the relevant stakeholders
Establish project goals and objectives
Elicit requirements from stakeholders
Document the requirements
Confirm the requirements
Prioritize the requirements

It is important to note that while these steps are typically initiated in the order listed, there is a great deal of overlap and iteration among them. It may, therefore, be better to think of them as subprocesses rather than steps as we look at each one individually.

Identify the Relevant Stakeholders

Find qualified representatives from each relevant stakeholder group. Depending on your project, these may include:

Customers stakeholders
Decision-makers
Users
System administrators
Other impacted customer departments
Internal stakeholders
Executives
Engineering
Marketing
Sales
Customer support (including on-site maintenance teams, if applicable)
Key suppliers
Distributers and other partners

Remember to search for “hidden stakeholders.” Ask probing questions in early meetings, before you begin eliciting requirements. Identify all stakeholder groups who need to be involved. Ideally, you want input from every group who has skin in the game; give them all the opportunity to state their needs.

Establish Project Goals and Objectives

What are you trying to achieve with this new product or project? What are the overall outcomes your customers want from the product? What are your company’s business goals? What are the actionable, measurable objectives you need to achieve to realize those goals and outcomes?

Write them down. State them clearly, and get all your stakeholders to sign off on them. Your goals and objectives will act as a framework for your decision-making.

Each requirement you write should help satisfy a project objective and accomplish a goal. If it doesn’t, you should either discard it or made it a candidate for a future release.

Elicit Requirements From Your Stakeholders

This is the first of three requirements gathering subprocesses which are highly iterative and overlapping. Even in an agile environment, you are likely to go through several cycles of elicitation, documentation, and review/confirmation before you achieve a workable specification to begin development.

Elicitation can be performed in several ways. Time-tested techniques include surveys, questionnaires, and interviews. Interviews and follow-up meetings will be prevalent during later iterations.

Be sure to listen actively during interviews. Ask probing questions and take copious notes. Afterward, organize your notes and follow up as necessary. Document each exercise or encounter thoroughly.

Document the Requirements

As soon as requirements begin to emerge from your elicitation process, begin documenting them.

Write them down and collect them in whatever format your organization has agreed upon. That could be a product requirements document (PRD) of your company’s design, a government-mandated system requirements specification, a vendor-supplied requirements management (RM) tool like Jama Connect, a spreadsheet, a database, or any other appropriate repository your entire team can access.

What’s most important is that the requirements documentation…

Can be easily navigated and understood by your team
Is available for review by all stakeholders
Provides a facility for traceability to other documentation.

Templates are extremely useful, both for the specification as a whole and for individual requirements. Solid, battle-tested templates and standardized formats help provide clarity and aid navigation.

Confirm the Requirements

Review the requirements with all stakeholders. Make sure the requirements clearly capture what was intended and that all parties have a common understanding of each of them. If you find any ambiguity in a requirement, revise it.

You should also validate your requirements through prototyping and testing, where possible. Modern prototyping tools make it fast and easy to create a working model of your specification. You can then use that model to perform feasibility, usability, and product concept testing.

Get stakeholder sign-off on individual requirements as you get them nailed down. Do the same for the specification as a whole during a final review.

Prioritize the Requirements

Most engineering development programs run into unexpected challenges along the way. Unanticipated obstacles are encountered. Schedules slip. Priorities change. It’s important to be able to adapt to those challenges and changes.

That’s why it is crucial to prioritize your requirements based on how each will impact your goals and objectives for your release.

Many product managers prioritize features by tagging them with labels, such as “must have,” “high want,” and “nice to have.” But it’s also important to rank order each requirement within those categories. There are two reasons for this.

The first is time to market. Schedules often slip. When they do, you may need to trim features and requirements to meet your release date. You don’t want your team implementing the easiest requirements first only to find that there’s not enough time to complete all your must-haves.

The second reason is that requirements evolve. During implementation, you’re likely to discover new needs. Some may be critically important and supersede existing requirements in terms of priority. You need to know where those new requirements fit in your pecking order. If you don’t, less important factors will determine what gets implemented first, which may have an adverse impact on your product’s success.

Common Requirements Gathering Pitfalls

Making Assumptions About What You’ve Heard

Beware of simple, broad requirements. Don’t assume you know exactly what they mean. Above all, don’t assume all your stakeholders interpret those requirements in the same way.

Broad statements like, “The site shall have a blog” can mask a host of underlying assumptions. Scrutinize such requirements. Ask lots of questions. How will posts be displayed? How should authors be managed? How about comments, categories, tagging? Should there be an RSS feed?… and so forth.

Cross-check the answers you receive. Then come up with a set of more specific, verifiable requirements that everyone can agree upon.

Focusing on HOW Instead of WHAT

Requirements address two things. The first is WHAT the product must do (the functional requirements). The second is the necessary constraints on how the product does what it does (the non-functional requirements).

Requirements should not address HOW the product does what it has to do. In other words, your specification should be as implementation-agnostic as possible, within the constraints of the non-functional requirements.

During requirements elicitation, try not to think about how you’re going to implement the product. Forget about the latest technology engineering is obsessed with, your software team’s tool du jour, and any features you think are missing from the product baseline. Focus instead on your stakeholders’ needs.

Listen to what your stakeholders are saying first. Then gather, review and refine your requirements. Finally, once you’ve done all that, find the gaps in your baseline, and determine which technologies will deliver what your customers and stakeholders really want.

Insufficient Consultation With Stakeholders

Perhaps the biggest mistake systems engineers and product managers make in gathering requirements is failing to adequately consult with their stakeholders. Stakeholder consultation has several facets.

First, it is critically important that you drill down (and follow up) with each stakeholder group to fully understand their needs. Failure to do so is one of the leading causes of requirements failures.

A second important facet is transparency. Clean up your notes and share them after every interview, meeting, and survey. The easiest way to do this is through a modern RM tool to which all team members have access. Tools like Jama Connect allow you to attach notes to the requirements themselves for traceability purposes. This greatly increases the speed of the process and simplifies the review task.

The third potential pitfall in this area is insufficient review. Be sure to hold reviews where stakeholders can review the requirements, provide feedback, voice objections, and defend their positions. Open discussions involving all concerned stakeholders can help uncover and correct requirements flaws and achieve consensus.

Finally, get all your stakeholders to sign off on the requirements to acknowledge that they understand them and that the requirements are sufficient for them to do their jobs. Be sure to make it clear to the stakeholder what his or her signature means.

Requirements Gathering for Agile Development

What’s different about requirements gathering for Agile?

First off, agile teams expect to move fast. So, their requirements management solutions must meet their developers’ need for speed.

Transparency is another priority. Requirements documentation must be constantly up-to-date, easily annotated, and provide clear traceability.

Both of these needs make Word documents and Excel spreadsheets poor RM choices for agile teams. Their static nature makes them tedious to update and cumbersome to share. Those drawbacks make it difficult to give everyone fast access to the latest configuration and keep them all on the same page. Plus, docs and spreadsheets don’t provide native features for annotation and traceability.

RM products like Jama Connect help Agile teams streamline requirements gathering and collaboratively manage requirements in real-time throughout the ALM product development process.

Are you working in an Agile development environment? See how Jama Connect can streamline requirements gathering and management by downloading our datasheet.

If you’ve ever started a new project only for it to transform into a huge challenge later in the process, you know that upfront, clearly defined requirements are critical to success. Defining requirements upfront allows you to effectively manage client expectations and create an implementation process that is smooth and seamless.

A project that lacks this upfront clarity, however, can lead to a vaguely defined project scope and results that miss the mark. A study by the Carnegie Mellon Software Engineering Institute found that 60 percent to 80 percent of the cost of software development is in the rework. Furthermore, successful requirements management can eliminate 50 percent to 80 percent of project defects.

So, how can you ensure that your requirements are more accurately and clearly defined? It starts with understanding the key differences between functional and non-functional requirements and understanding the role that each plays in the success of your project.

Functional vs. nonfunctional requirements: What’s the difference?

Functional requirements focus on what the project should do, and non-functional requirements focus on how it should be. Let’s break it down a little further.

What are different uses cases of functional requirements and non-functional requirements?

What is a functional requirement?

Functional requirements focus on how the software must perform and specify the desired behavior of the system; for example, when specific conditions are met, the system will send a new user an email. Another example is that only employees on the management level can view salary data. More examples of functional requirements include those related to the following:

Audit tracking
Reporting requirements
Authorization levels
Legal or regulatory requirements
Business rules
Administrative functions
Certification requirements
Reporting requirements
External interfaces

What is a non-functional requirement?

Non-functional requirements are critical to the usability of a software system, and if you don’t define them carefully, the end users’ experience can be adversely affected. An example of non-functional requirements is defining how fast a website must load or specifying that a website must handle 10 million users without having any performance challenges. Non-functional requirements can also be related to security; for example, a user must change their initial login password upon logging in the first time. More examples include those related to:

Compliance
Documentation
Privacy
Portability
Quality
Reliability
Resilience
Response time
Scalability
Stability

Non-functional requirements are focused on the system’s operation rather than its behaviors; for example, data must be updated for users during access within three seconds. Non-functional requirements can also be defined by metrics and relate to aspects of the system that evolve over time, such as manageability or documentation.

Attributes of Functions vs Nonfunctional Requirements

When comparing functional vs. non functional requirements, consider that a functional requirement might ensure the system loads a specific web page when the user clicks on a button. The non-functional requirement might dictate how fast the site loads. A website that loads slowly can adversely affect the user experience, which is why non-functional requirements are critical.

What are user stories and how do they help?

When considering requirements and defining those requirements, you’ll find it helpful to consider integrating user stories. A user story is basically the description of a software feature from the user’s perspective. The story defines what you want the system to do and how that affects the overall experience. A basic formula might look like the following:

A <define user type> wants <specify the specific goal> so that <include a specific reason>

Acceptance criteria should also be included with user stories, which are the conditions the product needs to address to be acceptable to the client. Create at least one acceptance criterion for each user story. A few examples may include:

A search field needs to be placed on the top bar of the website
A search is started once the user hits the “submit” button
The display language is English
No more than 150 characters can be typed into the search box

User stories are helpful in the context of non-functional requirements, as they allow you to take a deeper dive into the user experience and see how to make that process smoother.

Why are metrics used more in nonfunctional vs. functional requirements?

Non-functional requirements help companies measure the success of a system, so they must be measurable. The metrics must be qualitative and quantitative. You might require, for example, that a system be able to handle expansion in the future. That’s a qualitative goal, but let’s take it a step further and make it quantitative as well. You might require that the system handle at least 30,000 users within the next three years.

The benefit of focusing on quantitative goals is that the goal is easily measured and you and the client can agree on what success looks like.

What are requirement specifications? What is a requirements specification document?

A software requirements specification document, also known as an SRS document, addresses what the software will do and expectations with regard to its performance. The document also highlights what the product needs in terms of user functionality. Most documents include an overarching purpose and define functional and non-functional requirements. A few sections that you may want to include in your SRS document include:

Include a brief overview of the system, along with any relevant background details and terms that need definition upfront.
Overall description. Include any assumptions made about the project, its business values, and the overarching project vision.
Specific requirements. Define specific attributes to be included in the system, functional requirements, and any relevant database requirements.

If you want to view an example of an SRS document, Michigan State University has one that can give you a starting point for creating your own document.

Tracking Requirements: Why Traditional Documents May Miss the Mark

Traceability is critical to project success. Gartner highlights one of the main reasons why companies struggle to achieve the benefits of traceability:

Software and hardware teams must work together and collaborate throughout the development process to define market requirements, functional vs. non functional requirements, test cases, and other critical pieces of information. This becomes a challenge, however, when teams use different tools and terminology and work with different methodologies.

The answer is to connect data, conversations, and decisions in a single system in the product development process. This gives you the ability to consult and collaborate with people about requirements within the system, capture decisions and actions, and keep that information associated with the requirement. Down the road, if you need to revisit decisions, all data is stored and easy to find.

Moving Forward with Functional vs. Nonfunctional Requirements

Every software project has a vision, a goal, and a destination that you want to reach. Functional and non-functional requirements help you to reach that goal more easily through setting clear boundaries. These requirements help you answer the most critical questions and ensure that products are developed with success in mind.

Functional requirements vs. non functional requirements are critically important, but since non-functional goals are focused heavily on the user experience, these are arguably more critical. Understanding the role of each category empowers you to define and track each with greater success and create a road map that delivers on your client’s expectations.

Learn more about how Jama Connect streamlines tracking and tracing requirements.

SEE THE SOLUTION

Tag Archive for: Strategic SEO Content Project

What are functional requirements in product development?

The difference between functional requirements and non-functional requirements

Functional Requirements

Non-functional Requirements

RELATED POST: Nonfunctional Requirements vs. Functional Requirements – What’s the difference?

Forms and examples of functional requirements

Ubiquitous Requirements

State-driven Requirements

Event-driven Requirements

Optional Feature Requirements

Unwanted Behavior Requirements

Complex Requirements

Tips for writing good functional requirements

1. Be consistent in the use of modal verbs

2. Tag each requirement with a unique identifier

3. Write only one requirement in each requirement statement

4. Write requirements statements as concisely as possible

5. Make sure each requirement is testable.

6. Clearly segregate requirement statements from rationale and other explanations.

RELATED POST: Requirements Management Tools and Software

What is a Functional Requirements Document?

Tips for compiling a good FRD

1. Organize the document in a hierarchical structure

2. Standardize your requirements language

3. Use a good FRD template or a dedicated RM platform

The drawbacks of templates

What is requirements engineering?

RELATED POST: Requirements Management Tools and Software

The 4 steps of the requirements engineering process

RELATED POST: Nonfunctional Requirements vs. Functional Requirements – What’s the difference?

Common mistakes to avoid

Leveraging the right tools for success

What is a need?

What is a requirement?

What is requirements management?

Why is requirements management important?

Stages of the requirements management process

Planning Stage

Needs and Requirements artifacts

Needs and Requirements Baseline

Requirements development stage

Eliciting needs and requirements

Needs and requirements definition

Requirements analysis

System Verification Stage

System Validation Stage

Challenges with requirements management

How to successfully manage requirements in complex products and highly regulated industries

Benefits of requirements management tools

What is requirements analysis?

Best practices for requirements analysis

RELATED POST: Requirements Management Tools and Software

The requirements analysis process

Common challenges during requirements analysis

The pros and cons of various diagraming and modeling techniques

Flowcharts

Data flow diagrams

Role activity diagrams

RELATED POST: Nonfunctional Requirements vs. Functional Requirements – What’s the difference?

Unified Modeling Language (UML)

Business process modeling and notation (BPMN)

Gantt Charts

Integrated definition for function modeling (IDEF) diagrams

Gap analysis

Focus of the various diagraming and modeling techniques

Streamlining the requirements analysis process

What is compliance management, and how does it help product teams ship on time?

RELATED: A Guide to Understanding ISO Standards

What is compliance control?

What is a compliance management system?

RELATED POST: How to Perform Better Impact Analysis on Upstream and Downstream Relationships

Why is maintaining compliance so important for product teams working in regulated industries?

What are best practices for compliance management?

What makes a compliance program effective?

RELATED POST: Checklist: Selecting a Requirements Management Tool

What tools and software can help product teams maintain compliance during the application lifecycle?

What is ISO and What are ISO Standards?

What Are the Benefits of ISO Standards?

RELATED POST: How to Perform Better Impact Analysis on Upstream and Downstream Relationships