nscet e-learning presentation notes/unit 2/cs8494_se.pdf · difference verification validation...

NSCET

E-LEARNING

PRESENTATION

LISTEN … LEARN… LEAD…

Department of CSE, NSCET, Theni 1

COMPUTER SCIENCE AND

ENGINEERING

Mr.C.PRATHAP M.Tech.,(Phd)., Assistant Professor

Nadar Saraswathi College of Engineering & Technology, Vadapudupatti, Annanji (po), Theni – 625531.

CS8494 – SOFTWARE ENGINEERING

II YEAR / IV SEMESTER

PHOTO


UNIT 02 – Requirement Analysis and

Specification

Department of CSE, NSCET, Theni

It is the process of Establishing the services tat the customer requires from a system. And the constraints under which it operates and its developed.

Requirement Engineering

Department of CSE, NSCET, Theni

Types of Requirements • User

• System

• Software Specification


Functional Requirements These form the behavior of the product. Some

examples of functional requirements are,

• New features

• Bug fixes

• New behavior


Non-functional Requirements

These are implicit expectations from the product. Since these are expected features and not specifically documented requirements, they are also known as ‘Quality Attributes’. Some examples of non-functional requirements are,

• Performance

• Reliability

• Error handling

• Ease of use


System Requirements • Its more detailed specifications of system functions ,

services and constraints than user requirements.

• It can be expressed using system models.

• It specify what the system does and design specifies

how it does.

• It describe the external behavior of the system and

its operational constraints.


Verification and Validation • Verification:

The process of evaluating software to

determine whether the products of a given

development phase satisfy the conditions imposed at

the start of that phase.

• Validation:

The process of evaluating software during or at

the end of the development process to determine

whether it satisfies specified requirements.


Difference

Verification Validation

1.Verification is a static practice of verifying documents, design, code and program.

1. Validation is a dynamic mechanism of validating and testing the actual product.

2. It does not involve executing the code. 2. It always involves executing the code.

3. It is human based checking of documents and files.

3. It is computer based execution of program.

4. Verification uses methods like inspections, reviews, walkthroughs, and Desk-checking etc.

4. Validation uses methods like black box (functional) testing, gray box testing, and white box (structural) testing etc.

5. Verification is to check whether the software conforms to specifications.

5. Validation is to check whether software meets the customer expectations and requirements.


Requirement Engineering Process


Introduction to requirement engineering

• The process of collecting the software requirement

from the client then understand, evaluate and

document it is called as requirement engineering.

• Requirement engineering constructs a bridge for

design and construction.


Requirement engineering consists of

seven different tasks as follow: Inception

• Inception is a task where the requirement engineering

asks a set of questions to establish a software process.

• it understands the problem and evaluates with the

proper solution.

• It collaborates with the relationship between the

customer and the developer.

• The developer and customer decide the overall scope

and the nature of the question.


Elicitation

Elicitation means to find the requirements

from anybody. The requirements are difficult

because the following problems occur in

elicitation.

• Problem of scope

• Problem of understanding

• Problem of volatility


Elaboration • In this task, the information taken from user during

inception and elaboration and are expanded and

refined in elaboration.

• Its main task is developing pure model of software

using functions, feature and constraints of a

software.


Negotiation

• In negotiation task, a software engineer decides

how will the project be achieved with limited

business resources.

• To create rough guesses of development and

access the impact of the requirement on the

project cost and delivery time.


Specification

• In this task, the requirement engineer constructs a final work product.

• The work product is in the form of software requirement specification.

• In this task, formalize the requirement of the proposed software such as informative, functional and behavioral.

• The requirement are formalize in both graphical and textual formats.


Validation

The work product is built as an output of the

requirement engineering and that is accessed for

the quality through a validation step.

• The formal technical reviews from the software

engineer, customer and other stakeholders helps for

the primary requirements validation mechanism.


Requirement management

• It is a set of activities that help the project team to

identify, control and track the requirements and

changes can be made to the requirements at any

time of the ongoing project.

• These tasks start with the identification and assign a

unique identifier to each of the requirement.

• After finalizing the requirement traceability table is

developed.


Feasibility Study • Feasibility Study is essential to evaluate cost &

benefits of the proposed system.

• On the basis of the feasibility study decision is taken

on whether to proceed or to postpone the project

or to cancel the project Steering Committee


Needs of feasibility study • It determine the potential of the existing system .It finds

or determine all the problem of existing system.

• To determine all the goals of the system.

• It finds all possible solutions of the problem of existing

system.(that becomes proposed system).

• It find technology required to solve these problems.

• It determines really which solution is easy for operational

from the point of view of customer or employees such

that it requires very less time with 100% accuracy


Needs of feasibility study • It determines what hardware and software is

required to obtain solution of each problem or

proposed system.

• It determines cost requirements of the complete

proposed system in terms of cost of hardware

required, software required, designing new system,

implementation and training, proposed

maintenance cost.


Types of feasibility study 1) Technical Feasibility.

2) Operational Feasibility.

3) Economical Feasibility.


Technical Feasibility: Following things should be considered

• Determine available hardware.

• Determine available computer with configuration.

• Determine available software.

Find out technical feasibility required for proposed system

• It mentions new hardware requirements of proposed system.

• It Mentions Computer with new configuration requirements of proposed system

• It mentions New software requirements of the proposed system


Operational Feasibility (Behavioral feasibility)

It find out whether the proposed System will be suitable using three types of aspects;

That are human, organizational, and political aspects • It finds out whether there is any direct-indirect resistance from the user of

this system or not? • It finds whether the operations of proposed system is easy or not as

compare to existing system. • It find out whether the user or customer of the system requires extra

training or not? • It finds if any job reconstruction is required or not?

• Watches the feelings of the customers as well as user. • System should provide right & accurate information to user or customer

at right place as well as at right time.


Economical Feasibility: • Here, Steering committee finds total cost and all

benefits of the proposed system.

• There are two types of costs:

One time cost & recurring cost


One time cost involve following :

Feasibility study cost:

Cost converting existing system to proposed system

Cost to remolding architecture of the office, machinaries, rooms etc.

Cost of hardware‘s.

Cost of operating Software’s.

Cost of Application software’s.

Cost of training.

Cost of documentation preparation.


Recurring cost involves following :

• Cost involves in purchase or rental of equipment.

• Cost of phones & mobile communication

equipment.

• Cost of salaries of employee .

• Cost of maintenance of equipment.


Schedule Feasibility • It is the establishment of time limit for completion of

the project.

• This kind of feasibility is dependent upon available

manpower and economical support for the project.


Requirement Elicitation and Analysis

• It means discovery of all possible requirements .

• After identifying all possible requirements

the analysis on these requirements can be done.

• It’s a process of interacting with customers and

end-users to find out about the domain

requirements, what services the system should

provide, and the other constrains.


Stake Holders • It means the persons who will be affected by the

system.

eg: end-user , System maintenance engineers

or software engineers can be stake holders.


Problems Encountered in

Understanding the Requirements • Unrealistic expectations.

• Differences in the requirements.

• Economic and business environment.

• Political changes.


Requirement and Elicitation

process



process • Requirement Discovery:

By having effective communication with

the customer the requirements can be identified.

• Requirement classification and organization:

Unstructured requirements can be

categorized systematically depending upon their

nature. And they are arranged in groups.



process • Requirement Prioritization:

There are some conflicting requirements.

Hence the requirements are prioritized first.

if there are some unrealistic

requirements then negotiations are made and only

realistic prioritized requirements are collected.


Requirement and Elicitation process • Requirement documentation:

This is the specification of all the

requirements. And important requirements are

document is created.


Requirement Discovery • It means finding all relevant information about the

system.

• The Sources of information for requirement

gathering are documentation , System stake

holders and specification some other system which

is of similar kind.


Various methods of Requirement Discovery

• Interviewing

Effective method of requirement gathering.

Two types

Closed Interview

Open Interview


Characteristics of Interview • It Should be conducted in free environment.

• Open mind approach.

• Patience

• Unrealistic expectations are try to change their

mind.

• Start the discussion by asking questions.


Scenario • It is the sequence of interactions made by the user

with the software systems.

• From this scenarios to formulate the actual system

requirements.

• Each scenario covers one or more interaction

sessions.


Scenario • Each Scenario Includes

A description of what the system and the users want at the beginning of the scenario.

A description of normal flow of events.

A description of something that went wrong and handling of it.

A description of other activities occurring in parallel

A description of finish state.


VIEW POINT • It provides the perspective to the system and using

these perspectives the requirements can be

discovered.

Interactor

Indirect

Domain


VIEW POINT


USECASES • It is the fundamental units of modelling language, in

which functionalities are distinctly presented.

• Use cases help to identify individual interactions

with the system.


USECASES


Requirement Validation • It is a process in which it is checked that whether the

gathered requirements represent the same system that customer really wants.

• Requirement checking can be done in the following manner :

Validity

Consistency

Completeness

Realism

Verifiability


Techniques • Requirements review

• Prototyping

• Test Case Generation


Requirement Management

It is the process of managing changing

requirements during the requirements engineering

process and system development.


Why Requirements Get Change • Requirements are always incomplete and

inconsistent.

• System Customers may specify the requirements

from business perspective that can conflict with end

user requirements.

• During the development of the system, the

technical environment get changed.


Enduring and Volatile Requirements ENDURING:

• These are relatively stable requirements that derive

from the core activity of the organization and which

relate directly to the domain of the system.

VOLATILE:

• Requirements that are likely to change during the

system development process or after the system

has been become operational


Types of Volatile Requirements • Mutable Requirements.

Requirements that change because of

changes to the environment in which the

organization is operating.

• Consequential Requirements

Requirements that result from the introduction of the computer system. Introducing the computer system may change the organizations processes and open up new ways of working which generate new system requirements.


Types of Volatile Requirements • Emergent Requirements :

Requirements that emerge as the customer's

understanding of the system develops during the

system development.

• Compatibility Requirements :

Requirements that depend on the particular

systems or business processes within an

organization.


Requirement Management Planning • Traceability is concerned with relationship between

requirements their sources and the system design.

• Using Traceability the requirement finding become

easy.


Types • Source Traceability :

These are basically the links from requirement to stake holders who propose these requirements.

• Requirement Traceability :

These are the links between dependent Requirements.

• Design Traceability:

These are the links from requirements to design.


Requirement Change Management

Problem Analysis and change specification

Change Analysis and Costing

Change Implementation


Structured System Analysis • Structured analysis is a software engineering

technique that uses graphical diagrams to develop

and portray system specifications that are easily

understood by users.

• These diagrams describe the steps that need to

occur and the data required to meet the design

function of a particular software.


Structured System Analysis • The structured analysis is mapping of problem

domain to flows and transformations.

• The System Modeling can be modeled Using :

* Entity Relationship diagram are used to

represent data model.

* Data Flow diagram and Control flow

diagrams are used to represent the functional

model.


Designing Data Flow Diagrams • A data flow diagram (DFD) maps out the flow of

information for any process or system.

• It uses defined symbols like rectangles, circles and

arrows, plus short text labels, to show data inputs,

outputs, storage points and the routes between

each destination.


NOTATIONS • The following table shows the symbols used in

designing a DFD and their significance −

Symbol Name Symbol Meaning

Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow

Open Rectangle Data Store


Guide Line • Level 0 DFD i.e Context level DFD should depict the

system as a single bubble.

• Primary input and primary output should be carefully identified.

• While doing the refinement isolate processes , data objects and data stores to represent the next level.

• All the bubbles and arrows should be appropriately named.

• One bubble at a time should be refined.

• Information flow continuity must be maintained from level to level.


Petri Nets • Petri nets are specific types of modeling constructs

useful in data analysis, simulations, business process

modeling and other scenarios.

• This type of mathematical construct can help to

plan workflows or present data on complicated

systems.


Data Dictionary • It is defined as an organized collection of all the

data elements of the system with precise and

rigorous definitions.

• The data models are less detail hence there is a

need for data dictionary.

• Description of the entities, relationships and

attributes are also included in data dictionary.


Data Dictionary • The data dictionary stores following type of

information:

Name Description

Name Primary name of data or control item , the data store or external entity.

Alias Other name used for the Name

Where used or How is used

Data or Control item where is used. It also describes how is used


Notations Data Construct Notation Meaning

Composition = Is Composed of

Sequence + And

Selection [|] Or

Repetition {}n Repetition for n times

() Optional Data

*…..* Commented information


nscet e-learning presentation notes/unit 2/cs8494_se.pdf · difference verification validation...

Documents