REQUIREMENT ANALYSIS

Adapted from Steve Easterbrook, Department of Computer Science, University of Toronto

NGURAH AGUS SANJAYA ER, S.KOM, M.KOM

agus.sanjaya@cs.unud.ac.id
Overview

Basic requirement analysis

Requirements in the software life cycle
The essential requirement process
What is a requirement?
What vs How
Machine domain vs Application domain
Implementation bias
Non-functional requirements
Notations, techniques and methods
Elicitation techniques
Modeling methods
Basics of Requirements Engineering

What are the ‘essential’ process?

Must understand the problem
Can use some data gathering techniques to elicit requirements
Example: interviews, questionnaires, focus groups, prototyping, observation
Model and analyze the problem
Can use some modeling method(s)
Example: structured analysis, object oriented analysis, formal analysis
Attain agreement on the nature of the problem
Validation
Conflict resolution, negotiation
Communicate
Specifications, documentations, review meetings
Manage changes as the problem evolves
Requirements continue to evolve throughout the development
Requirements management  must maintain the agreement
Is RE the Weakest Link?

Requirements engineering is very hard to do:

Analysis problems have ill-defined boundaries (open-ended)
Found in organizational context  prone to produce conflicts
Solutions to analysis problems are artificial
Analysis problems are dynamic
Tackling analysis requires interdisciplinary knowledge and skill
Requirements engineering is important:
Engineering is about developing solutions to problems
A good solution  engineer fully understand the problem
Errors cost more the longer they go undetected
Cost is 100 times greater in maintenance phase than in the requirement phase
Experience from failed software development projects
Failure to understand and manage requirements  biggest cause of cost and schedule
over-runs
What vs How

Requirements should specify ‘what’ not ‘how’

It is not easy distinguish
What does a car do?
What does a web browser do?
‘What’ refers to a system’s purpose
It is external to the system
It is a property of the application domain
‘How’ refers to a system’s structured and behavior
It is internal to the system
It is a property of the machine domain

Requirements only exist in the application domain

It is essential to distinguish between application domain and machine domain for good
requirements engineering
Need to draw a boundary around the application domain
Which things are the part of the problem you are analyzing and which are not
Implementation Bias

Is the inclusion of requirements that have no basis in the application domain

i.e mixing some ‘how’ into the requirements
Examples:
The dictionary shall be stored in has table
The patient records shall be stored in a relational database
But sometimes it’s not so clear
The software shall be written in FORTRAN
The software shall respond to all requests within 5 seconds
The software shall be composed of the following 23 modules …
Instead of what and how, ask:
Is this requirement only a property of the machine domain? If yes  implementation bias
Or is there some application domain phenomena that justifies it?
Functional vs Non-functional

Functional requirements
Fundamental functions of the system  uses cases that describe all interactions that the
users will have with the software
Mapping of inputs to outputs
Control sequencing
Timing of functions
Handling of exceptional situations
Non-functional requirements
requirements which impose constraints on the design or implementation
Constraints/obligation (non-negotiable)  compatibility with legacy systems,
compliance with interface standards, data formats, etc.
Quality requirements (soft-goals)  security, safety, usability, performance, portability
Software requirements specifications (SRS)  used to describe functional
and non-functional requirements
General Outline of SRS
Software Requirements
Specifications (SRS)
Cover Page
Revisions Page
Table of Contents
1 INTRODUCTION
1.1 Product Overview
1.2 Purpose
1.3 Scope
1.4 Reference
1.5 Definition And Abbreviation
2 OVERALL DESCRIPTION
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions and Dependencies
3 SPECIFIC REQUIREMENTS
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Protocols
3.1.5 Memory Constraints
3.1.6 Operation
3.1.7 Product function
3.1.8 Assumption and Dependency
3.2 Software Product Features
3.3 Software System Attributes
3.3.1 Reliability
3.3.2 Availability
3.3.3 Security
3.3.4 Maintainability
3.3.5 Portability
3.3.6 Performance
3.4 Database Requirements
4 ADDITIONAL MATERIALS
Elicitation Techniques

Traditional approaches
Introspection
Interview / survey
Group elicitation
Observational approaches
Protocol analysis
Participant observation
Model-based approaches
Goal-based  hierarchies or stakeholder’s goals
Scenarios  characterizations of the ways in which the system is used
Uses case  specific instances of interaction with the system
Exploratory approaches
Prototyping
Modeling: Notations vs Methods
 Definitions  Example method:
 Notations: a systematic way of  Structured analysis
presenting something  may be  SADT
linguistic (textual) or graphical  SASD
(diagrams)  Information Engineering
 A method provides:  JSD
 a set of notations  Entity-relationship approach
 techniques for using those  Object-oriented analysis
notations  Coad-Yourdon
 heuristic to provide guidance  OMT
 Notation or method?  UML
 some notations have been  Formal methods
adopted by a number of different  SCR
methods  RSML
 some ‘methods’ are really just
notations
 Tools usually support a single
method