软件工程：Software Requirement Specification

Summary of “Software Requirements: Introduction”

1. Core Challenges in Requirements Engineering

• Key Issue: Understanding the problem the system must solve, often derived from customer/end-user needs.
• Challenges:
  • Developers may misunderstand the business problem, leading to incorrect solutions.
  • Customers/users may not clearly articulate their needs (especially problematic in predictive models like Waterfall).
  • Developers must align software with end-users’ workflows to ensure practicality.

2. Drivers of Requirements

• Custom Software (Project-Based):
  • Requirements driven by specific clients (e.g., government, enterprise tools).
  • Contractual obligations dictate functionality and delivery timelines.
  • Ownership transfers to the client post-delivery.
• Software Products:
  • Requirements originate from the company’s vision/opportunity (e.g., apps, productivity tools).
  • Developers prioritize features and constraints without a specific client’s contractual demands.
  • Continuous evolution: Features can be added/removed post-release.

3. Types of Requirements Information

• Business Requirements: High-level organizational objectives (e.g., “Increase customer satisfaction”).
• Business Rules: Policies/constraints (e.g., pricing policies). Stored in a Business Rules Catalogue, not part of the SRS itself.
• User Requirements: Tasks users must perform or desired attributes (e.g., “Users want to check in online”).
• Functional Requirements: Specific behaviors the system must perform (e.g., “The system shall calculate fuel quantity”).
• Features: Bundles of related functional requirements (e.g., “User Authentication Feature”).
• System Requirements: Top-level/system-wide requirements (e.g., integration with hardware).
• Non-Functional Requirements: Properties like performance, security, usability (e.g., “Authorization must take ≤2 seconds”).
• External Interface Requirements: Connections to users, systems, or hardware (e.g., “JSON format for data exchange”).
• Constraints: Restrictions on development (e.g., “Use open-source libraries only”).

4. Business Rules Management

• Documentation: Rules are recorded in tables with:
  • Rule ID, Rule Description, Volatility (how often they change), and Source (e.g., company policy).
  • Example: Delivery pricing rules for an e-commerce system.
• Impact: Influence functional/non-functional requirements (e.g., permissions, UX design).

5. Software Requirements Specification (SRS)

• Purpose: Formal document outlining all functional and non-functional requirements.
• Structure:
  1. Introduction: Purpose, scope, conventions.
  2. Overall Description: Product context, user classes, constraints.
  3. System Features: Detailed functional requirements (e.g., “The system shall…”).
  4. Data Requirements: Logical models, reports, data retention policies.
  5. External Interfaces: User, software, hardware, and communication interfaces.
  6. Quality Attributes: Usability, performance, security, safety.
  7. Appendices: Glossary, analysis models.
• Formality: Varies by system criticality (e.g., strict for avionics vs. informal for web apps).
• Example: Flight Management System (FMS) requirements trace from system to low-level software specs (e.g., fuel quantity display in pounds/kilograms).

6. Requirements Traceability

• Critical in Safety-Critical Systems (e.g., aviation):
  • Requirements must be bi-directionally traceable (e.g., from system to code).
  • Example: FMS fuel quantity requirements linked to sensor polling intervals and data validity checks.
• DO-178C Compliance: Mandates traceability for airborne software.

7. Agile Requirements Management

• Alternatives to Traditional SRS:
  • Vision and Scope Document: High-level goals and constraints.
  • Product Backlog: Prioritized user stories/use cases with acceptance criteria.
  • Dynamic Updates: Requirements evolve iteratively (e.g., user stories refined during sprints).
  • Working Software: Focus on delivering increments over exhaustive documentation.
• Example: User stories for a flight check-in system (e.g., “As a passenger, I want to print boarding passes after check-in”).

8. Key Takeaways

• Requirement Types: Differentiate between business rules, user needs, functional/non-functional requirements.
• Documentation: Formal SRS for critical systems; agile backlogs for product development.
• Traceability: Essential for compliance and defect prevention in safety-critical domains.
• Agile Adaptation: Prioritize collaboration, iterative delivery, and flexibility over rigid planning.

This summary captures the document’s focus on understanding requirements, their classification, documentation practices, and the shift toward agile methodologies for modern software development.