Requirements Engineering

Requirements Engineering

Requirements engineering is the process of defining, documenting, and maintaining software requirements. Good requirements are the foundation of successful software projects. Without them, you're building without a blueprint.

Types of Requirements

  +--------------------------------------------------+
  |              REQUIREMENTS TYPES                  |
  +--------------------------------------------------+
  |                                                  |
  |   Functional Requirements                        |
  |   - What the system MUST DO                      |
  |   - Examples:                                    |
  |     * User can login with email/password         |
  |     * System generates monthly reports           |
  |     * Admin can manage user accounts             |
  |                                                  |
  |   Non-Functional Requirements                   |
  |   - HOW the system performs                      |
  |   - Examples:                                    |
  |     * Page loads in under 2 seconds              |
  |     * System handles 10,000 concurrent users     |
  |     * Data encrypted at rest                     |
  |                                                  |
  |   Constraints                                    |
  |   - Limitations and restrictions                 |
  |   - Examples:                                    |
  |     * Must use existing database                 |
  |     * Budget cannot exceed $50,000               |
  |     * Must comply with GDPR                      |
  |                                                  |
  +--------------------------------------------------+

Gathering Requirements

Requirements come from many sources. Stakeholders, users, business analysts, and technical constraints all contribute. The key is to ask the right questions and validate assumptions.

Techniques:

• Interviews with stakeholders
• Surveys and questionnaires
• Workshops and focus groups
• Observation of existing workflows
• Analysis of competitor systems
• Review of existing documentation

Requirement Quality Criteria (SMART)

  Good Requirements are:
  ======================

  S - Specific        : Clear and unambiguous
                       "User enters email to login"
                       NOT "User can login somehow"

  M - Measurable      : Can be tested and verified
                       "Response time < 2 seconds"
                       NOT "System is fast"

  A - Achievable      : Realistic given constraints
                       "Support 1,000 users in Phase 1"
                       NOT "Support 1 billion users on day one"

  R - Relevant        : Aligns with project goals
                       "Integrate with payment gateway"
                       NOT "Add dancing hamster animation"

  T - Traceable       : Can be tracked to design/code/test
                       Each requirement has a unique ID
                       Linked to test cases

Common Pitfalls

• Ambiguous language ("the system should be fast")
• Missing non-functional requirements
• Scope creep from uncontrolled changes
• Not validating with actual users
• Assuming rather than asking

Key Takeaways

• Requirements engineering prevents costly rework later
• Distinguish between functional and non-functional requirements
• Use SMART criteria for writing good requirements
• Always validate requirements with stakeholders