2 Analysis Concepts and Principles

8/3/2019 2 Analysis Concepts and Principles

1/29

Department of Informatics Universitas Islam Indonesia

Analysis concepts and principles

Teduh Dirgahayu

[email protected]

Software Engineering


2/29

February 16, 2011Software Engineering 2


Outline Software requirement analysis

Source, stakeholders, techniques

Analysis principles Prototyping

Requirement specification

Review


3/29



Change

Development

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 errorsthat were made in the design and construction

of the solution? How will the solution be supported over long

term?

Definition


4/29



Analysis

Design

Code

Test

Maintenance

Definition

Change

Development


5/29



Software requirements A software requirement

a property which must be exhibited bysoftware developed or adapted to solve aparticular problem.


6/29



Product vs. process requirements

Product

requirements on software

The software shall verify that a student meets allprerequisites before he/she registers for a course.

Process requirements on the development of software

The software shall be written in Java.


7/29February 16, 2011Software Engineering 7


Functional vs. non-functional requirements

Functional

Functions that the software must execute

The software processes students' courseregistrations.

Non-functional Constraints or quality of the software

The software shall be able to process at least 500course registrations per minute.


8/29



Software requirement analysis A process ofdiscovery, refinement,

modeling, and specification of softwarerequirements.

Enables software engineer to

specify function and performance

indicate interaction with other elements

establish constraints that must be met.


9/29



Software

requirementanalysis

Softwaredesign

Architectural design


10/29



Requirement sources

Goals (eg. business concern, success factors)

Domain knowledge Stakeholders

Operational environment

Organisational environment


11/29



Stakeholders

(people involved in software development)

Users Customers

Market analysts (for mass market software)

Regulators (eg. banking, transportation) Software engineers


12/29



Techniques

Interviews

Scenarios (what-if, how-to) Prototypes

Observations

Facilitated meetings

Refinement

Conflicts resolution

Prioritisation


13/29



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


14/29



Analysis principles (2) The functions that the software is to

perform must be defined.

Function: what to do Process

Input and output

Actor (optional)


15/29



Analysis principles (3) The behaviour of the software must be

represented.

Behaviour: how to do The detailed information offunctions.


16/29



Analysis principles (4) 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

l d


17/29



Alarm software

Configure

system

Monitor

sensors

Interact

with user

Poll forsensor event

Activatealarm functions

Horizontal partitioning

Verticalpart

itioning

l d


18/29



Analysis principles (5) The analysis process should move from

essential information towardimplementation detail. Essential view

High-level representation of structures and function(without involving implementation detail)

Implementation view

Real-world realisation of structures and functions.

U i i I l I d i


19/29



Model AModel A

Model A'

Model A''

Essential information

Implementation detail 1

Implementation detail 2

U i i I l I d i


20/29



Prototyping Prototype is a software realisation of

requirements for assessment.Build

prototype

Customertest prototype

Listen tocustomer

Assessment

Requirementanalysis

U i it I l I d i


21/29



Throwaway prototype

For demonstration purpose only

Prototype is discarded when requirement areclearly understood.

Evolutionary prototype

Prototype is the first evolution of the software. Prototype is continued into design and

construction.

U i it I l I d i


22/29



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 estimatingproduct costs, risks, and schedules.

Uni ersitas Islam Indonesia


23/29



Requirements are in natural language.

Requirement specification is supplemented

by formal or semi-formal description. Eg. mathematical or graphical model.

Universitas Islam Indonesia


24/29



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.



25/29



Behavioural description

Validation and criteria

Performance bounds

Classes of tests Expected response

Special considerations

Bibliography

Appendix



26/29



Specification review

Do goals and objectives for software remainconsistent with system goals and objectives?

Have important interfaces to all system elementsbeen described?

Is information structure and flow adequatelydefined?

Are diagrams clear? Do functions remain within scope and has each

been adequately described?



27/29



Is the behaviour consistent with the information itmust process and the functions it must perform?

Are design constraints realistic?

Have the technological risk been considered?

Have alternative software requirements beenconsidered?

Have validation criteria been stated in detail? Arethey adequate?

Do inconsistencies, omissions, or redundancy exist?

Has the user reviewed the preliminary prototype?

How are planing estimates affected?



28/29



Summary Software requirement analysis

Analysis principles

Requirement specification



29/29

February 16 2011Software Engineering 29


Homework Assignment

Do a requirement analysis for your softwareproject.

Prepare a presentation for 5 minutes.

Documents

2 Analysis Concepts and Principles