Bharati Vidyapeeth's College of

Engineering, New Delhi

Lab Manual

For

Object Oriented Software Engineering

ETCS-456

SEMESTER : 8th
Aim1: Feasibility Study of the Project

Theory:
Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of an existing
business or proposed venture, opportunities and threats present in the environment, the resources required to
carry through, and ultimately the prospects for success. In its simplest terms, the two criteria to judge
feasibility are cost required and value to be attained.

A well-designed feasibility study should provide a historical background of the business or project, a
description of the product or service, accounting statements, details of the
operations and management, marketing research and policies, financial data, legal requirements and tax
obligations. Generally, feasibility studies precede technical development and project implementation.

A feasibility study evaluates the project's potential for success; therefore, perceived objectivity is an
important factor in the credibility of the study for potential investors and lending institutions. It must
therefore be conducted with an objective, unbiased approach to provide information upon which decisions
can be based

Feasibility study
Common factors
The acronym TELOS refers to the five areas of feasibility - Technical, Economic, Legal, Operational,
and Scheduling.

Technology and system feasibility

The assessment is based on an outline design of system requirements, to determine whether the company
has the technical expertise to handle completion of the project. When writing a feasibility report, the
following should be taken to consideration:

 A brief description of the business to assess more possible factors which could affect the study 
The part of the business being examined
 The human and economic factor
 The possible solutions to the problem

At this level, the concern is whether the proposal is both technically and legally feasible (assuming moderate
cost).

Legal Feasibility

Determines whether the proposed system conflicts with legal requirements, e.g. a data processing system
must comply with the local Data Protection Acts.
Operational Feasibility

Operational feasibility is a measure of how well a proposed system solves the problems, and takes advantage
of the opportunities identified during scope definition and how it satisfies the requirements identified in the
requirements analysis phase of system developmen.

The operational feasibility assessment focuses on the degree to which the proposed development projects
fits in with the existing business environment and objectives with regard to development schedule, delivery
date, corporate culture, and existing business processes.

To ensure success, desired operational outcomes must be imparted during design and development. These
include such design-dependent parameters such as reliability, maintainability, supportability, usability,
producibility, disposability, sustainability, affordability and others. These parameters are required to be
considered at the early stages of design if desired operational behaviours are to be realized. A system design
and development requires appropriate and timely application of engineering and management efforts to
meet the previously mentioned parameters. A system may serve its intended purpose most effectively when
its technical and operating characteristics are engineered into the design. Therefore operational feasibility is a
critical aspect of systems engineering that needs to be an integral part of the early design phases

Economic Feasibility

The purpose of the economic feasibility assessment is to determine the positive economic benefits to the
organization that the proposed system will provide. It includes quantification and identification of all the
benefits expected. This assessment typically involves a cost/ benefits analysis.

Technical Feasibility

The technical feasibility assessment is focused on gaining an understanding of the present technical
resources of the organization and their applicability to the expected needs of the proposed system. It is an
evaluation of the hardware and software and how it meets the need of the proposed system

Schedule Feasibility

A project will fail if it takes too long to be completed before it is useful. Typically this means estimating
how long the system will take to develop, and if it can be completed in a given time period using some
methods like payback period. Schedule feasibility is a measure of how reasonable the project timetable is.
Given our technical expertise, are the project deadlines reasonable? Some projects are initiated with specific
deadlines. It is necessary to determine whether the deadlines are mandatory or desirable.

Other feasibility
factors[edit] Market and real
estate feasibility

Market feasibility studies typically involve testing geographic locations for a real estate development project,
and usually involve parcels of real estate land. Developers often conduct market studies to determine the
best location within a jurisdiction, and to test alternative land uses for given parcels. Jurisdictions often
require developers to complete feasibility studies before they will approve a permit application for retail,
commercial, industrial, manufacturing, housing, office or mixed-use project. Market Feasibility takes into
account the importance of the business in the selected area.

Resource feasibility

This involves questions such as how much time is available to build the new system, when it can be built,
whether it interferes with normal business operations, type and amount of resources required,
dependencies, and developmental procedures with company revenue prospectus.

Cultural feasibility

In this stage, the project's alternatives are evaluated for their impact on the local and general culture. For
example, environmental factors need to be considered and these factors are to be well known. Further an
enterprise's own culture can clash with the results of the project.

Financial feasibility study

In case of a new project, financial viability can be judged on the following parameters:

 Total estimated cost of the project

 Financing of the project in terms of its capital structure, debt equity ratio and promoter's share of
total cost
 Existing investment by the promoter in any other business
 Projected cash flow and profitability

The financial viability of a project should provide the following information:[citation needed]

 Full details of the assets to be financed and how liquid those assets are.
 Rate of conversion to cash-liquidity (i.e. how easily can the various assets be converted to cash?).
 Project's funding potential and repayment terms.
 Sensitivity in the repayments capability to the following factors:
 Time delays.
 Mild slowing of sales.
 Acute reduction/slowing of sales.
 Small increase in cost.
 Large increase in cost.
 Adverse economic conditions.
Market research study and analysis
This is one of the most important sections of the feasibility study as it examines the marketability of the
product or services and convinces readers that there is a potential market for the product or service. If a
significant market for the product or services cannot be established, then there is no project.
Typically, market studies will assess the potential sales of the product, absorption and market capture rates
and the project's timing

The feasibility study outputs the feasibility study report, a report detailing the evaluation criteria, the study
findings, and the recommendations.
Aim2: Software Requirements Specification (SRS) of the Project

Theory:

A software requirements specification (SRS) is a comprehensive description of the intended

purpose and environment for software under development. The SRS fully describes what the
software will do and how it will be expected to perform.

An SRS minimizes the time and effort required by developers to achieve desired goals and also
minimizes the development cost. A good SRS defines how anapplication will interact with
systemhardware, other programs and human users in a wide variety of real-world situations.
Parameters such as operating speed, response time, availability, portability,
maintainability, footprint, security and speed of recovery from adverse events are evaluated.
Methods of defining an SRS are described by the IEEE(Institute of Electrical and Electronics
Engineers) specification 830-1998.

The following annotated template shall be used to complete the Software Requirements
Specification (SRS) assignment. The instructor must approve any modifications to the overall
structure of this document.

Template Usage:
Text contained within angle brackets (‘<’, ‘>’) shall be replaced by your project-specific
information and/or details. For example, <Project Name> will be replaced with either ‘Smart
Home’ or ‘Sensor Network’.

Italicized text is included to briefly annotate the purpose of each section within this template.
This text should not appear in the final version of your submitted SRS.

This cover page is not a part of the final template and should be removed before your SRS is
submitted.

Acknowledgements:
Sections of this document are based upon the IEEE Guide to Software Requirements
Specification (ANSI/IEEE Std. 830-1984). .
 <Project Name>

Software Requirements Specification

<Version>
<Date>

<Your Name>
Software Engineer
Revision History
Date Description Author Comments
<date> <Version 1> <Your Name> <First Revision>

Document Approval
The following Software Requirements Specification has been accepted and approved by the
following:
Signature Printed Name Title Date
<Your Name>

Page ii
Table of Contents

REVISION HISTORY ...............................................................................................................................................II

DOCUMENT APPROVAL .......................................................................................................................................II
1. INTRODUCTION ...................................................................................................................................................5
1.1
PURPOSE ..............................................................................................................................................................5
1.2
SCOPE ..................................................................................................................................................................5
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ................................................................................................5
1.4
REFERENCES ........................................................................................................................................................5
1.5
OVERVIEW ...........................................................................................................................................................6
2. GENERAL DESCRIPTION...................................................................................................................................6
3. SPECIFIC REQUIREMENTS...............................................................................................................................7
3.1 EXTERNAL INTERFACE REQUIREMENTS ...............................................................................................................7
3.1.1 User Interfaces............................................................................................................................................7
3.1.2 Hardware Interfaces ...................................................................................................................................7
3.1.3 Software Interfaces......................................................................................................................................7
3.1.4 Communications Interfaces.........................................................................................................................7
3.2 FUNCTIONAL REQUIREMENTS ..............................................................................................................................7
3.2.1 <Functional Requirement or Feature #1> .................................................................................................7
3.2.2 <Functional Requirement or Feature #2> .................................................................................................7
3.3 USE CASES ...........................................................................................................................................................8
3.3.1 Use Case #1 ................................................................................................................................................8
3.3.2 Use Case #2 ................................................................................................................................................8
3.4 CLASSES / OBJECTS..............................................................................................................................................8
3.4.1 <Class / Object #1>....................................................................................................................................8
3.4.2 <Class / Object #2>....................................................................................................................................8
3.5 NON-FUNCTIONAL REQUIREMENTS .....................................................................................................................8
3.5.1 Performance................................................................................................................................................8
3.5.2 Reliability ....................................................................................................................................................8
3.5.3 Availability ..................................................................................................................................................8
3.5.4 Security .......................................................................................................................................................8
3.5.5 Maintainability............................................................................................................................................8
3.5.6 Portability ...................................................................................................................................................8
3.6 INVERSE REQUIREMENTS .....................................................................................................................................8
3.7 DESIGN CONSTRAINTS .........................................................................................................................................9
3.8 LOGICAL DATABASE REQUIREMENTS ..................................................................................................................9
3.9 OTHER REQUIREMENTS .......................................................................................................................................9
4. ANALYSIS MODELS.............................................................................................................................................9
4.1 SEQUENCE
DIAGRAMS .........................................................................................................................................9 4.3 DATA
FLOW DIAGRAMS (DFD) ...........................................................................................................................9 4.2
STATE-TRANSITION DIAGRAMS (STD) ................................................................................................................9
5. CHANGE MANAGEMENT PROCESS ...............................................................................................................9
A. APPENDICES.........................................................................................................................................................9

Page iii
A.1 APPENDIX 1.........................................................................................................................................................9
A.2 APPENDIX 2.................................................................................................ERROR! BOOKMARK NOT DEFINED.

Page iv
1. Introduction
The introduction to the Software Requirement Specification (SRS) document should
provide an overview of the complete SRS document. While writing this document please
remember that this document should contain all of the information needed by a software
engineer to adequately design and implement the software product described by the
requirements listed in this document. (Note: the following subsection annotates are
largely taken from the IEEE Guide to SRS).

1.1 Purpose
What is the purpose of this SRS and the (intended) audience for which it is written.

1.2 Scope
This subsection should:
(1) Identify the software product(s) to be produced by name; for example, Host DBMS,
Report Generator, etc
(2) Explain what the software product(s) will, and, if necessary, will not do
(3) Describe the application of the software being specified. As a portion of this, it
should:
(a) Describe all relevant benefits, objectives, and goals as precisely as possible. For
example, to say that one goal is to provide effective reporting capabilities is not
as good as saying parameter-driven, user-definable reports with a 2 h turnaround
and on-line entry of user parameters.
(b) Be consistent with similar statements in higher-level specifications (for example,
the System Requirement Specification) , if they exist.What is the scope of this
software product.

1.3 Definitions, Acronyms, and Abbreviations

This subsection should provide the definitions of all terms, acronyms, and abbreviations
required to properly interpret the SRS. This information may be provided by reference to
one or more appendixes in the SRS or by reference to other documents.

1.4 References
This subsection should:
(1) Provide a complete list of all documents referenced elsewhere in the SRS, or in a
separate, specified document.
(2) Identify each document by title, report number - if applicable - date, and publishing
organization.
(3) Specify the sources from which the references can be obtained.
This information may be provided by reference to an appendix or to another document.

Page 5
 <Project Name>

1.5 Overview
This subsection should:
(1) Describe what the rest of the SRS contains
(2) Explain how the SRS is organized.

2. General Description
This section of the SRS should describe the general factors that affect 'the product and its
requirements. It should be made clear that this section does not state specific
requirements; it only makes those requirements easier to understand.

2.1 Product Perspective

This subsection of the SRS puts the product into perspective with other related products
or
projects. (See the IEEE Guide to SRS for more details).

2.2 Product Functions

This subsection of the SRS should provide a summary of the functions that the software
will perform.

2.3 User Characteristics

This subsection of the SRS should describe those general characteristics of the eventual
users of the product that will affect the specific requirements. (See the IEEE Guide to
SRS for more details).

2.4 General Constraints

This subsection of the SRS should provide a general description of any other items that
will
limit the developer’s options for designing the system. (See the IEEE Guide to SRS for a
partial list of possible general constraints).

2.5 Assumptions and Dependencies

This subsection of the SRS should list each of the factors that affect the requirements
stated in the SRS. These factors are not design constraints on the software but are,
rather, any changes to them that can affect the requirements in the SRS. For example, an
assumption might be that a specific operating system will be available on the hardware
designated for the software product. If, in fact, the operating system is not available, the
SRS would then have to change accordingly.

Page 6
 <Project Name>

3. Specific Requirements
This will be the largest and most important section of the SRS. The customer
requirements will be embodied within Section 2, but this section will give the D-
requirements that are used to guide the project’s software design, implementation, and
testing.

Each requirement in this section should be:

 Correct
 Traceable (both forward and backward to prior/future artifacts)
 Unambiguous
 Verifiable (i.e., testable)
 Prioritized (with respect to importance and/or stability)
 Complete
 Consistent
 Uniquely identifiable (usually via numbering like 3.4.5.6)

Attention should be paid to the carefuly organize the requirements presented in this
section so that they may easily accessed and understood. Furthermore, this SRS is not
the software design document, therefore one should avoid the tendency to over-constrain
(and therefore design) the software project within this SRS.

3.1 External Interface Requirements

3.1.1 User Interfaces

3.1.2 Hardware Interfaces

3.1.3 Software Interfaces

3.1.4 Communications Interfaces

3.2 Functional Requirements

This section describes specific features of the software project. If desired, some
requirements may be specified in the use-case format and listed in the Use Cases Section.

3.2.1 <Functional Requirement or Feature #1>

3.2.1.1 Introduction
3.2.1.2 Inputs
3.2.1.3 Processing
3.2.1.4 Outputs
3.2.1.5 Error Handling

3.2.2 <Functional Requirement or Feature #2>

Page 7
 <Project Name>

3.3 Use Cases

3.3.1 Use Case #1

3.3.2 Use Case #2

3.4 Classes / Objects

3.4.1 <Class / Object #1>

3.4.1.1 Attributes
3.4.1.2 Functions
<Reference to functional requirements and/or use cases>

3.4.2 <Class / Object #2>

3.5 Non-Functional Requirements

Non-functional requirements may exist for the following attributes. Often these
requirements must be achieved at a system-wide level rather than at a unit level. State
the requirements in the following sections in measurable terms (e.g., 95% of transaction
shall be processed in less than a second, system downtime may not exceed 1 minute per
day, > 30 day MTBF value, etc).

3.5.1 Performance

3.5.2 Reliability

3.5.3 Availability

3.5.4 Security

3.5.5 Maintainability

3.5.6 Portability

3.6 Inverse Requirements

Software Requirements Specification Page 8
 <Project Name>

State any *useful* inverse requirements.

3.7 Design Constraints

Specify design constrains imposed by other standards, company policies, hardware
limitation, etc. that will impact this software project.

3.8 Logical Database Requirements

Will a database be used? If so, what logical requirements exist for data formats, storage
capabilities, data retention, data integrity, etc.

3.9 Other Requirements

Catchall section for any additional requirements.

4. Analysis Models
List all analysis models used in developing specific requirements previously given in this
SRS. Each model should include an introduction and a narrative description.
Furthermore, each model should be traceable the SRS’s requirements.

4.1 Sequence Diagrams

4.3 Data Flow Diagrams (DFD)
4.2 State-Transition Diagrams (STD)
5. Change Management Process
Identify and describe the process that will be used to update the SRS, as needed, when
project scope or requirements change. Who can submit changes and by what means, and
how will these changes be approved.

A. Appendices
Appendices may be used to provide additional (and hopefully helpful) information. If
present, the SRS should explicitly state whether the information contained within an
appendix is to be considered as a part of the SRS’s overall set of requirements.

Example Appendices could include (initial) conceptual documents for the software
project, marketing materials, minutes of meetings with the customer(s), etc.

A.1 Appendix 1

Software Requirements Specification Page 9

 <Project Name>

Aim3:UseCase Diagram of the Project

Theory:

What is a UML Use Case Diagram?

Use case diagrams model the functionality of a system using actors and use cases. Use cases are services or functions provided by
the system to its users.

Basic Use Case Diagram Symbols and Notations

System

Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the system's boundaries.

Use Case

Draw use cases using ovals. Label with ovals with verbs that represent the system's functions.

Actors

Actors are the users of a system. When one system is the actor of another system, label the actor system with the actor stereotype.

Page 10
 <Project Name>

Relationships
Illustrate relationships between an actor and a use case with a simple line. For relationships among use cases, use arrows labeled either
"uses" or "extends." A "uses" relationship indicates that one use case is needed by another in order to perform a task. An "extends"
relationship indicates alternative options under a certain use case.

Page 11
 <Project Name>

Aim4:Class Diagram of the Project

Theory:
What is a UML Class Diagram?
Class diagrams are the backbone of almost every object-oriented method including UML. They describe the static structure
of a system.

Basic Class Diagram Symbols and Notations

Classes represent an abstraction of entities with common characteristics. Associations represent the relationships between classes.

Illustrate classes with rectangles divided into compartments. Place the name of the class in the first partition (centered, bolded, and
capitalized), list the attributes in the second partition, and write operations into the third.

Active Class

Active classes initiate and control the flow of activity, while passive classes store data and serve other classes. Illustrate active
classes with a thicker border.

Visibility
Use visibility markers to signify who can access the information contained within a class. Private visibility hides
information from anything outside the class partition. Public visibility allows all other classes to view the marked
information. Protected visibility allows child classes to access information they inherited from a parent class.

Associations
Associations represent static relationships between classes. Place association names above, on, or below the association line. Use a
filled arrow to indicate the direction of the relationship. Place roles near the end of an association. Roles represent the way the two
classes see each other.

Page 12
 <Project Name>

Note: It's uncommon to name both the association and the class roles.

Multiplicity (Cardinality)

Place multiplicity notations near the ends of an association. These symbols indicate the number of instances of one class linked to
one instance of the other class. For example, one company will have one or more employees, but each employee works for one
company only.

Constraint

Place constraints inside curly braces {}.

Simple Constraint

Composition and Aggregation

Composition is a special type of aggregation that denotes a strong ownership between Class A, the whole, and Class B, its part.
Illustrate composition with a filled diamond. Use a hollow diamond to represent a simple aggregation relationship, in which the
"whole" class plays a more important role than the "part" class, but the two classes are not dependent on each

Page 13
 <Project Name>

other. The diamond end in both a composition and aggregation relationship points toward the "whole" class or the aggregate.

Generalization

Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship between two classes where one class
is a specialized version of another. For example, Honda is a type of car. So the class Honda would have a generalization relationship
with the class car.

In real life coding examples, the difference between inheritance and aggregation can be confusing. If you have an aggregation
relationship, the aggregate (the whole) can access only the PUBLIC functions of the part class. On the other hand, inheritance allows
the inheriting class to access both the PUBLIC and PROTECTED functions of the superclass.

Page 14
 <Project Name>

Aim5:Activity Diagram of the Project

Theory:
What is a UML Activity Diagram?
An activity diagram illustrates the dynamic nature of a system by modeling the flow of control from activity to activity. An activity
represents an operation on some class in the system that results in a change in the state of the system. Typically, activity diagrams are
used to model workflow or business processes and internal operation. Because an activity diagram is a special kind of statechart
diagram, it uses some of the same modeling conventions.

Basic Activity Diagram Symbols and Notations

Action states

Action states represent the noninterruptible actions of objects. You can draw an action state in SmartDraw using a rectangle
with rounded corners.

Action Flow
Action flow arrows illustrate the relationships among action states.

Object Flow
Object flow refers to the creation and modification of objects by activities. An object flow arrow from an action to an object means
that the action creates or influences the object. An object flow arrow from an object to an action indicates that the action state uses
the object.

Page 15
 <Project Name>

Initial State

A filled circle followed by an arrow represents the initial action state.

Final State

An arrow pointing to a filled circle nested inside another circle represents the final action state.

Branching

A diamond represents a decision with alternate paths. The outgoing alternates should be labeled with a condition or guard
expression. You can also label one of the paths "else."

Synchronization

A synchronization bar helps illustrate parallel transitions. Synchronization is also called forking and joining.

Swimlanes
Swimlanes group related activities into one column.

Page 16
<Project Name>

Page 17
 <Project Name>

Aim6:Sequence Diagram of the Project

Theory:
What is a UML Sequence Diagram?
Sequence diagrams describe interactions among classes in terms of an exchange of messages over time.

Basic Sequence Diagram Symbols and Notations

Class roles
Class roles describe the way an object will behave in context. Use the UML object symbol to illustrate class roles, but don't list
object attributes.

Activation

Activation boxes represent the time an object needs to complete a task.

Messages
Messages are arrows that represent communication between objects. Use half-arrowed lines to represent asynchronous messages.
Asynchronous messages are sent from an object that will not wait for a response from the receiver before continuing its tasks.

Page 18
 <Project Name>

Various message types for Sequence and Collaboration diagrams

Lifelines
Lifelines are vertical dashed lines that indicate the object's presence over time.

Destroying Objects

Objects can be terminated early using an arrow labeled "<< destroy >>" that points to an X.

Page 19
 <Project Name>

Loops
A repetition or loop within a sequence diagram is depicted as a rectangle. Place the condition for exiting the loop at the bottom left
corner in square brackets [ ].

Page 20
 <Project Name>

Aim6: Collaboration Diagram of the Project

Theory:
What is a UML Collaboration Diagram?
A collaboration diagram describes interactions among objects in terms of sequenced messages. Collaboration diagrams represent a
combination of information taken from class, sequence, and use case diagrams describing both the static structure and dynamic
behavior of a system.

Basic Collaboration Diagram Symbols and Notations

Class roles

Class roles describe how objects behave. Use the UML object symbol to illustrate class roles, but don't list object attributes.

Association roles
Association roles describe how an association will behave given a particular situation. You can draw association roles using
simple lines labeled with stereotypes.

Messages
Unlike sequence diagrams, collaboration diagrams do not have an explicit way to denote time and instead number messages in order
of execution. Sequence numbering can become nested using the Dewey decimal system. For example, nested messages under the first
message are labeled 1.1, 1.2, 1.3, and so on. The a condition for a message is usually placed in square brackets immediately following
the sequence number. Use a * after the sequence number to indicate a loop.

Page 21
 <Project Name>

Aim7: StateChart Diagram of the Project

Theory:
What is a UML Statechart Diagram?
A statechart diagram shows the behavior of classes in response to external stimuli. This diagram models the dynamic flow of control
from state to state within a system.

Basic Statechart Diagram Symbols and Notations

States

States represent situations during the life of an object. You can easily illustrate a state in SmartDraw by using a rectangle with rounded
corners.

Transition
A solid arrow represents the path between different states of an object. Label the transition with the event that triggered it and the
action that results from it.

Initial State
A filled circle followed by an arrow represents the object's initial state.

Final State

An arrow pointing to a filled circle nested inside another circle represents the object's final state.

Synchronization and Splitting of Control

A short heavy bar with two transitions entering it represents a synchronization of control. A short heavy bar with two transitions
leaving it represents a splitting of control that creates multiple states.

Page 22
<Project Name>

Page 23
 <Project Name>

Aim9: Component Diagram of the Project

Theory:
What is a UML Component Diagram?
A component diagram describes the organization of the physical components in a system.

Basic Component Diagram Symbols and Notations

Component
A component is a physical building block of the system. It is represented as a rectangle with tabs.

Interface

An interface describes a group of operations used or created by components.

Dependencies
Draw dependencies among components using dashed arrows.

Page 24
 <Project
Name>

Aim10: Deployment Diagram of the Project

Theory:
What is a UML Deployment Diagram?
Deployment diagrams depict the physical resources in a system including nodes, components, and
connections.

Basic Deployment Diagram Symbols and Notations

Component
A node is a physical resource that executes code components.

Association
Association refers to a physical connection between nodes, such as Ethernet.

Components and Nodes

Place components inside the node that deploys them.