Mastering Requirement Analysis: Key Modeling Techniques & Common Pitfalls

Key Points and Pitfalls of Requirement Analysis Modeling

Requirement analysis is not about figuring out how to implement user needs; it is about analyzing the business to build a complete, clear business framework that guides later design and development.

The process involves decomposition, refinement, and contradiction elimination.

Decomposition

Modern requirements engineering recommends business‑oriented decomposition rather than traditional system‑oriented decomposition.

Business‑process‑driven decomposition

This structure uses the business process as the main thread and suits both OLTP systems and management information systems.

Program‑structure‑driven decomposition

Introducing program structure too early severs the link to the problem domain, leading to insufficient problem research, lower requirement quality, and higher change risk. It is suitable only for simple, loosely coupled problems such as tool software or device‑oriented systems.

Scenario‑driven decomposition

Ideal for decision‑support systems and user‑oriented embedded systems; scenarios can be abstracted into focus areas or functional domains and broken down into concrete decision steps.

Data‑driven decomposition

After selecting an appropriate decomposition structure, the outline of the requirement specification can be defined, guiding what information to capture and continuously validate.

Refinement

Decomposition is a top‑down approach; to preserve other decomposition lines, a bottom‑up refinement extracts commonalities and builds a global domain model.

Eliminating Contradictions

...

Modeling Goals and Key Points

The modeling process is more important than the result. Modeling should serve the analysis; modeling for its own sake creates unnecessary communication barriers.

Purpose of Modeling

Modeling helps visualize the system, provides a detailed description of structure or behavior, offers a template for construction, and documents decisions.

Key Modeling Principles

Design must be documented; use visual models to express architecture; avoid modeling without purpose—if a model does not aid construction, it wastes resources.

Models are communication tools and should be built only when needed.

Choosing Modeling Tools

Understand the modeling methodology before selecting tools.

UML is the most common method; know its history, accurate interpretation, reasons for use, and how to choose UML diagrams.

Cycle 1: Clarify Framework and Context

Task: Clarify the requirement structure (domain class diagram) and behavior context (flowchart and use‑case diagram).

Input: Business event list and report list from the requirement definition phase.

Output: Domain model and use‑case model.

This corresponds to the first iteration of the refinement phase in RUP; its end marker is the identification of most use cases and generation of the domain model.

Business Process Analysis

Each business event triggers a process; analyze each event, using textual description for simple flows and flowcharts for complex ones.

Key points: capture core business activities, department connections, and high‑cost, low‑efficiency activities.

Process characteristics: goal‑oriented, intrinsic, holistic, dynamic, hierarchical, structural.

Workflow implementation essence and design principles: focus on output, let the output‑oriented person execute the process, delegate decision‑making to lower management levels, accommodate process diversity, and maintain single‑point customer contact.

Process improvement (BPR) ESIA strategy: Eliminate inefficiencies (E), Simplify bottlenecks (S), Integrate resources (I), Automate tedious tasks (A).

Business Process Analysis Artifacts

Processes are hierarchical and typed: production, management, and supporting processes.

Artifacts: cross‑responsibility flowcharts, activity diagrams, and data‑flow diagrams.

Cross‑responsibility flowchart emphasizes business context; Visio is recommended.

Activity diagram supports parallel behavior.

Data‑flow diagram emphasizes data movement; Visio is also recommended.

Cycle 2: Detail Requirements

Fill in details of use‑case and domain models. For behavioral requirements, capture event flows, related features, UI prototypes, and rules/constraints. For structural requirements, capture fields, formats, calculation rules, and structural rules.

Behavioral Requirement Details

Behavioral requirements correspond to the "thing" of the four main demand lines (person, thing, object, interface).

Four types: business functions, report functions, interfaces, technical support.

Use‑case description template includes event flow, related features, UI prototype, and rules/constraints.

Business use‑cases describe all business operations; system use‑cases describe only system‑related steps. Removing non‑system steps yields a clean system use‑case.

Guidelines: avoid implementation details, branching, loops in event‑flow descriptions; keep the subject; use business verbs for naming.

Interface Requirements

Identify interfaces, then describe users, content & format, and design constraints without discussing implementation.

Non‑Functional Requirements Tracking

Analyze quality attributes using standards such as ISO/IEC 9126 or McCall model, covering functionality, reliability, usability, efficiency, maintainability, and portability.

Summary

The core of the SERU method is to start from the four main lines—"thing, object, person, interface"—and follow the business thread (business domain → business event/process → business activity → business step) to decompose and construct components, flowcharts, use‑cases, and event flows, thereby achieving effective requirement analysis.