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.
- 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.
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 living requirements 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/