Requirement Analysis

Requirement analysis is the critical thinking phase of requirements engineering—examining raw requirements gathered during elicitation to determine if they are complete, consistent, feasible, and unambiguous. Elicitation gives you raw material; analysis refines it into something a development team can actually build from. Think of elicitation as mining ore and analysis as refining it into usable metal. Without analysis, requirements documents contain contradictions, gaps, impossibilities, and ambiguities that will cause expensive problems during development.

Analysis Activities

Conflict Detection and Resolution: Different stakeholders often want contradictory things. The marketing team wants every feature immediately; the engineering team wants time for quality. Customers want the cheapest price; the business needs profitable margins. Analysis identifies these conflicts explicitly and facilitates resolution.

Completeness Checking: Are there scenarios not addressed? What happens when the user enters invalid data? What happens during system failure? What about edge cases like empty lists, maximum values, or concurrent access? Analysis ensures every scenario has a defined system response.

Consistency Verification: Do requirements contradict each other? If REQ-001 says "users can delete their account" and REQ-042 says "user transaction history must be retained for 7 years," there is a conflict that analysis must resolve (perhaps: account deletion removes personal data but retains anonymized transaction records).

Feasibility Assessment: Can each requirement actually be implemented with available technology, budget, and timeline? A requirement for "real-time language translation with 99.9% accuracy" may not be technically feasible with current technology.

Prioritization: Not all requirements are equally important. MoSCoW classification (Must have, Should have, Could have, Won't have this time) helps teams focus on what matters most when resources are constrained.

Analysis Techniques

Requirement Modeling

Visual models reveal gaps and relationships that text descriptions miss:

Use Case Diagrams show system boundaries and actor interactions—helping identify missing actors or forgotten functionality.

Data Flow Diagrams trace how information moves through the system—revealing missing data sources, transformations, or storage.

Entity-Relationship Diagrams model data requirements—exposing missing entities, undefined relationships, and cardinality ambiguities.

State Machine Diagrams model entity lifecycles—revealing missing states, undefined transitions, or impossible state combinations.

Structured Analysis

Decision Tables systematically enumerate all condition combinations and their required actions—revealing cases that stakeholders forgot to specify.

Scenario Analysis walks through specific usage scenarios step by step, asking "what if?" at each point to uncover missing requirements.

Formal Methods

For safety-critical systems, formal mathematical specifications (Z notation, VDM, B-method) can prove requirement consistency and detect logical contradictions that human review might miss.

Real-World Example: Online Banking Analysis

Raw requirements from stakeholders include:

• "Customers can transfer money between their accounts"
• "The system must be secure"
• "Transfers should be fast"

Analysis transforms these into precise, implementable requirements:

Completeness analysis reveals questions:

• What is the maximum transfer amount? (Per transaction? Per day?)
• What happens if the source account has insufficient funds?
• Can customers transfer to accounts at other banks?
• What authentication is required for transfers?
• What happens if the system fails mid-transfer?

Consistency analysis finds conflicts:

• Security requirement demands multi-factor authentication for transfers
• Usability requirement says transfers should complete in "one click"
• Resolution: MFA for transfers over $1,000; single confirmation for smaller amounts

Feasibility analysis identifies constraints:

• Real-time inter-bank transfers require connection to national payment network (cost: $500K integration)
• Budget allows intra-bank transfers now; inter-bank transfers in Phase 2

Refined requirements:

• REQ-T-001: Customers shall transfer funds between their own accounts instantly
• REQ-T-002: Maximum single transfer: $50,000. Maximum daily: $100,000
• REQ-T-003: Insufficient funds shall display the available balance and reject the transfer
• REQ-T-004: Transfers over $1,000 require SMS verification code
• REQ-T-005: System failure during transfer shall roll back completely within 30 seconds
• REQ-T-006: Transfer history shall be available for 7 years

Analysis Deliverables

• Refined requirements document with conflicts resolved and gaps filled
• Prioritized requirement list with MoSCoW or numeric priority
• Analysis models (use cases, data models, state diagrams)
• Requirements traceability matrix (linking requirements to sources)
• Risk assessment (technically challenging or high-impact requirements)
• Open issues list (questions requiring further stakeholder input)

Common Analysis Pitfalls

Accepting vague requirements without questioning ("the system should be user-friendly"), assuming unstated requirements are obvious (they are not—make everything explicit), analysis paralysis (spending too long perfecting requirements before starting development), and ignoring non-functional requirements during analysis (discovering performance or security problems during testing is extremely expensive).