Skip to main content

Week 3 - Requirement Engineering

A process to find out and structure the functional and non-functional requirements

RE (Requirement Engineering)

Common Mistakes in RE​

  • Noise: does not add relevant information

  • Silence: feature in the problem not mentioned in the specification

  • Over-specification: talk about the solution rather than the problem

  • Contradictions: inconsistent description

  • Ambiguity: unclear

  • Forward references: especially cumbersome in long documents

  • Wishful thinking: features that cannot realistically be realized

Four major steps in RE process​

  1. Elicitation 啟發: understanding problem

  2. Specification: describing problem

  3. Validation: nature of problem

  4. Negotiation: boundaries of problem

Four positions of analyst in RE​

  • Functional (Objective, order)

  • Social-relativism (subjective, order)

  • Radical-structuralism (objective, conflict)

  • Neohumanism (subjective, conflict)

Will it quiz? I don't know

Five types of requirements Elicitation activities​

  1. Understanding the application domain

  2. Identifying the sources of requirements

  3. Analyzing the stakeholders

  4. Selecting the techniques, approaches, and tools to use

  5. Eliciting the requirements from stakeholders and other sources

Requirements Elicitation Techniques​

  • Interview

  • Brainstorming

  • Task Analysis

  • Scenario-Based Analysis

  • Form analysis

  • Focus Group and Facilitated Workshop

  • Mind mapping, group story telling, user stories

Interview​

  • Unstructured

  • Structured

    • Predetermined set of questions

  • Semi-structured

Brainstorming​

List of ideas iteratively toward a particular topic

Task Analysis​

Top-down approach

High-level tasks decomposed into subtasks

Scenario-Based Analysis​

User-oriented perspective

Form analysis​

Figure out items that are certain or have variety, and the time

I don't really know

Focus Group and Facilitated Workshop​

Focus group​

Small and diverse group of people

Structuring requirements​

Hierarchical

Link requirements to stakeholders

Prioritizing Requirements​

MoSCoW Method​

Must haves: mandatory requirements

Should haves: important but not mandatory

Could haves: if time allows

Won’t haves: not today (may be tomorrow)