Software Engineering Chapter 2: Requirements Engineering

Software Engineering - Chapter 2: Requirements Engineering

• Requirements Engineering Process: This is a phased approach to gathering, analyzing, and documenting software requirements. It involves several key steps: Feasibility Study, Requirements Elicitation, Requirements Specification, Requirements Verification and Validation, and Requirements Management.

Feasibility Study

• Feasibility Assessment: Evaluates the technical, economic, legal, operational, and schedule feasibility of a project. Involves a cost-benefit analysis.

• Technical Feasibility: Examines technical resources, skills, and current technology.

• Operational Feasibility: Assesses operational aspects of the project, compatibility with existing systems, and training needs.

• Economic Feasibility: Analyzes cost and benefits of the project.

• Legal Feasibility: Determines if the project complies with legal requirements.

• Schedule Feasibility: Checks if the project can be completed within a realistic timeframe.

• Output: The feasibility study determines whether to continue with the project.

Requirements Elicitation

• Gathering Requirements: A cyclic process of collecting and analyzing stakeholder requirements for a software system.

• Goal: To understand the problem the software will solve and stakeholder expectations.

• First Step: Identifying key stakeholders. Users are typically the most crucial stakeholders.

• Techniques: Common techniques include:

  • Interviews: One-on-one discussions with stakeholders.
  • Surveys: Questionnaires distributed to stakeholders.
  • Focus Groups: Small groups of stakeholders discuss requirements.
  • Observation: Observing stakeholders' work to understand their needs.

Requirements Specification

• Requirement Specification Document (SRS): A formal document that meticulously and consistently details the requirements.

• Description: Includes functional requirements (FRs), non-functional requirements (NFRs) (also called software quality requirements), user interfaces (hardware, software, external), and other important features.

• Goal: This document is a contract between the customer and developers. It's used by the customer to validate the final system and is critical for developers to understand and implement the system properly.

• SRS Structure: A typical SRS contains sections such as introduction, overall description (including details of user and system interfaces, software and hardware needs, and constraints), user characteristics, system features and requirements, and delivery for approval. Specific details will vary depending on the project specifics.

Understanding Requirements

• Business Requirements (BRD): This document outlines goals and requirements from a business perspective, encompassing the business, users and other stakeholders.
• User Requirements: These are statements in natural language or diagrams delineating services, operations, and constraints.
• System/Software Requirements: This document expands upon business and user requirements, defining specific functions and specifications, and serves as a contract between developers and the customer.

Requirements Verification and Validation (V&V)

• Verification: This process ensures the requirements are correctly specified and error-free.
• Validation: This process ensures the requirements meet the needs and expectations of stakeholders.
• Importance of V&V: Ensuring the software system meets requirements, stays within budget, and adheres to quality standards.

Requirements Management

• Importance: Essential for tracking and controlling changes to requirements and communication with stakeholders to prevent scope creep and ensure alignment.
• Activities: Includes tracking and controlling changes to requirements from customers, version control (maintaining different versions of the SRS), traceability (linking requirements to design, testing, and validation), communication which is critical for keeping everybody aligned and on the same page, and monitoring and reporting (monitoring project progress and reporting on requirements status).

Benefits of Requirements Engineering

• Stakeholder Alignment: Ensures the software meets stakeholder needs.
• Early Problem Detection: Identifies potential problems before design and development begins.
• Cost-Effectiveness: Ensures efficient and cost-effective software development.
• Project Success: Leads to the delivery of on-time and within-budget software.

Challenges of Requirements Engineering

• Time and Complexity: Gathering requirements can be time-consuming and costly, especially with complex projects.
• Stakeholder Conflicts: Conflicts between stakeholders can arise and be difficult to reconcile.
• Understanding and Agreement: Ensuring all stakeholders understand and accept the requirements can be a challenge.