Requirements Engineering

Summary

• Definitions?
• Identifying Purpose
• Completeness and Pertinence
• Funcational vs Non-Functional
• User vs System
• Requirement Origins
• Elicitation Process
  • Traditional Techniques
  • Other Techniques
• Modeling Requirements
• Analyzing Requirements
• Requirements Prioritization
• Requirements Engineering Process
• Software Requirements Specification

Definitions?

Requirements Engineering is the process of establishing the services that the customer requires from the software system, and compares that to the constraints under which the system operates.

Focuses on what, not how

Software is an abstract description of a set of computations that becomes concrete only when we run it on hardware and in the context of some human activity.

Software Intensive Systems := Software + Hardware + Context

We normally take hardware and context for granted, but they need to be explicitly considered.

Software Quality is a function of both the software and its purpose (Fitness for Purpose)

Identifying Purpose

Extremely hard

• Sheer complexity of the purpose
• People don’t know what they want
• Requirements can change
• Many stakeholders can have different requirements

Completeness and Pertinence

It is difficult to get a grasp of the full picture of requirements.

Pertinence pertains to the relevance of the requirements

• This leads to bloat

Funcational vs Non-Functional

Functional Requirements have to do with the function of the system.

• “The elevator shall take people to the floor they select”

Non-Functional Requirements relate to a system’s qualities

• Accuracy
• Security
• Performance

NFR typically don’t have clear criteria

NFR should strive for verifiability

• Not “Elevator should be fast”
• Instead “Elevator should reach the floor in less than 30s”

User vs System

User Requirements are written for customers

• often natural language
• non-technical

System Requirements are written for developers

• detailed func and non-func reqs
• clearly and more rigorously specified

Requirement Origins

Requirements can come from multilple places

• Stakeholders
• Application Domain
  • Banks, Medical, etc
• Documentation

Elicitation Process

Domain knowledge is often thinly spread and distributed

Knowledge is often tacit

Observability is often limited

Collected information is often biased

• Consciously or Subconciously

Traditional Techniques

• Background Reading
  • Reading random documents
  • Good first step
• Hard Data and Samples
  • Run experiments/collect data
• Interviews
  • Simply talk to people
• Surveys
  • Quickly collect info from large number of people
• Meetings
  • Good for summarizations of data
  • Should have clear intentions/agend

Other Techniques

• Collaborative techniques
  • Brainstorming
• Socia approaches
  • Ethnographic techniques
• Cognitive techniques

Modeling Requirements

Decide what and how to model

Examples:

• Modeling enterprises
  • goals and objectives
  • org structure
  • task and deps
  • agents, roles, intentionality
• Modeling info and behaviors
  • information structure
  • behavioral view
    • scenarios and use cases
    • state machine models
    • sequence diagrams
    • information flow
  • time/sequencing requirements
• Modeling system qualities
  • Non-Functional Properties

Analyzing Requirements

• Verification
  • Completeness and Pertinence
• Validation
  • Do the requirements satisfy what the stakeholders want
• Risk Analysis
  • Find risks in development

Requirements Prioritization

Limited resources lead to need to prioritize

• Mandatory
• Nice to Have
• Superflous

Requirements Engineering Process

Software Requirements Specification

SRS is a way to communicate requirements to others

Different projects require differen specs

IEEE defines a standard

Simplified standard has three sections:

1. Introduction
2. User Reqs
3. System Reqs

Requirements should be

• simple
• testable
• organized
• numbered (traceable)