You are on page 1of 30

REKAYASA

PERANGKAT LUNAK
Semester Genap 2013 - 2014
Analysis Concepts and Principles
Beni Suranto, S.T., M.SoftEng
Outline
Software requirement analysis
Source, stakeholders, techniques
Analysis principles
Prototyping
Requirement specification
Review
Definition
Engineering process
What is the problem to be solved?
What are the characteristics of the solution?
How will the solution be realised?
How will the solution be constructed?
What approach will be used to uncover errors
that were made in the design and construction of
the solution?
How will the solution be supported over
long term?
Development
Change
Analysis
Design
Code
Test
Maintenance
Definition
Change
Development
Software requirements
A software requirement
a property which must be exhibited by software
developed or adapted to solve a particular
problem.
Product vs. process requirements
Product
requirements on software
The software shall verify that a student meets all
prerequisites before he/she registers for a course.
Process
requirements on the development of software
The software shall be written in Java.
Functional vs. non-functional requirements
Functional
Functions that the software must execute
The software processes students' course
registrations.
Non-functional
Constraints or quality of the software
The software shall be able to process at least 500
course registrations per minute.
Software requirement analysis
A process of discovery, refinement, modeling, and
specification of software requirements.
Enables software engineer to
specify function and performance
indicate interaction with other elements
establish constraints that must be met.
Software
requirement
analysis
Software
design
Architectural design
Requirement sources
Goals (eg. business concern, success factors)
Domain knowledge
Stakeholders
Operational environment
Organisational environment
Stakeholders
(people involved in software development)
Users
Customers
Market analysts (for mass market software)
Regulators (eg. banking, transportation)
Software engineers
Techniques
Interviews
Observations
Scenarios (what-if, how-to)
Prototypes
Facilitated meetings
Refinement
Conflicts resolution
Prioritisation
Analysis principles (1)
The information domain of the problem must
be represented and understood.
Software is to process data and information.
Information domain consists of
Information content (ie. individual data)
Information structure
Information flow
The functions that the software is to perform
must be defined.
Function: what to do
Process
Input and output
Actor (optional)
Analysis principles (2)
The behaviour of the software must be
represented.
Behaviour: how to do
The detailed information of functions.
Analysis principles (3)
The models must be partitioned in a manner
that uncovers detail in a layered fashion.
Problem is too large or too complex to handle.
Decompose the problem into sub-problems.
Vertical and horizontal decomposition
Analysis principles (4)
Alarm software
Configure
system
Monitor
sensors
Interact
with user
Poll for
sensor event
Activate
alarm functions
Horizontal partitioning
V
e
r
t
i
c
a
l

p
a
r
t
i
t
i
o
n
i
n
g
The analysis process should move from
essential information toward
implementation detail.
Essential view
High-level representation of structures and function
(without involving implementation detail)
Implementation view
Real-world realisation of structures and functions.
Analysis principles (5)
Model A Model A
Model A'
Model A''
Essential information
Implementation detail 1
Implementation detail 2
Prototyping
Prototype is a software realisation of requirements
for assessment.
Build
prototype
Customer
test
prototype
Listen to
customer
Assessment
Requirement
analysis
Throwaway prototype
For demonstration purpose only
Prototype is discarded when requirement are
clearly understood.
Evolutionary prototype
Prototype is the first evolution of the software.
Prototype is continued into design and
construction.
Requirement specification
Establishes the basis for agreement between
customers and developers on
What the software to do
What the software not expected to do.
Provides a realistic basis for estimating
product costs, risks, and schedules.
Requirements are in natural language.
Requirement specification is supplemented by
formal or semi-formal description.
Eg. mathematical or graphical model.
Example: Specification outline
Introduction
System references
Overall description
Software project constraints
Information description
Information content and structure representation
Information flow representation
Functional description
Functional partitioning
Functional description: narrative, limitation,
performance, constraints, diagrams.
Behavioural description
Validation and criteria
Performance bounds
Classes of tests
Expected response
Special considerations
Bibliography
Appendix
Specification review
Do goals and objectives for software remain consistent
with system goals and objectives?
Have important interfaces to all system elements been
described?
Is information structure and flow adequately defined?
Are diagrams clear?
Do functions remain within scope and has each been
adequately described?
Is the behaviour consistent with the information it
must process and the functions it must perform?
Are design constraints realistic?
Have the technological risk been considered?
Have alternative software requirements been
considered?
Have validation criteria been stated in detail? Are they
adequate?
Do inconsistencies, omissions, or redundancy exist?
Has the user reviewed the preliminary prototype?
How are planing estimates affected?
Summary
Software requirement analysis
Analysis principles
Requirement specification
Thanks..

You might also like