3.1 Requirement Engineering Process
Requirement Engineering is the disciplined process of discovering, analyzing, documenting, validating, and managing the functional and behavioral services that a software system must provide.
Figure 3.1: The systematic requirement engineering pipeline transforms stakeholder needs into a validated SRS document.
3.2 Types of Requirements: Functional, Non-Functional & Domain
Requirements are categorized based on their level of abstraction and operational focus:
- Functional Requirements (FRs): Statements of concrete system services, functions, and behavioral calculations (e.g. "The system shall authenticate the user using OAuth 2.0", "The system shall generate a monthly payroll statement in PDF format").
- Non-Functional Requirements (NFRs / Quality Attributes): Constraints on how the system performs its services. Examples include performance (latency < 200ms), scalability (100k concurrent users), reliability (99.999% uptime), security (AES-256 encryption at rest), and maintainability.
- Domain Requirements: Requirements that originate directly from the operational domain's regulations or physics (e.g. medical HIPAA compliance, banking double-entry bookkeeping rules).
3.3 Feasibility Study
A Feasibility Study is an early investigative analysis determining whether the proposed project is economically, technically, and operationally viable before capital is committed.
- Technical Feasibility: Does the organization possess or can it acquire the required hardware, software stacks, algorithms, and developer skill sets?
- Economic Feasibility (Cost-Benefit Analysis): Will the Return on Investment (ROI) justify development costs? Compares operational savings against CAPEX/OPEX.
- Operational Feasibility: Will the target end-users accept the software, and will it integrate smoothly into current organizational workflows?
- Schedule Feasibility: Can the software be built and deployed prior to market opportunities closing or regulatory deadlines expiring?
- Legal Feasibility: Does the solution comply with copyright laws, GDPR data privacy, patents, and labor contracts?
3.4 Software Requirement Specification (SRS)
The SRS is the definitive legal and technical agreement between the client and development organization. Standardized under IEEE 830 / ISO/IEC/IEEE 29148, it establishes what developers commit to building.
Key Characteristics of a Superior SRS
- Correct & Complete: Covers all essential functional features and environmental scenarios.
- Unambiguous: Written so that every requirement has only a single logical interpretation.
- Verifiable / Testable: Every stated requirement can be proven true or false via quantifiable tests.
- Consistent: Contains no contradictory requirements (e.g., specifying sub-millisecond response while requiring deep disk journaling on low-power chips).
- Traceable: Each requirement has a unique ID traced backward to stakeholder needs and forward to code modules and test cases.
3.5 Data Flow Diagram (DFD)
A Data Flow Diagram (DFD) is a graphical representation of the information flow and data transformations throughout a software system. DFDs use four canonical symbols:
- Circle / Oval: Process (transforms incoming data streams into outgoing data streams).
- Rectangle: External Entity (source or sink of data outside the system boundary).
- Open-Ended Rectangle / Parallel Lines: Data Store (files, databases, tables).
- Arrow: Data Flow (path along which data items travel).
Figure 3.2: DFD Level-0 depicting processes (circles), external entities (rectangles), data stores, and data flows.
