Skip to content

Introduction

Requirements: things that people or organizations require, (some can be optional)

Engineering: systematic, reliable processes

Why Requirements Engineering is Important

  1. Poor requirement engineering leads to heavy economic loss.
  2. In safety-critic systems, poorly defined requirements are extremely dangerous.

How to Deal with System Failure

Solution 1: SE methods, (a more agile method)

  • Build and deploy incrementally
  • Prototype

Solution 2: More requirements engineering

  • Spend more time to understand the problem, user, environment...
  • Capture Knowledge in a structured and understandable way

Best solution can be a mixture.

Requirements Concepts

User and Stakeholder

User: People who directly use the system.

Stakeholders: Anyone who will be positively or negatively affected by system.

Users are stakeholders.

Requirements and Design

Requirements: describe what the system should do. not describe how the system will do these things.

Design: concerns the internal workings of the solution system.

Requirements is in technically neutral way, in order to avoid influencing the design of solution.

For developers, design information in requirements is constraint.

Functional and Non-functional Requirements

Functional requirements: The things the system must do.

Non-functional requirements: The qualities the product must have.

What is Requirements Engineering

It is a set of systematic techniques, models, structures to help you think about the problem you will solve with technology.

It can be very simple or very complex.

Requirements Creativity

Try to come up with both useful and novel ideas.

Requirements Scoping

Problems are usually boundless. We need to focus on a reasonable part of the problem and set of users.

Set boundaries

Make sure

  • to solve the core problem
  • the system is really the best way to solve the core problem
  • to pick a reasonable scope

minimal viable product

Requirements Modeling

Many types of requirements models.

UML:

  • class diagram: entities in the world
  • activity diagram: user activity flows
  • sequence diagram: user sequence of action
  • state diagram: states of entities in the world

Non-UML: context diagrams, goal models.

Context Diagrams

Entities (actors)

Relationships

Goal Models

i* Language

Agent, Role

Is-a relationship

participate-in relationship

Requirements Elicitation

From users/stakeholders

Can be difficult: domain knowledge, bias...

Known and Unknown Unknowns

Knowns Unknowns
Known Things we are aware of and understand Things we are aware of but don't understand
Unknown Things we understand but are not aware of Things we are neither aware or nor understand

The requirements elicitation deals with Known Unknowns and Unknown Unknowns.

Elicitation Techniques

Traditional ways: Documentation, Data Sampling, Interviews, Surveys/Questionnaires...

Collaborative ways: Focus groups, Prototyping

Contextual ways: participant observation

Cognitive ways: Think aloud protocol