Tag Archive for: requirements gathering

Tag Archive for: requirements gathering

Requirements Management Planning: A Guide for Product Teams

What is Requirements Management Planning

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

Requirements Management Plan

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

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

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

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

Components of a requirements management plan

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

Project overview

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

Roles and responsibilities

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

Typical roles include: 

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

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

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

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

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

Tools

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

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

Requirements gathering

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

RELATED POST: 11 Requirements Gathering Techniques for Agile Product Teams

Categorization and assignment

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

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

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

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

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

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

Prioritization

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

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

Traceability

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

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

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

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

Change management

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

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

Configuration management

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

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

Verification

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

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

Benefits of requirements management planning

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

For more in-depth information…

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

requirements-management-hub

A Step-by-Step Guide to the Requirements Gathering Process

In the quest for a successful product development process, there are any number of steps that could go wrong or lead to release delays or cost overruns. Few, however, are as vital to a good outcome as the requirements gathering process.

The requirements gathering process is central to a timely and efficient release of a product that fulfills expected deliverables. Unfortunately, this important step is too often rushed, condensed, or truncated. When all of the relevant stakeholders aren’t consulted for input, the requirements document won’t include everything necessary for a successful product, and the process may be doomed to failure before design even begins.

To help you gather the right requirements from the right people, Jama has assembled this step-by-step guide to the requirements gathering process.

A Step-By-Step Guide to the Requirements Gathering Process

If you’ve waited until project kick-off to start gathering requirements, you may have already waited too long. Requirements gathering should begin as soon as possible—even before the official beginning of the project, if possible.

RELATED POST: What is Requirements Gathering?

And requirements gathering should be an ongoing process. Obviously, there’s a point where the real design work must begin, but you should always have an ear and eye open to catch additional requirements as they arise. The earlier you can catch new or revised requirements, the easier it will be to integrate them and avoid delays or cost overruns.

With that somewhat fluid and holistic perspective in mind, there is still value in defining a more linear process that can give a framework for ongoing requirements gathering. Here is a good starting point for gathering requirements for your next project, broken down into three phases:

Phase One: Requirements Elicitation

The initial phase of requirements gathering is elicitation, which is just a process of collecting all of the top-requirements from all relevant stakeholders through a series of sessions, meetings, surveys, interviews, or other means. The elicitation process can be broken down into four steps:

1: Establish stakeholders. The very first step in requirements gathering is figuring out whose input to include in the process. You can split stakeholders into three basic groups:

    • Internal stakeholders: These are the people inside the company or on the development team who have a direct interest in positive outcomes. Internal stakeholders can include the project sponsor, managers, SMEs, and others.
    • Technical stakeholders: Technical stakeholders are the teams and leaders responsible for developing and implementing the project or product. This group may include developers, testers, solution architects, and other support teams.
    • External stakeholders: This group will have an interest in the outcome of the project, but will not necessarily be directly involved in development. External stakeholders may include compliance and regulatory groups, business analysts, or customers and end users.

2: Define initial scope of the project. Defining project scope is key to avoiding scope creep along the way. While it’s important to recognize that the scope may change after requirements gathering sessions, defining the initial scope can help keep the project from getting out of control early on.

3: Set up requirements gathering sessions. Once you’ve established the various stakeholders, start holding sessions to gather requirements. These meetings could include internal or external stakeholders or even a combination of both. For a successful session, follow these guidelines:

    • Establish a clear agenda ahead of time. Write out the main points to be covered in the meeting, including any specific questions or development items for which you need to write requirements.
    • Take notes. Never assume that someone else is taking notes! Write your notes under each agenda item so that you start grouping requirements. For example, if you know that a particular integration will be necessary, make notes under that heading on your agenda to keep those requirements together. Review your notes immediately after your meetings and send to internal teams to make sure everything is captured in one place. Save your notes to a shared folder for the entire team.
    • Start creating tasks. After notes are completed, use them to start creating tasks and action items and defining deliverables. Set up future meetings as needed to capture additional action items and requirements.

4: Get creative. Initial requirements gathering sessions may be focused more around technical stakeholders or business analysts, but be sure to include time to gather input from creative team members—marketing, design, and others. It’s also good to include sessions with end users, sales team members, and others who can offer input on what features and benefits the final product should include.

For a deep dive into requirements gathering techniques, visit: 11 Requirements Gathering Techniques for Agile Product Teams

Phase Two: Requirements Documentation

In the documentation phase, the development team organizes input in the form of user stories, functional decompositions, feature descriptions, and the like. We break this phase into three steps:

  1. Write the Marketing Requirement Document (MRD). The MRD is the document that expresses a customer’s needs or wants in a final product from the development team. This document will help define customers and their pain points, identify competitors, and establish business needs and desired business outcomes.
  2. Revise scope, if necessary. This isn’t an opportunity to completely redefine the project concept or scope, but rather a modification step that takes into consideration all of the requirements gathering sessions. The point of this step is simply to make sure the scope is defined as completely as possible to avoid future scope creep.
  3. Write the Product Requirement Document (PRD). Or collect the requirements in some other format that your team or organization has agreed to use—a spreadsheet, a database, or a requirements management tool like Jama Connect. This document should include relevant insights from the MRD and other supporting early notes. It should also integrate user stories, feature descriptions, functional and non-functional requirements, etc. It should have four main components: purpose, features, release criteria, and timeline.

 Phase Three: Submit for Review

Once you’ve conducted multiple requirements gathering sessions and completed the initial documentation, it’s time for review.

  1. Confirm requirements with stakeholders. Involve as many of the original stakeholders as possible. Ask them to review the requirements as defined in documentation. Are the requirements clear to all parties? Did the product development team miss any important requirements? Revise any requirements that are unclear to all parties. Be sure to get sign-off on individual requirements by relevant stakeholders.
  2. Conduct prototyping and testing. Wherever possible, conduct initial prototyping and testing on a working model of your specification. Perform feasibility, usability, and product concept testing. This step should be conducted at the same time as the previous step so that results can be shared with stakeholders.
  3. Prioritize requirements. Once requirements are clarified and signed off, the team should prioritize them with as specificity as possible. More than just noting whether a requirement is a “must have” or “nice to have,” prioritization should also involve ranking each requirement within the higher categories.

There is much room for overlap between these phases and steps, and it may feel overwhelming to undertake the entire requirement gathering process before any design or development begins. However, spending the time to conduct a thorough requirements gathering process can save time and money and create a much higher probability of success for your project.

Common Pitfalls of Requirement Gathering

Even when a thorough process is undertaken, teams can encounter challenges and pitfalls along the way that risk introducing delays into the project development process.

  • Making assumptions or not clarifying requirements. When faced with a long list of stakeholders or requirements gathering sessions, it’s tempting to make assumptions. Take the time to clarify, ask more specific questions, and get as much detail as possible. And be sure to be as specific as possible in your confirmation process!
  • Focusing on HOW instead of WHAT. Requirements should address WHAT a product MUST do (the functional requirements) and WHAT constraints it will have on how it achieves that functionality (the non-functional requirements). Don’t let assumptions about tools, features, techniques, implementation, or other development concerns influence how you gather and write requirements. Just listen to the needs of stakeholders and write the requirements to those needs.
  • Failing to adequately consult stakeholders. This pitfall could take several forms. It may mean not conducting enough sessions at the beginning of the process, or it could mean not adequately confirming requirements before beginning design and development. Be sure to get a thorough review and sign-off of all requirements before moving on to the next phase. One way to do this is with a good requirement management (RM) tool such as Jama Connect. With a requirements management tool, everyone has access to the same information, and notes and other feedback can be attached directly to requirements for traceability purposes.

Requirements Gathering for Agile Development

While the requirements gathering process outlined above is ideal for many projects, Agile teams have different needs, and an extensive requirement gathering process could interfere with their results. Agile teams expect to work fast, and scrums and sprints are typically just a few weeks, at most.

For Agile teams, a robust requirement management tool can streamline requirements gathering and management without sacrificing results. With a tool like Jama Connect, teams have transparency and access to requirements at all times, allowing easy annotation and clear traceability. Requirements management products encourage collaboration throughout the ALM product development process and offer clear advantages over static tools such as spreadsheets or simple documents.

Comprehensive requirements gathering is the key to a successful product development process. By clearly defining requirements and scope up front and getting sign-off from all stakeholders before full design begins, teams will have a much clearer path to product development success. While it’s no replacement for a requirements management solution like Jama Connect, which automates Live Traceability™, download this project requirements template to make things simpler.

 

requirements-management-hub


A Guide to Requirements Elicitation for Product Teams

 

The success of a development project relies on understanding the business need and defining the correct list of requirements. Requirement elicitation is the process of communicating and collaborating with key stakeholders to assemble the insight and identify the project’s needs.

This article will provide an overview of why requirements elicitation is important for product teams, discuss different elicitation techniques, and outline the steps involved in eliciting requirements.

What is requirements elicitation?

Business analysts conduct requirements elicitation to identify the business need, scope, assumptions, and risks of a project based on data from key stakeholders. It’s an imperative part of requirements management as the outcome impacts the fundamental understanding of the project’s goal. Failure to clearly define business needs can lead to catastrophic results such as expensive mistakes or system failure.

The importance of requirements elicitation for product teams

Requirements elicitation is important for product teams because it is the main way product requirements are identified. The elicitation process unearths requirements insights from key stakeholders. By expertly asking the right questions of subject matter experts, enabling deep conversations, and recording findings, business analysts discover the true business needs to drive the project.

In the absence of properly identified business needs and requirements, development costs will be over budget due to rework, users/customers will not get what they want, and projects will be unsuccessful.

The requirement elicitation process

An effective elicitation process is important for product teams to realize the following benefits:

  • Lower project costs by catching requirements problems before development begins.
  • Increase the likelihood that users and customers get what they want.
  • Reduce the risk of project failure.

RELATED POST: Requirements Management Maturity Model – Empirical vs Theory

There are five main steps to the requirements elicitation process:

  1. Gathering requirements

You may be thinking, “How is requirements elicitation different from requirements gathering?” especially when the two terms are often used interchangeably. It is a good question, and it is acceptable to casually interchange them. However, there is a slight difference between gathering requirements and requirements elicitation that is worth pointing out when discussing the specifics of the requirements elicitation process.

By definition, “gathering” is the act of collecting from scattered sources, while “eliciting” is the act of drawing out information from a source. Both acts are essential to the overall process of requirements elicitation and take expertise to execute properly.

An effective way to prepare for requirements elicitation is for business analysts to gather all available requirements and study them for insights. A few techniques for requirements gathering include:

  • Document analysis, such as studying process models or researching regulations.
  • Analyzing system interfaces and business rules.
  • Reading available user feedback.

The findings from requirements gathering can help identify key stakeholders and inform which requirements elicitation techniques might best suit the project. Business analysts can then begin the work of drawing out the enlightening experiences that fill in the missing requirements. Therefore, requirements gathering is the perfect first step in the process of requirements elicitation.

  1. Identifying key stakeholders

As noted, requirements gathering can provide insight on relevant stakeholders. It is important to identify the right people up front so everyone can begin on the same page. Doing so eliminates the need to fill in missing requirements later that could potentially change the course of the project.

  1. Eliciting requirements from key stakeholders

In this part of the process, business analysts need to determine which requirement elicitation techniques will provide the best results given the project at hand and appropriate stakeholders.

There are a variety of requirement elicitation techniques, here are some of the most popular methods.

Brainstorming –

Use case: Current solutions may not be innovative enough to meet the project’s goal.

Designed to: Uncover new, innovative ideas and solutions.

How to: Assemble a mix of key stakeholders for an open conversation on innovative ideas and solutions. As facilitator, the business analyst ensures that the conversation stays on topic and records ideas discussed.

Focus groups –

Use case: Business analysts need more information about specific aspects of the project. Time is short.

Designed to: Help stakeholders be more forthcoming and articulate solutions. Get a lot of information at once.

How to: Gather representatives from stakeholder groups. The facilitator asks questions to get team members to discuss specific areas of interest and records ideas discussed.

Interviews –

Use case: Get an in-depth perspective from a specific subject matter expert (SME).

Designed to: Obtain a stakeholder’s one-on-one insight on the business need or viability of given solutions.

How to: Create questions that will allow the SME to be open about the issues on the table. Questions can be shared in advance or be conducted as a conversation. The interviewer should take notes and share them with the SME to ensure he or she correctly understood the SME’s point of view.

Observation –

Use case: When the development project is an augmentation of a current work process.

Designed to: Provide a direct view of how a stakeholder performs a particular process.

How to: Observation can be conducted passively—the facilitator watches the stakeholder work without interrupting—or actively—the facilitator asks questions about the work as it is being performed. In both cases, the facilitator should take notes and get feedback from the stakeholder on the information collected.

Prototyping –

Use case: When stakeholders do not understand written technical requirements and would benefit from seeing a version of the product.

Designed to: Collect feedback from non-technical stakeholders by showing them an example with which they can physically interact.

How to: At first prototyping can be executed via storyboard, interactive screen, virtual mock-up, navigation flow, etc. The exact method depends on the project, but it is usually an iterative process that is improved based on input. As more requirements come forward, more detailed prototypes are created to ensure they meet the expectations as recorded.

Requirements workshops –

Use case: When time is short, and the business need is not clear.

Designed to: Get the stakeholders together in a structured, time-based setting to elicit, refine, and edit requirements. Stakeholders can discuss and provide immediate input on identified business needs.

How to: Set a specific timeframe and agenda for the workshop. Include brainstorming, focus group, and prototyping (if applicable) opportunities within the schedule. Use these to guide the discussion and record input.

Surveys –

Use case: When business analysts need data from large groups of participants.

Designed to: Obtain objective feedback from large groups of customers or end-users.

How to: Choose participants wisely based on desired criteria. Create clear questions that do not lead the respondents. Questions can have a number of finite choices or be open-ended—for best results consider the goal of the question, as well as the number of respondents, to determine the best structure for proper analysis.

As is often the case, a variety of requirements elicitation methods can be employed to unearth the business needs of a project. For example, a business analyst may ask specific requirements questions in a focus group, in a brainstorming session, or during observation. A business analyst may also conduct surveys before a requirements workshop, or create a prototype to be used during observation. Knowing which elicitation techniques to use for a given project comes with experience.

  1. Documenting requirements

The next step in the requirement elicitation process is documenting the requirements elicited thus far. There are a variety of formats for documenting requirements: a home-grown product requirements document (PRD), a government-mandated system requirements specification, a requirements management tool like Jama Connect, a spreadsheet, etc. The best tool for documenting requirements depends on the project.

If the project has many stakeholders, complex development, or compliance or functional safety standards, it’s a best practice to choose a requirements management tool like Jama Connect. These are purpose-built to mitigate risks associated with complex systems and regulatory compliance. Assessing needs and researching functionality will help determine the best option for the project

  1. Confirming the findings

Once business analysts document the requirements, it is time to make sure they are recorded correctly. Requirements are sent to all stakeholders to review so there is a collective understanding of what’s being developed. Stakeholders are likely to make refinements. It is also possible that this step elicits further requirements, which will necessitate revisions before approval can take place.

RELATED POST: Requirements Management – Living NOT Static

Business analysts conduct the process of requirements elicitation at the beginning of a project, and the process is ongoing throughout the development process. This is because change is always occurring and it’s never possible to know all the questions to ask or have all the correct answers upfront.

Challenges of successful requirement elicitation

The elicitation process may seem easy: ask the stakeholders what they want. However, it’s a much more rigorous endeavor. Here are some of the most common challenges of the requirements elicitation process.

Finding the right stakeholders – Identifying the correct subject matter experts isn’t always easy. Hunt down “hidden” stakeholders who can be excellent sources of knowledge. Examples include customer-facing personnel like sales/support reps and maintenance techs.

Uncovering the best insights – Unfortunately, stakeholders don’t always know what they want. In the practice of requirements elicitation, multiple elicitation methods can be used concurrently to identify the business need and an optimal list of requirements. The expertise is in realizing the best combination of techniques to yield success for that development project.

Documenting the requirements – Using the wrong documentation tool for the job can be detrimental. Issues can arise with everything from reviews and approvals to managing change. Spreadsheets or home-grown PRDs may work for smaller, non-regulated projects. Complex products or those in regulated industries, on the other hand, greatly benefit from requirements management software that can streamline requirements elicitation and the overall process with features like live traceability and compliance management.

Planning for change – Priorities shift and problems arise—it’s best to plan for changes up front. Be sure to have a process in place that allows time to address problems, document changes, and add new requirements, and conduct additional reviews.

Again, in projects with fewer requirements, it won’t be so grueling to scour spreadsheets or PDRs to manage change. However, this kind of manual change management can still eat up many work hours and push projects off schedule and off budget. With complex and regulated products, however, the potential for waste of time and money is much larger. In these cases, a tool like Jama Connect can save precious time and budget in the face of change. Having the right tool for the job is critical.

Streamlining the requirements elicitation process

Requirements elicitation is a mixture of art and science for business analysts. They need to be adept at knowing which questions to ask and how to ask them. Additionally, business analysts must be able to clearly communicate and collaborate with key stakeholders during all phases of the elicitation process.

Business analysts working on complex or highly regulated projects cannot rely on home-grown PRDs or spreadsheets to document requirements. The level of sophistication in which they are working demands that they have the best requirements elicitation tools at their fingertips.

Jama Connect is a requirements management tool that can transform how business analysts perform requirement elicitation for complex projects. See how Jama can streamline requirements elicitation and management.


A Guide to Requirements Analysis for Product Teams

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.

RELATED POST: Requirements Management Tools and Software

The requirements analysis process

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

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

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

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

See How Jama Connect streamlines requirements analysis and requirements management.

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


What is Requirements Gathering? A Process Guide for Product Teams

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. 
RELATED POST: Requirements Management Tools and Software

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. 

RELATED POST: What is Requirements Traceability and Why Does it Matter for Product Teams?

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. 

RELATED POST: Requirements Gathering Techniques for Agile Product Teams

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. 

 


11 Requirements Gathering Techniques for Agile Product Teams

Requirements Gathering Techniques

It would be nice if requirements gathering was as simple as asking your customers and stakeholders what they want your system to do. Unfortunately, it’s never that straightforward.

In most cases, stakeholders are not aware of all the alternatives that exist when it comes to developing a specific product. Immersed in the current status quo, their vision tends to be limited. It’s hard for users to detach from the way they’re currently doing things—to imagine possibilities that are a significant departure from what they have now.

Furthermore, there’s no silver bullet. No single requirement gathering technique will help you elicit a complete set of requirements that will fill every gap and stand up to scrutiny during validation.

That’s why it’s a good idea to take a multi-faceted approach to requirements gathering. Requirements engineering best practices recommend using a variety of methods aimed at different phases of the process.

This article looks at eleven effective requirements gathering techniques. They will be presented roughly in the order in which they normally appear in the requirements gathering process. It is not necessary to use all of them for every project, but a healthy mix of these techniques, chosen based on the needs of your specific project, will likely improve your requirements coverage and help you reduce requirements-related problems during software development and afterward.

  • Interviews
  • Questionnaires or Surveys
  • User Observation
  • Document Analysis
  • Interface analysis
  • Workshops
  • Brainstorming
  • Role-play
  • Use Cases and Scenarios
  • Focus Groups
  • Prototyping

Requirements Gathering Technique #1: Interviews

Interviews are a great way to start the requirements elicitation process. They are invaluable for gathering background information on business needs, customers’ and users’ problems, and the concerns of support staff and other relevant stakeholders. Interviews can also be used in follow-up to gather more detailed information.

Interviews should cover a diverse and representative cross-section of the system’s stakeholders. You will want to include the full range of customer and user profiles. This is necessary to gain a proper perspective on competing needs, so your system requirements aren’t slanted in favor of one group.

When you conduct interviews, it is important to ask open-ended questions. Open-ended questions are those that cannot be answered with a simple “yes” or “no.” They draw out specific information. They require the interviewee to explain their thoughts and provide reasons, which in turn provides context for evaluating and validating the requirements.

You’ll also want to ask a lot of follow-up questions during the interview. Good follow-up questions either drill down for more detail or pull up to get an overview of the context. Some people will tend to talk specifics and exceptions. With them, you’ll need to pull up. Others will talk about context without ever getting into specifics. With those folks, you’ll need to drill down.

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

Requirements Gathering Technique #2: Questionnaires or Surveys

Individual interviews present several challenges. They can be tricky to schedule and time-consuming for the interviewers. Plus, the requirements you gather may only scratch the surface; not every interviewer is skilled at asking follow-up questions in real time.

Questionnaires (or surveys) can provide an efficient alternative. They allow follow-up with multiple stakeholders at the same time.

A well-thought-out questionnaire—one that asks probing questions—is a good tool for getting at those underlying requirements of which stakeholders may not be fully conscious, but which are essential to a successful design.

Technique #3: User Observation

One of the best ways to understand what users truly need is to observe them performing their daily tasks.

User observation can be either passive or active. Active observation—asking questions of users while observing them—is the best approach for gaining an understanding of an existing process. Passive observation is more effective when gathering user feedback on a design prototype (see technique #11).

When observing users, record the actions and activities that take place. What already works well? What causes users difficulty? Note the obstacles users must routinely overcome.

By observing end users in the real context in which they perform their tasks, you’ll gain a true understanding of what they are up against and what improvements they need so they can perform better. You’ll then be better able to specify a system that successfully reinvents users’ processes and grants them far greater productivity and usability, rather than simply providing them an incremental improvement.

Technique #4: Document Analysis

Frequently overlooked, document analysis is another highly effective technique for gathering requirements.

Reviewing the documentation of the current system you’re seeking to replace can help you in performing AS-IS process analysis and gap analysis. The former helps you see where you can improve the user’s process. The latter will aid you in determining where the business needs revealed earlier—through your interviews, questionnaires, and user observation—are not being met.

Naturally, you’ll want to analyze the system’s requirements documents, if available, but you should also look at other system-level documentation, such as users’ manuals and problem reports.

Nuggets of information on why the existing system works as it does are often buried within the specifications and design documentation. The insights gained from document analysis can help you formulate further questions and evaluate the completeness of your requirement set.

RELATED POST: What is Requirements Traceability and Why Does it Matter for Product Teams?

Requirements Gathering Technique #5: Interface Analysis

Analyzing a system’s interfaces, both human and machine, is vitally important to ensure requirements are complete and the system will be usable.

Interfaces for a software product will include those with:

  • End users
  • System components the software interacts with (e.g., sensors or other peripherals)
  • External systems the software interacts with

Thorough interface analysis—really understanding the interactive context of the system— will frequently uncover requirements not readily visible to users.

Technique #6: Brainstorming

Brainstorming can be performed as part of a workshop (see technique #7, which follows) or on its own, in either large or small groups.

In your brainstorming session, consider different parts of the system individually. Explore various what-if scenarios and blue-sky ideas. The general idea is to break away from existing conventions. Consider visionary ideas for pushing current boundaries.

Useful tools for brainstorming sessions include whiteboards, mind mapping software, and empathy maps (the latter for exploring user needs).

Technique #7: Workshops

When gathering requirements from a broad spectrum of stakeholders, it’s only natural that you’ll get conflicting opinions. You will need to resolve these issues, however, before implementation begins.

Requirements workshops are a good method for resolving such conflicts.

Once you have a broad set of candidate requirements defined and organized, convene your stakeholders and hash through these candidates together. Gather additional detail. Give a fair hearing to opposing views. Grant everyone ample opportunity to provide the rationale for their positions.

Seek to resolve discrepancies and conflicts, gain consensus, and validate your requirements. These activities are vital to ensuring your system will best meet the needs of all users and stakeholders, not just the most vocal groups.

Technique #8: Role-play

Some systems—certain kinds of enterprise software, like ERP, for example—must meet the needs of a variety of user types. Role-play can help to ensure that the needs of all users are being met.

In a role-play session, different people take the roles of the different user types. Having the various roles interact with one another helps examine individual system requirements from different perspectives and generates discussions and new ideas.

In effect, role-play is an additional brainstorming technique. It is a good way to gain a solid understanding of how the various parts of the system need to function to support the overall process.

RELATED POST: Requirements Management Tools and Software

Requirements Gathering Technique #9: Use Cases and Scenarios

Once you have high-level functional requirements in place, it is a good idea to explore a variety of use cases and scenarios.

Use cases are the specific, individual business objectives the system must accomplish and the various situations in which a given feature or functionality will be used. They describe the various external entities that act on the system and the specific interactions they have with the system to accomplish the business objective. Use cases are expressed as step-by-step lists of tasks performed during a process.

Scenarios, also called user stories, are similar to use cases in that they describe how the system will carry out a process to fulfill a business objective. Their form, however, is a narrative, rather than an enumerated list. They are essentially short stories with the user in the role of the protagonist. Scenarios describe:

  • Tasks users perform
  • Information users see
  • How users interact with the system

Use cases and scenarios can be used to validate the features and functional requirements of the system across a wide range of situations. They can also help you discover exceptions and boundary cases that need consideration.

Requirements Gathering Technique #10: Focus Groups

A focus group (or user group) is a gathering of customers or user representatives who meet with you to

  • Provide feedback on your product
  • Express their needs
  • Help guide your software development

Focus groups can be convened to either:

  • Gather information for the development of requirements, or
  • Gain feedback aimed at validated previously elicited requirements

Focus groups are different from brainstorming. Brainstorming is a managed process that generally involves internal stakeholders. Focus groups typically involve external stakeholders.

Many systems engineers and business analysts are skeptical of using focus groups to gather requirements. Meetings can be dominated by vocal individuals with narrow agendas. Strong disagreements on needs and features can make these meetings unproductive. Focus groups can, however, be extremely useful in certain situations. One of these is the evaluation of design prototypes (see technique #11) to help validate and finalize requirements.

Requirements Gathering Technique #11: Prototyping

There’s an old joke among systems engineers that the discussion with a user group following a design presentation often goes something like this…

System engineer: “So, what do you think?”

User group: “We hate it.”

System engineer: “Ah… okay, well… what is it you want, then?”

User group: “Well… we don’t know… BUT IT AIN’T THAT!”

Often, end users and other stakeholders don’t have a clear idea of what they truly want. In most cases, they don’t have a good grasp of what’s possible. If you can give them something to try, however, they can usually tell you what they like and don’t like about it.

That’s where prototyping comes in.

Prototyping gives users a chance to try out ideas on what their next solution could look like. Today’s rapid prototyping tools allow developers to quickly put together any number of interactive mock-ups for users to try.

Once the initial mock-up is built, the process is an iterative one:

  • Trial of the prototype by users
  • Feedback from users
  • Modification of the prototype

Modern prototyping tools make it easy for developers to modify the prototype on the fly, so users can help you quickly discover what will satisfy them. From that working model, it’s then a relatively simple matter to reverse engineer the requirements that describe the accepted functionality.

Automating the Requirements Gathering Techniques Process

As you gather and develop requirements, it is beneficial to have a flexible, user-friendly system for collecting them, organizing them, and making them available to relevant stakeholders. This is especially true in agile development where documents and spreadsheets can prove especially cumbersome.

To see how Jama Connect can streamline requirements gathering and management for Agile teams, click here.


8 Do’s and Don’ts for Writing Requirements

Every word matters when writing requirements. Something as simple as adding an adverb or using “should” instead of “must” can create ambiguity that confuses engineers and sets a project back.

Better requirements lead to clearer, more effective communication between stakeholders. This drives the entire organization toward greater transparency, less rework, and, accelerated development… without sacrificing quality. While writing requirements is both an art and a science that will vary by context, there are a few best practices to consider.

Follow these top dos and don’ts for writing requirements and you’ll find yourself with both clear and traceable requirements across the product development lifecycle.

1. DO: Use a Requirements Template

A template gives consistent structure to requirements. It can be in a user story or systems engineering format, either of which provides uniform construction to support easier testing.

2. DON’T: Use Adverbs

“Quickly,” “easily,” and other adverbs don’t provide clear guidance to testers. Instead, focus on acceptance criteria that are testable and measurable.

RELATED POST: Requirements Management – Living NOT Static

3. DO: Standardize Your Language

The English language contains numerous words with similar meanings in everyday usage. Settle on a few to represent agreed-upon meanings, like “shall” for binding high-priority requirements.

4. DON’T: Be Ambiguous

Requirements are often ambiguous because they’re too general, e.g., “the device shall be easy to use.” Get more specific, whether that means setting a clear benchmark or naming a specific color

5. DO: Use Active Voice and Specific Adjectives

Use active voice verbs. For instance, “the car shall withstand…” is clearer than “the car shall be enhanced to withstand…” Also select specific adjectives instead of standbys like “user-friendly” and “compatible.”

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

6. DON’T: Mix Design Specifications into Requirements

When possible, aim to remove design from requirements, as the latter describe a need while the former constitute a response to that need. Design-free requirements give engineers more freedom.

7. DO: Regularly Review Requirements with Stakeholders

Reviewing your requirements with others is a reliable way to ensure shared understanding. Collaborating within a real-time platform lets teams exchange feedback, ensure testability, and minimize rework.

8. DON’T: Rely on Negative Requirements Statements

Negative statements can introduce ambiguity, since there are virtually infinite things that any system will “not do” en route to fulfilling its positive requirements. Check negative statements

To learn more about how to write requirements in a way that all stakeholders have a clear understanding of development needs, download our eBook, Best Practices for Writing Requirements.

READ THE EBOOK

Business analysts and managers sometimes ask me how long it will take to “do requirements” on their next project.

As with so many issues in software and product development, the correct answer to this question is “it depends.”

Multiple variables contribute to this issue. Various industry averages have been published to suggest what percentage of a typical project’s effort should be devoted to requirements development, which includes activities such as requirements gathering (also known as requirements elicitation).

Data from different benchmarks don’t agree very well, though, and whether these “typical” projects are similar to your own is questionable. In this article, adapted from my book, “More about Software Requirements,” I’ll offer some suggestions about how you can determine an appropriate amount of time and effort to invest in things like requirements gathering.

Industry Benchmarks

Here’s an illustration of how benchmarks may or may not be helpful. Table 1 (below) presents some industry benchmark data for the average percentage of total effort and the average schedule time that projects in several different categories devote to requirements elicitation and prototyping (data from Capers Jones’ “Software Assessments, Benchmarks, and Best Practices”). These benchmarks are for very large projects of 10,000 function points in size (approximately one million lines of code). How similar are your projects to these benchmarks?

Table 1. Benchmarks for Requirements Work on Large Projects

There’s another problem with using industry benchmarks such as these. The data doesn’t indicate how successful those projects were or define what “success” means for each project. Nor does this data indicate whether the more successful project teams devoted more of their effort to requirements elicitation activities than the less successful teams — they’re just averages of actual performance.

Whereas typical project teams devote perhaps 10% or less of their effort on things like requirements gathering, investing more has a big payoff, provided the team doesn’t get trapped in analysis paralysis. Contrary to what many people believe, spending more effort in improving your requirements development process can actually accelerate development.

A recent study by Engineering.com found that development teams without strong requirements management platforms reported more production outcome failures and reprimands by regulatory agencies.

Read it now.

While working on small projects when I was employed at Kodak, my team would typically devote 15%-to-18% of our total effort on requirements activities. We found this investment reduced the amount of post-delivery rework. It’s difficult to link causes and effects with certainty, but I believe the greatest contributing factor to our low maintenance level was the extensive user participation we cultivated.

I can’t tell you how long you should expect to spend on requirements gathering for your next project. However, Figure 1 identifies some of the conditions that can accelerate your requirements process and several other factors that lengthen the time needed for developing effective requirements.

Figure 1. Factors that influence the time needed for requirements development.

Your Own Experience

For starters, your best bet is to collect some data on how much of your own project effort is spent on requirements gathering. That’ll help you judge how well that has worked for you in the past. Use this historical data when estimating the requirements effort needed for future projects. Adjust your initial estimate by using the considerations in Figure 1 to compensate for differences between your next project and the benchmark projects. Consider any additional factors that would influence your own project. You might weight each of the factors shown in Figure 1 on a scale of 0 (no effect) to 5 (major impact). This analysis can help you spot risk factors that could prolong your requirements development work.

Another factor to consider is the development life cycle that the project is following. Not all the requirements elicitation effort should be allocated to the early stages of the project, as is the case in the sequential or waterfall life cycle (dotted line in Figure 2). Don’t think in terms of a discrete “requirements phase,” but rather about a set of requirements-related activities that span the project’s life cycle. In particular, requirements management will be performed on an ongoing basis once a set of requirements baselines emerge for the System Requirements Specification (SRS) and change requests begin to appear.

Figure 2. The distribution of requirements effort over time varies for projects that follow different development life cycles.