Wireless Sensor Networks (IT-604 (C)) - Unit 3 Short Notes

3. Requirements Engineering

Feasibility Studies

A preliminary analysis to determine if a software project is viable and worth pursuing before committing significant resources.

Types of Feasibility:

• Technical: Can the technology be implemented?

• Economic: Cost-benefit analysis (ROI, NPV, payback period).

• Operational: Will it fit into existing workflows?

• Schedule: Can it be completed in time?

• Legal/Regulatory: Compliance with laws/standards.

Outcomes:

• Go/No-Go decision on project initiation.

• Refined initial requirements based on constraints.

• Identified risks and assumptions.

• Preliminary cost and time estimates.

Effects on Requirements Collection:

• Explicit: Feasibility outcomes directly document constraints (e.g., budget, technology stack) that become part of the SRS.

• Implicit: Shapes stakeholder expectations and prioritization of requirements; influences the scope and depth of elicitation activities.

[!TIP]

Exam Focus: Always link feasibility outcomes to how they shape or constrain the requirements in the SRS. Questions often ask for "effects on requirements" – emphasize both explicit (documented) and implicit (influence on process) effects.

Requirements Elicitation

The process of gathering requirements from stakeholders and sources.

Collection Methods:

Organization:

• Categorize into:

  • Functional Requirements (what the system does).

  • Non-Functional Requirements (how the system performs: performance, security, usability).

  • Constraints (limitations: budget, technology, regulations).

• Use a requirements hierarchy (e.g., goal → sub-goal → requirement).

Representation:

• Natural Language: Simple but ambiguous.

• Use Cases: Actor-goal interactions (e.g., "Withdraw Cash" in ATM).

• User Stories: "As a [role], I want [feature] so that [benefit]."

• Data Flow Diagrams (DFDs): Visualize data movement.

• Entity-Relationship Diagrams (ERDs): Data structure.

• Prototypes: Mock-ups or simulations.

[!TIP]

Common Pitfall: Elicitation ≠ collection only. Always mention organization and representation as separate, critical steps. Past papers ask "how are they organized and represented?" – structure your answer in three parts: methods, organization, representation.

Software Requirements Specification (SRS)

A formal document describing what the software must do, how it must perform, and constraints.

Typical Structure (IEEE 830 Standard):

1. Introduction (Purpose, Scope, Definitions).

2. Overall Description (Product perspective, user characteristics, constraints, assumptions).

3. Specific Requirements (Functional, Non-functional, Interface).

4. Appendices (Supporting info, analysis models).

Parts of SRS:

• Functional Requirements: System behaviors (e.g., "The system shall authenticate users").

• Non-Functional Requirements:

  • Performance: "Response time < 2 sec."

  • Security: "Data encryption AES-256."

  • Usability: "Training time < 1 hour."

• Interface Requirements: UI, hardware, software, communication.

• Constraints: Budget, technology, regulatory.

• Assumptions and Dependencies: Conditions presumed true.

Characteristics of a Good SRS:

[!TIP]

Exam Key: For "characteristics of a good SRS," list and explain each briefly. "Verifiable" and "Traceable" are heavily emphasized in past papers. Always give examples (e.g., for verifiable, convert "user-friendly" to measurable "task completion time < 30s").

Quick Reference Table: SRS vs. Other Documents

[!NOTE]

RGPV Past Pattern: Questions often combine topics – e.g., "How does feasibility study affect SRS?" Link explicitly: feasibility outcomes (constraints, risks) become explicit parts (Constraints section) and implicit influences (prioritization, scope) in the SRS.