12
LECTURE 2 Software Engineering Software Requirement / Sp ecification

SE Lecture2

Embed Size (px)

Citation preview

Page 1: SE Lecture2

8/7/2019 SE Lecture2

http://slidepdf.com/reader/full/se-lecture2 1/12

LECTURE 2Software Engineering

Software Requirement / Specification

Page 2: SE Lecture2

8/7/2019 SE Lecture2

http://slidepdf.com/reader/full/se-lecture2 2/12

Software Specification or Requirements

The Descriptions of the services andconstraints are the requirements for thesystem and the process of finding out,analyzing, documenting and checkingthese services and constraints is calledrequirements engineering.

Page 3: SE Lecture2

8/7/2019 SE Lecture2

http://slidepdf.com/reader/full/se-lecture2 3/12

Ambiguous requirements

Page 4: SE Lecture2

8/7/2019 SE Lecture2

http://slidepdf.com/reader/full/se-lecture2 4/12

Levels of Requirements

Some of the problems that arise during the requirement

engineering process are a result of failing to make a clear

separation between the different levels of description. User Requirements

� High level abstract requirements

System Requirements� Detailed description of what the system should do

A software design specification� Is an abstract description of design specification

Page 5: SE Lecture2

8/7/2019 SE Lecture2

http://slidepdf.com/reader/full/se-lecture2 5/12

Advantage of Requirement Levels

Communicate

informationabout the

system to

different types

of readers

User requirement

System

requirements

Software designspecification

Client mangersSystem end-usersClient engineers

Contractor managers

System architects

System end-usersClient engineersSystem architectsSoftware developers

System architectsSoftware developers

Page 6: SE Lecture2

8/7/2019 SE Lecture2

http://slidepdf.com/reader/full/se-lecture2 6/12

Classification of Requirements

Software System requirements are often classified as following

Functional requirements

� It describe the functionality/services which system should provide.� How the system should react to particular input.� What type of output system should produce.� How the system behave in particular situation or exception.� Use cases are used to captured functional requirements

Non-functional requirements� It describe the constraints on the service/functions offered by system.� They relate to system properties such as reliability, response time, storage

occupancy, security etc.

Page 7: SE Lecture2

8/7/2019 SE Lecture2

http://slidepdf.com/reader/full/se-lecture2 7/12

User Requirements

Should simply focus on the key facilities to be provided.

Should describe the functional and non-functional

requirements.� User don·t have detailed technical knowledge.

Should specify the external behavior of the system.� Avoid as far as possible, system design characteristics.

Must be written using natural language forms and simpleintuitive diagrams.

Page 8: SE Lecture2

8/7/2019 SE Lecture2

http://slidepdf.com/reader/full/se-lecture2 8/12

System Requirements

More detailed descriptions of the user requirements.

Serve as contract between contractor and client.

Should be complete and consistent specification of the wholesystem.� Requirement specification may include data-flow model.

They are the starting point of system design for softwareengineer

Should state what the system should do and not how itshould be implemented.

Page 9: SE Lecture2

8/7/2019 SE Lecture2

http://slidepdf.com/reader/full/se-lecture2 9/12

REA(Requirement Engineering activity)

RE is a process that involves all of the activities required to create andmaintain a system requirements document. There are four generic highlevel RE process activities.

Feasibility

report

Feasibility

study

Requirements

elicitation and

analysis

Requirements

specification

Requirements

validation

System

ModelUser and system

requirementsRequirements

document

Page 10: SE Lecture2

8/7/2019 SE Lecture2

http://slidepdf.com/reader/full/se-lecture2 10/12

10

Feasibility Studies

Is a focused study which aims to answer a number of questions

Does the system contribute to the overallobjectives of the organization?

Can the system be implemented usingcurrent technology and within given costand schedule constraints?

Can the system be integrated with other

systems which are already in place?

Page 11: SE Lecture2

8/7/2019 SE Lecture2

http://slidepdf.com/reader/full/se-lecture2 11/12

11

Requirements elicitation and analysis

In this activity, technicalsoftware development staff

work with stakeholders to findout about the applicationdomain, what services thesystem should provide, therequired performance of the

system, hardware constraints,and so on.

Domain

understanding

Requirements

collection

Classification

Conflict

resolution

Prioritisation

Requirements

checking

Requirements

specification

Requirements

document

Page 12: SE Lecture2

8/7/2019 SE Lecture2

http://slidepdf.com/reader/full/se-lecture2 12/12

Next Lecture

Requirement Specification

Requirement Validation