This session provides an introduction to requirements engineering, focusing on the roles, processes, and methodologies involved in business analysis.

Core Concepts

  • Requirements: Defined as a usable representation of a need, such as a feature, function, constraint, or condition, which must provide value.
  • Levels of Requirements:
    • Business Requirements: High-level needs aligned with organizational objectives.
    • Stakeholder Requirements: Needs from the user’s perspective, including goals and inputs/outputs.
    • Solution Requirements: Technical needs split into functional (what the system does) and non-functional (how the system operates, such as performance, security, and scalability).
    • Transitional Requirements: Temporary requirements needed for implementation, such as data migration and training.

Requirements Engineering Process

 

The framework for handling requirements throughout the project lifecycle includes:

  1. Elicitation: Gathering requirements from stakeholders (e.g., via interviews, workshops, surveys, or shadowing).
  2. Analysis: Reviewing requirements to remove errors, resolve conflicts, and establish priorities.
  3. Documentation: Defining requirements using narrative or diagrams.
  4. Validation: Reviewing requirements to ensure they are defined at the correct quality level and meet stakeholder needs.
  5. Management: Tracking requirements and managing changes throughout the project lifecycle.

Key Actors

  • Business Representatives: Includes the Project Sponsor (who provides funds and rules on conflicts), Product Owner (who manages the backlog and maximizes value), Subject Matter Experts (SMEs), and business staff.
  • Project Team: Includes the Project Manager (responsible for timelines, cost, and quality), Business Analyst (responsible for elicitation and documentation), Developers (who build the solution), and Software Testers (who validate against acceptance criteria).

Challenges and Characteristics

  • Common Problems: Incomplete, ambiguous, conflicting, unrealistic, or unmanaged requirements, as well as poor communication and over-engineering.
  • Characteristics of Good Requirements: They should be correct, necessary, prioritized, owned, understandable, and testable.

Agile vs. Waterfall

  • Waterfall: Tends to be more document-heavy and policy-driven.
  • Agile: Focuses on user stories, which are often grouped into “Epics.” User stories should follow the “INVEST” criteria: Independent, Negotiable, Valuable, Estimable, Small, and Testable.