Requirements Engineering Notes

The Importance of Requirements

  • Requirements definition is a stage where failure commonly occurs.
  • Getting requirements right is crucial for project success.

Types of Requirements

  • Functional: What the system should do.
  • Non-functional: Memory size, response time, etc.
  • Data: What data needs to be stored and how.
  • Environment/Context of Use: Physical (e.g., dusty, noisy) and social (e.g., file sharing).
  • Users: Characteristics, ability, background; system use (novice, expert, casual, frequent).
  • Usability: Learnability, throughput, flexibility, attitude.

Data Gathering Techniques

  • Questionnaires: For specific information from a large group; can be quantitative or qualitative.
  • Interviews: Structured, unstructured, or semi-structured; good for exploring issues but time-consuming.
  • Workshops/Focus Groups: Group interviews to gain consensus.
  • Naturalistic Observation: Observing stakeholders in their tasks; time-consuming but insightful.
  • Studying Documentation: Useful for understanding rules and regulations; doesn't require stakeholder time.

Problems with Data Gathering

  • Identifying and involving stakeholders (users, managers, developers).
  • Requirements management: version control, ownership.
  • Communication challenges within teams and with users.
  • Domain knowledge is distributed and implicit.
  • Availability of key people.
  • Political problems, stakeholder dominance and economic changes.

Basic Guidelines for Requirements Gathering

  • Focus on stakeholder needs.
  • Involve all stakeholder groups and multiple representatives.
  • Use a combination of data gathering techniques.
  • Support the process with prototypes and task descriptions.
  • Run a pilot session and consider data recording methods.

Data Interpretation and Analysis

  • Start soon after data gathering.
  • Initial interpretation before deeper analysis.
  • Use different approaches (e.g., class diagrams, entity-relationship diagrams).

Task Descriptions

  • Scenarios: Informal, narrative stories.
  • Use Cases: Assume interaction with a system and detailed understanding.
  • Essential Use Cases: Abstract away from details.

Task Analysis

  • Used to investigate existing situations.
  • Focus on what people are trying to achieve and why.
  • Common technique: Hierarchical Task Analysis (HTA).

Hierarchical Task Analysis (HTA)

  • Involves breaking tasks into subtasks and plans.

  • Focuses on physical and observable actions.

  • Starts with a user goal and identifies main tasks and sub-tasks.

    Example HTA: Borrowing a book\text{Example HTA: Borrowing a book}

  • 0. In order to borrow a book from the library

  • 1. Go to the library

  • 2. Find the required book

    • 2.1 Access library catalogue
    • 2.2 Access the search screen
    • 2.3 Enter search criteria
    • 2.4 Identify required book
    • 2.5 Note location

  • 3. Go to correct shelf and retrieve book

  • 4. Take book to checkout counter

    Plan 0: do 1-3-4. If book isn’t on the shelf expected, do 2-3-4.\text{Plan 0: do 1-3-4. If book isn’t on the shelf expected, do 2-3-4.}
    Plan 2: do 2.1-2.4-2.5. If book not identified do 2.2-2.3-2.4.\text{Plan 2: do 2.1-2.4-2.5. If book not identified do 2.2-2.3-2.4.}