REQUIREMENT ANALYSIS
Adapted from Steve Easterbrook, Department of Computer Science, University of Toronto
NGURAH AGUS SANJAYA ER, S.KOM, M.KOM
[email protected] 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 3 SPECIFIC REQUIREMENTS
Specifications (SRS) 3.1 External Interface Requirements
3.1.1 User Interfaces
Cover Page 3.1.2 Hardware Interfaces
Revisions Page 3.1.3 Software Interfaces
3.1.4 Communications Protocols
Table of Contents 3.1.5 Memory Constraints
1 INTRODUCTION 3.1.6 Operation
1.1 Product Overview 3.1.7 Product function
1.2 Purpose 3.1.8 Assumption and Dependency
1.3 Scope 3.2 Software Product Features
1.4 Reference 3.3 Software System Attributes
1.5 Definition And Abbreviation 3.3.1 Reliability
3.3.2 Availability
2 OVERALL DESCRIPTION 3.3.3 Security
2.1 Product Perspective 3.3.4 Maintainability
2.2 Product Functions 3.3.5 Portability
2.3 User Characteristics 3.3.6 Performance
2.4 General Constraints 3.4 Database Requirements
2.5 Assumptions and Dependencies 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
