Requirements Analysis Techniques Listing
Most Widely Used Techniques
Requirements analysis is the tasks that an analyst performs to structure and organize requirements, specify and model requirements and designs, validate and verify information, identify solution options that meet business needs, and estimate the potential value that could be realized for a solution option.
While the BABOK specifies over 50 specific requirements analysis techniques, there are many that are used more than others. We’ve shared some of our favorites below.
Acceptance and Evaluation Criteria
Acceptance criteria are used to define the requirements, outcomes, or conditions that must be met in order for a solution to be considered acceptable to key stakeholders. Evaluation criteria are the measures used to assess a set of requirements in order to choose between multiple solutions. The Acceptance and Evaluation Criteria technique can apply at all levels of a project, from high-level to a more detailed level.
Scope models are commonly used to describe the boundaries of control, change, a solution, or a need. They may also be used to delimit any simple boundary. Scope models are typically represented as a combination of diagrams, matrices, and textual explanations. Two of the most common scope diagrams are the Context Diagram (shown below) or a Use Case Diagram.
Decision analysis formally assesses a problem and possible decisions in order to determine the value of alternate outcomes under conditions of uncertainty.
Some general decision analysis tools and techniques include:
- Decision Tables
- Decision Trees
- Decision Models
- Force Field Analysis
Process models describe the sequential flow of work or activities. A business process model describes the sequential flow of work across defined tasks and activities through an enterprise or part of an enterprise. A system process model defines the sequential flow of control among programs or units within a computer system. A program process flow shows the sequential execution of program statements within a software program. A process model can also be used in documenting operational procedures.
Processes can be depicted using a variety of diagrams and techniques including:
- Capability & Process Text Template
- Functional Decomposition Diagram
- User Story
- Use Case Diagram
- Use Case Description
Use Cases and Scenarios
Use cases describe the interactions between the primary actor, the solution, and any secondary actors needed to achieve the primary actor’s goal. Use case diagrams are a graphical representation of the relationships between actors and one or more use cases supported by the solution.
A scenario describes just one way that an actor can accomplish a particular goal. Scenarios are written as a series of steps performed by actors or by the solution that enable an actor to achieve a goal. A use case describes several scenarios.
User stories capture the needs of a specific stakeholder and enable teams to define features of value to a stakeholder using short, simple documentation. They can serve as a basis for identifying needs and allow for the prioritizing, estimating, and planning of solutions.
A user story is typically a sentence or two that describes who has the need addressed by the story, the goal the user is trying to accomplish, and any additional information that may be critical to understanding the scope of the story. With a focus on stakeholder value, user stories invite exploration of the requirements by promoting additional conversations with stakeholders and grouping functional requirements for delivery.
A data model describes the entities, classes or data objects relevant to a domain, the attributes that are used to describe them, and the relationships among them to provide a common set of semantics for analysis and implementation.
Logical and physical data models include elements specific to the solutions they support, and are generally developed by stakeholders with expertise in implementing particular technical solutions. For instance, logical and physical entity-relationship diagrams (ERDs) would be used to implement a relational database, whereas a logical or physical class diagram would be used to support object-oriented software development.