Software Engineering PPT

89
Software Engineering IT350 Lecture 3 Software Process Models and Process Iteration Software Requirements

Transcript of Software Engineering PPT

Page 1: Software Engineering PPT

Software Engineering

IT350

Lecture 3

Software Process Models and

Process Iteration

Software Requirements

Page 2: Software Engineering PPT

Summary of last session

• Difference between Software Engineering and

Computer Science

2Software Engineering

Page 3: Software Engineering PPT

Summary of last session

• Difference between Software and System

Engineering

• Software Process

• Software Process model

• CASE tools

• Attributes of good software

Software Engineering 3

Page 4: Software Engineering PPT

Summary of last session

• Characteristics of an activity in a process

Software Engineering 4

Page 5: Software Engineering PPT

Summary of last session

• Software Process Models

– Waterfall model

– Evolutionary development

– Formal Systems Development Model

– Reuse-Oriented development

Software Engineering 5

Page 6: Software Engineering PPT

Agenda

• Software Process Models

– Waterfall model

– Evolutionary development

– Formal Systems Development Model

– Reuse-Oriented development

• Process iteration

• Software Requirements

6Software Engineering

Page 7: Software Engineering PPT

Formal Systems Development Model

Software Engineering 7

Requirementsdefinition

Formalspecification

Formaltransformation

Integration andsystem testing

Page 8: Software Engineering PPT

Formal Systems Development Model

• Advantages

– Useful when developing systems require strict

safety, reliability and security requirements.

• Disadvantages

– Mathematical notations used for the formal

specifications adds to the system development

effort and cost making this model impractical

– Proofs are very long and impractical for large-

scale systems.

8Software Engineering

Page 9: Software Engineering PPT

Reuse-Oriented development

9Software Engineering

Page 10: Software Engineering PPT

Reuse-Oriented development

• Advantages

– Reduced cost

– Save time

– Minimizes the likelihood of errors or bugs

• Disadvantages

– May lead to compromises in perceived

requirements, resulting in a product that does not

fully meet the needs of its intended users.

10Software Engineering

Page 11: Software Engineering PPT

Process Iteration

• Where parts of the process are repeated as

system requirements evolve.

• Types of iterative processes:

– Incremental development

– Spiral development

Software Engineering 11

Page 12: Software Engineering PPT

Incremental development

Software Engineering 12

Page 13: Software Engineering PPT

Advantages

• Customer do not have to wait until the entire

system is delivered.

• Lower risk of failure

• Highest priority services tend to receive the

most testing

Software Engineering 13

Page 14: Software Engineering PPT

Disadvantages

• Communication overhead

• Difficult to freeze requirements

• Requires a very efficient change control

mechanism

Software Engineering 14

Page 15: Software Engineering PPT

Spiral Model

Software Engineering 15

Page 16: Software Engineering PPT

• Advantages

– Most flexible models in place

– Risk management is one of the in-built features

• Disadvantages

– Extensive skill is required in evaluating

uncertainties or risks

– Evaluating the risks can shoot up the cost

Software Engineering 16

Page 17: Software Engineering PPT

Introduction to Software

Requirements

• Requirement:Is a description of services and

constraints of a system.

• Requirement Engineering : Is the process of

finding out, analysing, documenting and

checking the services and constraints of the

system.

Software Engineering 17

Page 18: Software Engineering PPT

Requirement

• It ranges from a

– high-level abstract statement - bid for a contract

– detailed mathematical functional specification –

contract

• Types of requirements:

– User requirement

– System requirement

– Software Design specification

Software Engineering 18

Page 19: Software Engineering PPT

Types of requirements

• User requirements:

– Statements in natural language plus diagrams of the services the system provides and its operational constraints written for customers.

• System requirements:

– A structured document setting out detailed descriptions of the system’s functions, services and operational constraints.

– Defines what should be implemented so may be part of a contract between client and contractor.

Software Engineering 19

Page 20: Software Engineering PPT

• Eg:

– User requirement

• The software must provide a means of accessing external files created by other tool

– System requirement

• The user should have a facility to define the type of the external file.

• Each external file should have an associated tool which can be applied to view the file

• Each external file must be represented as an icon on the desktop

• When the user selects an icon representing an external file, the effect must be to apply the pre-defined tool and open the file.

Software Engineering 20

Page 21: Software Engineering PPT

Readers of different specification

type

Software Engineering 21

User requirements

Client managersSystem end-usersClient engineersContractor managersSystem architects

System requirements

Software devlopersSystem end-usersClient engineersSystem architects

Software design specification

Client engineersSystem architectsSoftware developers

Page 22: Software Engineering PPT

Level of detail

Software Engineering 22

User requirement

System requirement

Software design specification

Page 23: Software Engineering PPT

Software Engineering 23

Page 24: Software Engineering PPT

Software Engineering 24

Page 25: Software Engineering PPT

THANK YOU!!!

25Software Engineering

Page 26: Software Engineering PPT

Software Engineering

IT350

Lecture 4

Software Requirements

Page 27: Software Engineering PPT

Summary of last session

• Software Process Models

– Waterfall model

– Evolutionary development

– Formal Systems Development Model

– Reuse-Oriented development

• Process iteration

– Incremental model

– Spiral model

2Software Engineering

Page 28: Software Engineering PPT

Agenda

• What is a requirement?

• What is requirement engineering?

• Different types of requirements

Software Engineering 3

Page 29: Software Engineering PPT

Introduction to Software

Requirements

• Requirement:Is a description of services and

constraints of a system.

• Requirement Engineering : Is the process of

finding out, analysing, documenting and

checking the services and constraints of the

system.

Software Engineering 4

Page 30: Software Engineering PPT

Requirements classification

• First axis: Based on the level of detail of requirements specification

– User requirement

– System requirement

– Software design specification

• Second axis- based on the operation and behaviour of the system

– Functional

– Non-functional

Software Engineering 5

Page 31: Software Engineering PPT

Types of requirements

• User requirements:

– Statements in natural language plus diagrams of the services the system provides and its operational constraints written for customers.

• System requirements:

– A structured document setting out detailed descriptions of the system’s functions, services and operational constraints.

– Defines what should be implemented so may be part of a contract between client and contractor.

Software Engineering 6

Page 32: Software Engineering PPT

• Eg:

– User requirement

• The software must provide a means of accessing external files created by other tool

– System requirement

• The user should have a facility to define the type of the external file.

• Each external file should have an associated tool which can be applied to view the file

• Each external file must be represented as an icon on the desktop

• When the user selects an icon representing an external file, the effect must be to apply the pre-defined tool and open the file.

Software Engineering 7

Page 33: Software Engineering PPT

Readers of different specification

type

Software Engineering 8

User requirements

Client managersSystem end-usersClient engineersContractor managersSystem architects

System requirements

Software devlopersSystem end-usersClient engineersSystem architects

Software design specification

Client engineersSystem architectsSoftware developers

Page 34: Software Engineering PPT

Level of detail

Software Engineering 9

User requirement

System requirement

Software design specification

Page 35: Software Engineering PPT

Software Engineering 10

Page 36: Software Engineering PPT

Software Engineering 11

Page 37: Software Engineering PPT

Functional and Non-functional

requirements

• Functional requirements

– Statements of services the system should provide,

how the system should react to particular inputs

and how the system should behave in particular

situation.

• Non-functional requirements

– Constraints on the services or functions offered by

the system such as timing constraints, constraints

on the development process, standards, etc.

Software Engineering 12

Page 38: Software Engineering PPT

Software Engineering 13

Page 39: Software Engineering PPT

Software Engineering 14

Page 40: Software Engineering PPT

• Some of the non-functional requirements– Accessibility

– Avaliability – system up time...

– Capacity – memory, database size, number of users ...

– Efficiency – accuracy of processing....

– Maintainability – mean time to repair.....

– Performance – speed, accuracy of processing...

– Portability- Platorms it should suport...

– Privacy – degree of confidentality

– Recoverability- recovery from power, product failure...

– Response time

– Reliability- Mean time to recovery...

– Security

– Software tools, standards

Software Engineering 15

Page 41: Software Engineering PPT

Non-functional requirements

Product requirements Organisational requirements External requirements

Product behaviour Based on policies and

procedures

• customer’s organisation

•developer’s organisation

Factors external to the

system

•Usability

•Performance

•Space

•Reliability

•Portability

•Delivery

•Implementation

•Standards

•Interoperability

•Ethical

•Safety

•Privacy

Eg1. No more than 2

defects of severity level

1 are to be

reported in a calendar

month.

Eg2: Should

accomediate 500 users

on the network

Eg 1: The product must follow

ISO standards

Eg 2: It should be developed

using Java language

Eg 1: Only the team lead

has

program check-out/check-

in authority.

Eg 2: Payments are

uploaded to the

frame:ABC123 at 3:00am

each Friday.

16Software engineering

Page 42: Software Engineering PPT

Library System

• A library system that provides a single

interface to a number of databases of articles

in different libraries.

• Users can search for download and print these

articles for personal study.

Software Engineering 17

Page 43: Software Engineering PPT

• Examples of functional requirements

– The user shall be able to search éither all of the

intial set of databases or select a subset from it.

– The system shall provide appropriate viewers for

the users to read documents in the document store.

– Every order shall be allocated a unique identifier(

ORDER_ID) which the user shall be able to copy

to the account’s permanent storage area.

Software Engineering 18

Page 44: Software Engineering PPT

• Examples of non-function requirements

– Product requirement: The user interface for Library system shall be implemented as simple HTML without Java applets.

– Organizational requirements: The system development process and deliverables documents shall conform to the process and deliverables defined in ISO 9001.

– External requirement: The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.

Software Engineering 19

Page 45: Software Engineering PPT

Domain requirements

• Reflects the characteristics of the domain

• Both functional and non-functional – Eg:

• The requirements for the insulin pump system that delivers insulin on demand include the following domain requirement:– The system safety shall be assured according to standard IEC 60601-

1:Medical Electrical Equipment – Part 1:General Requirements for Basic Safety and Essential Performance.

• The requirements for an automated train protection system. This system automatically stops a train if it goes through a red signal. This requirement states how the train deceleration is computed by the system– Dtrain=Dcontrol + Dgradient

Software Engineering 20

Page 46: Software Engineering PPT

• Domain requirement issues

– Understandability: Expressed in the language

specific to application domain which is not

understood by software engineers.

– Implicitness: Domain specialists may not leave out

information because it is obvious.

Software Engineering 21

Page 47: Software Engineering PPT

THANK YOU!!!

22Software Engineering

Page 48: Software Engineering PPT

Software Engineering

IT302

Lecture 5

Software Requirement

& Requirement engineering

processes

Page 49: Software Engineering PPT

Summary of last session

• Functional and Non-functional requirements

• User requirements

• System requirement

• Software design specification

2Software Engineering

Page 50: Software Engineering PPT

Agenda

• User and System requirements continued

• Software requirement document

• Requirement engineering process

• Feasibility study

Software Engineering 3

Page 51: Software Engineering PPT

Problems with natural language

• Lack of clarity: Difficult to use it in a precise

and unambiguous way.

• Requirements confusion: Functional

requirements, non-functional requirements,

system goals and design information are mixed

up.

• Requirements amalgamation: Several

requirements may be expressed together.

4Software Engineering

Page 52: Software Engineering PPT

Wrong way:

Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may beturned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of gridlines shown will be reduced to avoid filling the smaller diagram with grid lines.

• Grid requirement mixes different kinds of requirement• Functional requirement (the need for a grid)• Non-functional requirement (grid units)• Non-functional interface requirement (via control panel)

• Initial information given – grid is initially off• Initial information missing – units when turned on.

5Software Engineering

Page 53: Software Engineering PPT

Right way:

A grid facility shall be provided, where a matrix

of horizontal and vertical lines provide a

background to the editor window to add

objects to a diagram

6Software Engineering

Page 54: Software Engineering PPT

How to overcome?

• Use standard format such as bolding, including

rationale.

• Use language consistency such as shall for

mandatory requirments and should for

desirable requirements.

• Use text highlighting for key parts of

requirements.

• Avoid computer jargons.

Software Engineering 7

Page 55: Software Engineering PPT

Structured language specifications

• A restricted form of natural language may be used to express requirements

• Limits the terminology used and may use templates to specify system requirements

• Advantage:

– No ambiguity

– Imposes a degree of uniformity

• Often best supported using a forms-based approach

8Software Engineering

Page 56: Software Engineering PPT

Form-based specifications

• Definition of the function or entity

• Description of inputs and where they come

from

• Description of outputs and where they go to

• Indication of other entities required

• Pre and post conditions (if appropriate)

• The side effects (if any)

9Software Engineering

Page 57: Software Engineering PPT

• Function

• Description

• Inputs

• Source

• Outputs

• Destination

• Requires

• Pre-condition

• Post-condition

• Side-effects

Software Engineering 10

Page 58: Software Engineering PPT

• Function Add node

• Description Adds a node to an existing design. The user selects the type of node, and its position. When added to the design, the node becomes the current selection. The user shooses the node position by moving the cursor to the area where the node is added

• Inputs Node type, node position, Design identifier.

• Source Node type and Node position are imput by user, Design identifier from the database.

• Outputs Design identifier

• Destination The design database. The design is commited to the database on completion of the operation.

• Requires Design graph rooted at input design identifier.

• Pre-condition The design is open and displayed on the user’s screen.

• Post-condition The design is unchanged apart from the addition of a node of specified type at the given position.

• Side-effects None

Software Engineering 11

Page 59: Software Engineering PPT

PDL-based requirements definition

• Requirements may be defined operationally using a program descriptive language (PDL)

• Most appropriate in two situations

– Where an operation is specified as a sequence of actions and the order is important

– When hardware and software interfaces have to be specified

12Software Engineering

Page 60: Software Engineering PPT

PDL disadvantages

• PDL may not be sufficiently expressive to express the system functionality in an understandable way

• Notation is only understandable to people with programming language knowledge

• The requirement may be taken as a design specification rather than a model to help understand the system

13Software Engineering

Page 61: Software Engineering PPT

Interface specification

• Specifies how a system should be interfaced with the other systems.

• Three types iof interface:

– Procedural interface: Where existing system offers a range of services which are accessed by calling interface procedures.

– Data structures which are passed from one sub-system to another sub-system.

– Representation of data which have been established for an existing sub-system.

Software Engineering 14

Page 62: Software Engineering PPT

Software requirements

specification(SRS)

• Is the official statement of what is required of

the system developers

• It is NOT a design document. As far as

possible, it should be a set of WHAT the

system should do rather than HOW it should

do it.

15Software Engineering

Page 63: Software Engineering PPT

Use the requirements todevelop validation tests forthe system

Use the requirementsdocument to plan a bid forthe system and to plan the

system development process

Use the requirements tounderstand what system is tobe developed

System testengineers

Managers

System engineers

Specify the requirements andread them to check that they

meet their needs. Theyspecify changes to therequirements

System customers

Use the requirements to help

understand the system andthe relationships between itsparts

Systemmaintenance

engineers

16Software Engineering

Page 64: Software Engineering PPT

IEEE standard for SRS

• Introduction– Purpose

– Scope

– Definition, acronyms and abbreviations

– References

– Overview

• General description– Product perspective

– Product functions

– User characteristics

– General constraints

– Assumptions

• Specific requirements– Functional requirements

– Non-functional requirements

– External interface requirements

• Appendices

• Index

17Software Engineering

Page 65: Software Engineering PPT

Deadline 2

• Task:

– SRS in IEEE format

• Plagiarism Control : YES

• Deadline:

– 13 rd Aug, 2012 by 10:00 am

Software Engineering 18

Page 66: Software Engineering PPT

Requirements engineering

Software Engineering 19

Page 67: Software Engineering PPT

Feasibility study

• Feasibility study determines whether proposed

system is wothwhile or not.

• Three activities are involved

– Informatin assessment

– Information collection

– Report writing

Software Engineering 20

Page 68: Software Engineering PPT

• Does the system contribute to the overall objective of the organisation?

• Is there a demand for the software?

• Who else is producing similar software?

• What is needed to make the software? ( Can the system be developed using the current technology that is used by the organisation.)

• What is the cost and time required for producing a software? (Can it developed within the cost and schedule?)

• Can the system be integrated with other systems which are in place?

• What is the likely profit?

Software Engineering 21

Information assessment

Page 69: Software Engineering PPT

Information Sources

• Managers of department

• Software Engineers

• Technology experts

• End-users etc

Software Engineering 22

Page 70: Software Engineering PPT

Outcome

– May approve a proposal

– May break the proposal

– May change:

• Project scope

• Budget

• Schedule of the project

Software Engineering 23

Page 71: Software Engineering PPT

THANK YOU!!!

Software Engineering 24

Page 72: Software Engineering PPT

Software Engineering

IT302

Lecture 6

Requirements Engineering

Page 73: Software Engineering PPT

Summary of last session

Software Engineering 2

Page 74: Software Engineering PPT

Summary of last session

• Problems with natural language– Lack of clarity

– Requirements confusion

– Requirements amalgamation

• How to overcome?

• Structured language specifications: Restricted form of natural language – No ambiguity

– Imposes a degree of uniformity

– Example: Form-based specification

• PDL-based requirements definition– sequence of actions and the order is important

– hardware and software interfaces have to be specified

Software Engineering 3

Page 75: Software Engineering PPT

procedure ATM is

PIN: Pin_no ;

Acc_no: Account_number ;

Balance: Amount ;

Service: Available_services ;

Valid_card, Valid_PIN: Boolean ;

begin

loop

Get_card ( Acc_no, PIN, Valid_card) ;

if Valid_card then

Validate_PIN (PIN, Valid_PIN) ;

if Valid_PIN then

Get_account (Acc_no, Balance) ;

Get_service (Service) ;

while a service is selected loop

Deliver_selected_service ;

Get_service (Service) ;

end loop ;

Return_card ;

end if ;

end if ;

end loop ;

end ATM ;

Software Engineering 4

Page 76: Software Engineering PPT

Summary of last session

• Disadvantage of PDL

– Not expressive

– Not understood by everyone

– More of design specification

Software Engineering 5

Page 77: Software Engineering PPT

Summary of last session• Interface specification

• Software requirements specification(SRS)

• Introduction– Purpose

– Scope

– Definition, acronyms and abbreviations

– References

– Overview

• General description– Product perspective

– Product functions

– User characteristics

– General constraints

– Assumptions

• Specific requirements– Functional requirements

– Non-functional requirements

– External interface requirements

• Appendices

• Index

Software Engineering 6

Page 78: Software Engineering PPT

Summary of last session

Software Engineering 7

Page 79: Software Engineering PPT

Summary of last session

• Feasibility study : Feasibility study

determines whether proposed system is

wothwhile or not.

Software Engineering 8

Page 80: Software Engineering PPT

Tips for the assignment

• Follow only IEEE format of SRS that has

been discussed in class

• Function requirements under the specific

requirements are the details versions i.e.

system requirements

• Phrases such as ‘shall’, ‘should’ and may be

should be expressed for mandatory, desired

and optional requirements respectively.

Software Engineering 9

Page 81: Software Engineering PPT

• Function Add node

• Description Adds a node to an existing design. The user selects the type of node, and its position. When added to the design, the node becomes the current selection. The user shooses the node position by moving the cursor to the area where the node is added

• Inputs Node type, node position, Design identifier.

• Source Node type and Node position are imput by user, Design identifier from the database.

• Outputs Design identifier

• Destination The design database. The design is commited to the database on completion of the operation.

• Requires Design graph rooted at input design identifier.

• Pre-condition The design is open and displayed on the user’s screen.

• Post-condition The design is unchanged apart from the addition of a node of specified type at the given position.

• Side-effects None

Software Engineering 10

Page 82: Software Engineering PPT

Agenda

• Requirement elicitation and analysis

Software Engineering 11

Page 83: Software Engineering PPT

Requirements engineering

Software Engineering 12

Page 84: Software Engineering PPT

Requirements elicitation and

analysis

• Sometimes called requirements elicitation or

requirements discovery.

• Involves technical staff working with customers

to find out about the application domain, the

services that the system should provide and the

system’s operational constraints.

• May involve end-users, managers, engineers

involved in maintenance, domain experts, trade

unions, etc. These are called stakeholders.

Software Engineering 13

Page 85: Software Engineering PPT

Stakeholders

• Anyone who has direct or indirect influence on

the system requirements.

• Such as,

– Customer

– End user

– Domain experts etc

Software Engineering 14

Page 86: Software Engineering PPT

Requirements elicitation and

analysis

Process entry

Software Engineering 15

Requirementschecking

Domainunderstanding

Requirements collection

Classification

Conflictresolution

Prioritisation

Requirementschecking

Domainunderstanding

Requirements collection

Classification

Conflictresolution

Page 87: Software Engineering PPT

Problems with elicitation and analysis

• Stakeholders do not know what they want from system.

• Users express requirements in their own terms.

• Different users may have conflicting requirements.

• Organisational and political factors may influence the system requirements.

• The requirements change during the analysis process.

Software Engineering 16

Page 88: Software Engineering PPT

• Methods for requirement elicitation and

analysis:

– Viewpoint-oriented elicitation

– Scenarios

• Event scenarios

• Use-case

– Ethnography

Software Engineering 17

Page 89: Software Engineering PPT

Thank you!!!

Software Engineering 18