Software Engineering Chapter 4: Capturing Requirements

Software Engineering - Chapter 4: Capturing Requirements

• Chapter 4 Objectives:
  • Elicit requirements from customers
  • Model requirements
  • Review requirements for quality
  • Document requirements for design and test teams

The Requirement Process

• Customer Requests:
  • New system
  • Replacing an existing system
  • Changing processes (e.g., manual to automatic)
  • Examples include paying bills
• Requirements Definition:
  • An expression of desired behavior
  • Deals with objects, entities, states, and functions
• Example Scenario: Building a system for generating paychecks, including issuing checks bi-weekly, direct deposit options (based on salary levels), and allowing access from multiple locations.

The Requirement Process (Continued)

• Focus on Customer Needs: Requirements should prioritize what the customer needs, not how the system will be implemented.
• Key Entity Identification: Identify key entities, such as "employee."
• Limiting Entities: Set limitations or constraints on entities, such as an employee being paid for a maximum of 40 hours per week.
• Defining Relationships: Define relationships among entities, such as "employee X is supervised by employee Y." This impact how employee Y can authorize changes to employee X's salary.

Why are Requirements Important?

• Project Failure Factors: Incomplete requirements, lack of user involvement, unrealistic expectations, changing requirements/specifications, lack of planning, system no longer needed.
• Cost of Requirements Errors: Errors in requirements definition are increasingly costly. For example: $1 error in definition phase translates to $5 in Design, $10 in coding, $20 in unit tests, and up to $200 after delivery.

Process for Capturing Requirements

• Analyst Role: Requirement analyst or system analyst performs the tasks.
• Elicitation Process: Communicate with customers to understand requirements, asking questions, examining existing systems, and creating models/prototypes.
• Modeling/Prototyping: Capturing requirements in models or prototypes for better comprehension.
• Specification Phase: Define specific aspects of the required behavior, which systems must implement.
• Validation: Verify that the specification meets customer expectations.
• Revision: Analysis and validation may reveal problems or omissions, necessitating revision of models and specifications accordingly.

Process for Capturing Requirements (Summary)

• Software Requirements Specification (SRS): The final deliverable, used to communicate requirements among developers, designers, testers, and maintainers.
• Stages: Elicitation, Analysis, Specification, and Validation.

Requirements Elicitation

• Customer Understanding: Customers may not fully understand their needs or problems.
• Stakeholder Collaboration: Discussion among all stakeholders involved in the system is critical to establish agreement on requirements. This consensus is crucial, as disagreements can cripple project success.

Requirement Stakeholders

• Clients: Pay for the software development
• Customers: Buy the software
• Users: Use the software
• Domain experts: Possess in-depth knowledge of the problem domain
• Market Researchers: Understand market trends and potential customers
• Lawyers/Auditors: Address legal or safety aspects
• Software Engineers: Provide technical insights

Means of Eliciting Requirements

• Stakeholder Interviews: Gather information directly
• Review Existing Documentation: Leverage available materials
• Observe Current Systems: Learn from existing processes and procedures
• Apprenticing with Users: Gain practical insight to understand real-world task requirements.
• Group Interviews/Brainstorming: Encourage diverse ideas and perspectives.

Means of Eliciting Requirements (Continued)

• Use of Templates/Models: Models and templates help structure the elicitation process.

Types of Requirements

• Functional Requirements: Describe the system's required behaviors in terms of its activities and how entities change.
• Quality Requirements: Describe the qualities the system must have (e.g., fast response time, ease of use, high reliability).
• Design Constraints: Address architectural or design choices (e.g., platform selection).

Resolving Conflicts

• Multiple Stakeholder Needs: Different stakeholders may have differing requirements.
• Prioritization: Critical requirements are categorized as "essential," "desirable," or "optional."
• Example: A credit billing system might have essential, desirable, and optional requirements. Essential might be the ability to list charges, desirable might be separating by purchase type, and optional might be printing credits in black and debits in red.

Kinds of Requirements Documents

• Requirements Definition: Comprehensive list of everything the customer needs. Focuses on the current system and environment.
• Requirements Specification: Restates requirements from the perspective of the system itself; the specifications will focus on the interface between the system and its environment. This is the technical specification intended for software developers or engineers.

Characteristics of Requirements

• Characteristics of High-Quality Requirements: Requirements are correct, consistent, unambiguous, complete, feasible, relevant, testable, and traceable.

Modeling Notations

• Standard Notations: Using standard modeling notations facilitates communication and collaboration in software development.
• Modeling examples: Entity-Relationship diagrams, and Data-Flow diagrams.

Entity Relationship Diagrams (ER Diagrams)

• Core Constructs: Entities, attributes, and relationships.
• Representation: Entities as rectangles, relationships as lines connecting entities, and attributes as annotations on entities.
• Usefulness: ER diagrams help understand and model problem domains, showing the relationships between entities.

Entity-Relationship Diagrams (Continued)

• Turnstile Example: An example ER diagram to illustrate the concept using a turnstile system, with entities for visitors, coin values, and coin slots.

Data-Flow Diagrams (DFDs)

• Functionality Representation: DFDs show the flow of data between different system components.
• Components: Processes (represented by bubbles), data stores, actors, and data flows (represented by arrows).
• Example: A high-level data-flow diagram for a library system, showing interactions between customers, accounting, inventory, and other related parts of the system.

Dive deep into Chapter 4 of Software Engineering, focusing on the essential processes for capturing requirements. Learn how to elicit, model, and document requirements to ensure they meet customer needs. This chapter emphasizes the importance of understanding user requests and accurately defining the desired behavior of systems.