Requirements Capture and Analysis: Processes, Interviews, Use Cases, and Scenarios
This article explains the systematic activities of requirements capture and analysis, describing stakeholder involvement, the four main processes of discovery, interview techniques, use‑case and scenario modeling, and subsequent classification, prioritization, negotiation, and specification of software requirements.
Requirements Capture and Analysis
It is a process of interacting with customers and end‑users to identify domain needs, the services the system should provide, and other constraints.
Domain needs reflect the environment in which the system operates, such as train operations, medical records, or e‑commerce.
Stakeholders may include end‑users, managers, system engineers, test engineers, maintenance engineers, etc.; anyone who can directly or indirectly influence requirements.
Four Main Processes of Requirements Capture and Analysis
1. Discovery : interact with stakeholders to collect needs about the desired system and any existing systems.
2. Collection and Understanding : gather requirements through discussions, interviews, or graphical symbols.
3. Organization and Prioritization : group related requirements into sub‑components, rank them, and refine by removing ambiguous or conflicting items.
4. Specification : document the finalized requirements for later phases.
Interviews
Interviewers ask stakeholders about the current system and the system to be developed to extract requirements.
Questions are of two types:
Closed‑ended: a predefined set of questions.
Open‑ended: no predefined answer, used to explore unclear issues.
In practice, interviews combine both: start with open‑ended questions, then use closed‑ended ones for clarification.
Interviews help understand what stakeholders need, how they will interact with the new system, and the difficulties they face with the current system.
Challenges include domain‑specific terminology that engineers may misinterpret and stakeholders omitting “obvious” requirements.
Use Cases and Scenarios
Use cases and scenarios are complementary techniques that describe system interactions.
A use case identifies interactions between the system, its users, and external systems using graphical symbols; a scenario provides a textual description of one or more of those interactions.
Use‑case diagram symbols include:
Actor: a person or another system that interacts with the system.
Use case (interaction): represented by an ellipse with a verb name.
Association: a line connecting actors and use cases.
Include relationship: shows one use case invoking another.
Extend relationship: optional behavior that extends a base use case.
Scenarios describe each use case with a format covering initial conditions, event flow, exceptions, parallel activities, and final state.
Requirement Classification and Organization
Group related requirements, decompose the system into sub‑components, and define relationships among components to aid architectural design.
Prioritization and Negotiation
Identify conflicts among stakeholder needs, negotiate compromises, and assign priorities so that high‑priority features receive more focus.
Specification
Record the refined requirements in a formal specification document, which will be discussed in detail in the subsequent “Requirements Specification” section.
For further reading, see the original article at http://jiagoushi.pro/requirements-engineering-elicitation-analysis-part-2 .
Architects Research Society
A daily treasure trove for architects, expanding your view and depth. We share enterprise, business, application, data, technology, and security architecture, discuss frameworks, planning, governance, standards, and implementation, and explore emerging styles such as microservices, event‑driven, micro‑frontend, big data, data warehousing, IoT, and AI architecture.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.