REKAYASAPERANGKAT LUNAKSemester 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 softwaredeveloped 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

Vert

ical part

itio

nin

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 AModel 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..