Sre 2

Software Requirement Engineering (CSE-305)
Lecture 2
Object Orientation and Software Engineering
Muhammad Fawad
Lecturer
COMSATS Institute of Information Technology
1 COMSATS Institute of Information Technology, Attock Muhammad Fawad

Lecture overview
Introduction to:
Object oriented analysis
Object oriented design
UML
Software development process

Introduction to OOAD
The proverb owning a hammer doesnt make one an

architect is especially true with respect to object technology
Knowing an object language is necessary but insufficient to
create object systems
Its about analyzing system requirements in terms of objects
and allocating responsibilities to class objects
How would these objects collaborate with each other
What classes should do what

OOA
It emphasizes on finding requirements and problems rather

than solutions
Object oriented analysis is a process of analyzing
requirements in an object oriented paradigm
It approves some of the requirements while discards others
The requirements are represented in the form of Use cases
and personas to make more sense
Based on this OOA the OOD is built

Use Case
Use case consists of a paragraph or so text that presents a

scenario of a single system requirement
It is written in simple English that would help realize the
importance of the requirement and its contribution to the over
all system
There can be many use cases for a system representing its
various requirements
It is not an OO activity but it helps in the development of
OOD

Use Case
Example
Use Case Login to System
When the User tries to access the system, the systems asks for
a user name and password. On provision of the correct user
name and password the user is allowed to enter the system.

Persona
Persona is an imaginary story in which the importance of the

required system is highlighted.
It is in the form of a short story
It assumes a person with certain personal details whom the
writer know
The writer explains the problems of the person in the
persona with the current system and how it is lagging him
behind
It also explains what the user actually wants things to be
In this way the requirements of the system are elaborated

OOD
It emphasizes on the conceptual solution in software or

hardware that fulfills the requirements
It does not give any implementation details
Design ideas normally exclude low level details that are
obvious to the intended customers
Ultimately designs can be implemented in code to give its
true and complete realization

OOA vs OOD
In OOA there is an emphasis on finding and describing

objects or concepts in the problem domain
For example in flight information system some of the objects
are flights, planes and pilot
During OOD there is emphasis on defining software objects
and how they collaborate with each other to fulfill
requirements
For example a flight object may have attributes like flight
duration, departure time, arrival time, source, destination etc.

Assigning responsibilities to objects
It is the most critical activity
This activity has to be performed either while drawing UML

diagrams or programming
It strongly influences the robustness, maintainability and

reusability of the software components

UML
UML is a standard diagramming notation

UML is not OOAD or a method it is just a diagramming
notation
It is useless to learn UML but not really know how to create
an excellent OO design or evaluate and improve an existing
one
To know how to design is a separate skill

UML Diagrams
Use case diagram

Activity diagram
Sequence diagram
Domain model
Class diagram
Collaboration diagram

UML perspectives
Conceptual perspective
The diagrams are interpreted as describing things in a situation
of the real world or domain of interest
Specification perspective
The diagrams (using same notations) describe software
abstraction or components with specifications and interfaces but
no commitment to a particular implementation
Implementation perspective
Software implementation in a particular technology

Development Process
Given the requirements and possible activities that are to be

implemented the question is how to proceed
In this case, an agile (light, flexible) approach is used as
sample of iterative development process
Agile development process is relatively new approach and is
very successful

Iterative development process
Iterative development process is an agile development
process
During this process development is organized in to a series
of short, fixed-length mini-projects called iterations
The outcome of each iteration is tested, integrated as
executable partial system
Each iteration includes its own requirements analysis,
design, implementation and testing activities
It is also called iterative and incremental development
Also called iterative and evolutionary development (feedback
and adaptation)

Requirement Engineering Introduction
Requirements form the basis for all software products
Requirements engineering is the process, which enables us

to systematically determine the requirements for a software
product
16
Requirement
Something required, something wanted or needed

Websters dictionary
There is a huge difference between wanted and needed and
it should be kept in mind all the time
17
REQUIREMENT
1. I hope to have a car (The capability to posses a car is absent but hope
exists that someday it might be possible)
2. I wish to have a car (The capability to posses a car is distinctly possible
but not feasible yet)
3. I desire to have a car (The capability to posses a car exists. But there
are other competing demands to cater to.)
4. I need a car (The capability exists and it is feasible. Having a car
surpassed other competing demands)
5. I require a car (Possessing a car can no longer be postponed. It is
essential now)
18
Software Requirements - 1
A complete description of what the software system will do

describing how it will do it is represented by the software
requirements
19
Software requirements are complete specification of the

desired external behavior of the software system to be built
They also represent External behavior of the system
20
Software requirements may be:

Abstract statements of services and/or constraints
Detailed mathematical functions
21
Software requirements may be:

Part of the bid of contract
The contract itself
Part of the technical document, which describes a product
22
IEEE Definition
A condition or capability that must be met or possessed by a

system...to satisfy a contract, standard, specification, or other
formally imposed document
IEEE Std 729
23
Sources of Requirements
Stakeholders
People affected in some way by the system
Documents
Existing system
Domain/business area
24
Importance of Software Requirements
The hardest single part of building a software system is

deciding what to build...No other part of the work so cripples
the resulting system if done wrong. No other part is difficult
to rectify later
Fred Brooks
25
Examples of Requirements - 1
The system shall maintain records of all payments made to

employees on accounts of salaries, bonuses, travel/daily
allowances, medical allowances, etc.
26
The system shall interface with the central computer to send

daily sales and inventory data from every retail store
27
The system shall maintain records of all library materials

including books, serials, newspapers and magazines, video
and audio tapes, reports, collections of transparencies, CD-
ROMs, DVDs, etc.
28
The system shall allow users to search for an item by title,

author, or by International Standard Book Number (ISBN)
The systems user interface shall be implemented using a

web browser
29
The system shall support at least twenty transactions per

second
The system facilities which are available to public users shall

be demonstrable in ten minutes or less
30
Kinds of Software Requirements

Kinds of Software Requirements
Functional requirements
Non-functional requirements
Domain requirements
Inverse requirements
Design and implementation constraints
32
Functional Requirements

Functional Requirements - 1
Statements describing what the system does
Functionality of the system
34
Statements of services the system should provide

Reaction to particular inputs
Behavior in particular situations
35
Sequencing and parallelism are also captured by functional

requirements
Abnormal behavior is also documented as functional

requirements in the form of exception handling
36
Functional requirements should be complete and consistent
Customers and developers usually focus all their attention on

functional requirements
37
Functional Requirements Example # 1
The system shall solve a quadratic equation using the

following formula
x = (-b+sqrt(b2 4*a*c))/2*a
38
The user shall be able to search either the entire database of

patients or select a subset from it (admitted patients, or
patients with asthma, etc.)
39
The system shall provide appropriate viewers for the user to

read documents in the document store
40
Every order shall be allocated a unique identifier

(ORDER_ID) which the user shall use to access that order
41
The system shall allow customers to return non-perishable

items within fifteen days of the purchase. A customer must
present the original sale receipt to return an item
42
Comments on Examples
Notice the level of detail in different requirements described

above. Some are very detailed compared to others
43
Notice the ambiguity in the requirement, which uses the term

appropriate viewers
This requirement does not mention the formats of documents

and types of viewers, which can be used
44
Notice the ambiguity in the requirement for solving the

quadratic equation. The requirement does not speak about
the possibility when the value of a is zero
x = (-b+sqrt(b2 4*a*c))/2*a
45
Incomplete and ambiguous requirements are open to

multiple interpretations and assumptions
This can lead to the development of poor quality, or faulty,

software products
46
Summary
Requirements form the basis of all software engineering

projects
Functional requirements capture the behavioral
aspects/functions of the proposed automated system
Functional requirements are the backbone of all software
products
47
References
Requirements Engineering: Processes and

Techniques by G. Kotonya and I.
Sommerville, John Wiley & Sons, 1998
Software Requirements: Objects, Functions,
and States by A. Davis, PH, 1993
Software Engineering 6th Edition, by I.
Sommerville, 2000
Software Engineering 5th Edition, by R.
Pressman
48

Sre 2

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Sre 2

Încărcat de

Drepturi de autor:

Formate disponibile

Software Requirement Engineering (CSE-305)

1 COMSATS Institute of Information Technology, Attock Muhammad Fawad

2 COMSATS Institute of Information Technology, Attock Muhammad Fawad

The proverb owning a hammer doesnt make one an

3 COMSATS Institute of Information Technology, Attock Muhammad Fawad

It emphasizes on finding requirements and problems rather

4 COMSATS Institute of Information Technology, Attock Muhammad Fawad

Use case consists of a paragraph or so text that presents a

5 COMSATS Institute of Information Technology, Attock Muhammad Fawad

6 COMSATS Institute of Information Technology, Attock Muhammad Fawad

Persona is an imaginary story in which the importance of the

7 COMSATS Institute of Information Technology, Attock Muhammad Fawad

It emphasizes on the conceptual solution in software or

8 COMSATS Institute of Information Technology, Attock Muhammad Fawad

In OOA there is an emphasis on finding and describing

9 COMSATS Institute of Information Technology, Attock Muhammad Fawad

It is the most critical activity

This activity has to be performed either while drawing UML

It strongly influences the robustness, maintainability and

10 COMSATS Institute of Information Technology, Attock Muhammad Fawad

UML is a standard diagramming notation

11 COMSATS Institute of Information Technology, Attock Muhammad Fawad

Use case diagram

12 COMSATS Institute of Information Technology, Attock Muhammad Fawad

13 COMSATS Institute of Information Technology, Attock Muhammad Fawad

Given the requirements and possible activities that are to be

14 COMSATS Institute of Information Technology, Attock Muhammad Fawad

15 COMSATS Institute of Information Technology, Attock Muhammad Fawad

Requirements form the basis for all software products

Requirements engineering is the process, which enables us

Something required, something wanted or needed

A complete description of what the software system will do

Software requirements are complete specification of the

They also represent External behavior of the system

Software requirements may be:

Software requirements may be:

A condition or capability that must be met or possessed by a

The hardest single part of building a software system is

The system shall maintain records of all payments made to

The system shall interface with the central computer to send

The system shall maintain records of all library materials

The system shall allow users to search for an item by title,

The systems user interface shall be implemented using a

The system shall support at least twenty transactions per

The system facilities which are available to public users shall

31 COMSATS Institute of Information Technology, Attock Muhammad Fawad

33 COMSATS Institute of Information Technology, Attock Muhammad Fawad

Statements describing what the system does

Functionality of the system

Statements of services the system should provide

Sequencing and parallelism are also captured by functional

Abnormal behavior is also documented as functional

Functional requirements should be complete and consistent

Customers and developers usually focus all their attention on

The system shall solve a quadratic equation using the

The user shall be able to search either the entire database of

The system shall provide appropriate viewers for the user to

Every order shall be allocated a unique identifier

The system shall allow customers to return non-perishable

Notice the level of detail in different requirements described

Notice the ambiguity in the requirement, which uses the term

This requirement does not mention the formats of documents

Notice the ambiguity in the requirement for solving the