Business Analysis 101: Requirements Analysis and Design Definition - Modeling Requirements, Use Cases, User Stories, Activity Diagrams

Modeling Requirements (Use Cases, User Stories, Activity Diagrams)

What This Is

Modeling requirements is the practice of turning stakeholder needs into visual or textual artifacts that clearly describe what the solution must do and how users will interact with it. In the BABOK® life?cycle, modeling sits in the Requirements Life Cycle Management and Solution Evaluation knowledge areas, serving as a bridge between elicitation (understanding the need) and specification (defining the need).

Real?world example: A bank wants a new Customer Relationship Management (CRM) system to track sales leads, service requests, and marketing campaigns. The BA creates use?case diagrams to show the “Create Lead” and “Update Customer Profile” interactions, writes user stories for the agile development team (“As a sales rep, I want to add a lead so I can follow up later”), and draws activity diagrams to map the end?to?end “Lead?to?Opportunity” process.

Key Terms & Techniques

• Use Case – A textual description of a system’s interaction with an actor to achieve a goal; delivered as a Use?Case Specification (BABOK: Requirements Analysis).
• Actor – Any person, system, or external entity that interacts with the solution; appears in Use?Case and Activity diagrams.
• User Story – A short, “role?goal?benefit” statement that captures a functional need; primary artifact for Agile (BABOK: Solution Scope).
• Acceptance Criteria – Conditions that must be true for a user story to be considered complete; documented in the Definition of Done (Solution Scope).
• Activity Diagram – A BPMN?style flowchart that shows the sequence of activities, decisions, and parallel paths; output of Business Process Modeling (BABOK: Business Analysis Planning).
• Swimlane – A visual lane in an activity diagram that groups activities by actor or system; helps clarify responsibilities.
• Scenario – A concrete example that walks through a use case or user story; used for validation (Requirements Life Cycle Management).
• Traceability Matrix – A table linking requirements (or stories) to design, test cases, and business objectives; a key deliverable for Requirements Management & Communication.
• Story Mapping – Organizing user stories along a backbone (high?level activities) and slices (details) to visualize product backlog priorities (Solution Scope).
• MoSCoW Prioritization – Classifying requirements as Must, Should, Could, Won’t; often applied to user stories during backlog grooming (Requirements Life Cycle Management).
• Non?Functional Requirement (NFR) – Quality attributes (performance, security, usability) that are modeled alongside functional stories, usually as quality?of?service statements.

Step?by?Step / Process Flow

1. Identify & Confirm Actors – Review stakeholder register and interview notes; create an actor list and validate with the sponsor.
2. Elicit & Capture Functional Needs – Run workshops or interviews; capture raw needs as user story cards (“As a … I need … so that …”).
3. Select Modeling Technique – Choose use cases for complex, multi?step interactions, user stories for agile backlog items, or activity diagrams for end?to?end process visualization.
4. Develop the Model
5. Use Cases: Write a brief description, then flesh out the main flow, alternate flows, and exception paths.
6. User Stories: Add acceptance criteria, assign story points, and place in the backlog.
7. Activity Diagrams: Sketch the workflow, add swimlanes, decision nodes, and parallel forks.
8. Validate with Stakeholders – Conduct a walkthrough (scenario?based) or a “story?review” session; capture feedback and update the model.
9. Baseline & Maintain – Freeze the approved models in the requirements baseline; keep the traceability matrix up?to?date as changes occur.

Common Mistakes

Certification Exam Tips

1. Know the Input/Output Relationships – For modeling, the primary input is elicitation results (e.g., stakeholder needs); the output is models (use?case specs, activity diagrams, story cards). Exam questions often ask “What does the BA produce after elicitation?” – answer: models.
2. Distinguish Knowledge Areas – Use?case and activity?diagram creation belong to Requirements Analysis (part of the Requirements Life Cycle Management KA), while user stories are a technique of Solution Scope (Agile?focused). Remember the KA name to avoid “wrong area” traps.
3. Watch the “next step” pattern – After a requirements workshop, the BA typically models the information (e.g., writes use cases or user stories) before moving to validation. Choose the option that mentions modeling rather than design or implementation.
4. Remember the “definition of done” – Acceptance criteria are outputs of the User Story technique; they are not the same as test cases (which are outputs of Solution Evaluation).

Quick Check Questions

1. Scenario: After a requirements workshop, the team has a list of functional needs but the sponsor wants to see how the system will be used. Which modeling artifact should the BA create first?
   Answer: Use?Case Diagram – it visualizes actors and their interactions with the system, satisfying the sponsor’s request for a high?level view.

2. Scenario: The development team works in two?week sprints and needs concise, testable items. Which technique best fits this environment?
   Answer: User Stories – they are short, role?goal?benefit statements that can be sized, prioritized, and delivered within a sprint.

3. Scenario: A process analyst needs to illustrate parallel approvals in a loan?origination workflow. Which diagram element should be used?
   Answer: Parallel Fork/Join in an Activity Diagram – it shows activities that occur simultaneously and later converge.

Last?Minute Cram Sheet (10 One?Liners)

1. Elicitation = activity; Requirements = output – the BA elicits information, not the requirements themselves.
2. Use Cases belong to the Requirements Analysis knowledge area; they produce Use?Case Specifications.
3. User Stories are a Solution Scope technique; they are written in “As a?… I want?… so that?…” format.
4. Activity Diagrams are part of Business Process Modeling (a sub?task of Requirements Analysis).
5. Actors can be people, systems, or external entities; they appear in both use?case and activity diagrams.
6. Acceptance Criteria are the definition of done for a user story, not the same as test cases.
7. Traceability Matrix links requirements (or stories) to design, test, and business objectives – essential for baseline control.
8. MoSCoW is a prioritization technique used after modeling to order backlog items.
9. Swimlanes in activity diagrams group activities by responsible party, clarifying ownership.
10. Scenario walkthroughs validate models; they are a key activity in Requirements Life Cycle Management.