Fundamental of S/W Development SUBCODE: -3341603

Practical -1

AIM: - Identify the development model for software with proper

explanation
General Description:3

After analysis of all models through the various factors, it has been found that the original
water fall model is used by various big companies for their internal projects. Since the
development team is familiar to the environment and it is feasible to specify all requirements of
working environment. Iterative model overcome the drawback of original waterfall model. It
allows feedback to proceeding stage. Prototype model used to develop online systems for
transaction processing. Since significantly reduce rework and lead to the creation of working
model in lower capital cost. Spiral model is used for development of large, complicated and
expensive projects like scientific Projects .Since spiral model approach enables the project term
to address the highest risk at the lowest total cost.

Choosing process model

The selection of process model for a software project is a tedious task. There are many
factors affecting the optimal choice of software process framework for a process. When selecting
a process model, one must carefully assess the context of the project:

 Is the project small or large in terms of effort, schedule, or business value?

 How much risk is involved in the project? What is the relative importance of this
project in comparison to other projects, and the overall activities of the company?
 How much changes can be anticipated? Is it possible to come up with stable,
definitive requirements for the project up-front, or do we have to work on
something, and rely on customer feedback for next steps?
 How many people are involved in the project, both directly and indirectly? How
competent are they? Are they familiar with the process we are planning to use?
 Is the whole team located at same room, floor, building? How are we going to
communicate during the project?

The selection of process model affects management of software project in several ways.
The pace and contents of interaction with the customer / end-user are highly affected by the
software process model in use. The roles used by software development organization should be
aligned with the software process model. Even the structure of the product to be developed must

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

match with the chosen organization and practices of the software project team.

Comparative
Prototyping
Analysis of Four Water fall Model Iterative Model Spiral Model
Model
Models Features
Requirement Beginning Beginning Frequently Beginning
Specification Changed
Understanding Well Understood Not Well Not Well Well Understood
Requirements understood understood
Cost Low Low High Expensive
Availability of No Yes yes yes
reusable component
Complexity of Simple simple complex complex
system
Risk Analysis Only at beginning No Risk Analysis No Risk yes
Analysis
User Involvement Only at beginning Intermediate High High
in all phases of
SDLC
Guarantee of Less High Good High
Success
Overlapping Phases No overlapping No Overlapping Yes Yes Overlapping
Overlapping
Implementation long Less Less Depends on
time project
Flexibility Rigid Less Flexible Highly Flexible
Flexible
Changes Difficult Easy Easy Easy
Incorporated
Expertise Required High High Medium High
Cost Control Yes No No Yes
Resource Control Yes Yes No Yes

[Comparisons of s/w Models]

SEMESTER –IV IT DEPARTMENT

 Practical -3

AIM: - Prepare SRS document for your system.

Software Requirements Specification for <Project> Page iii

Contents
<IN THIS TEMPLATE YOU WILL FIND TEXT BOUNDED BY THE “<>” SYMBOLS. THIS TEXT
APPEARS IN ITALICS AND IS INTENDED TO GUIDE YOU THROUGH THE TEMPLATE AND
PROVIDE EXPLANATIONS REGARDING THE DIFFERENT SECTIONS IN THIS DOCUMENT.
THERE ARE TWO TYPES OF COMMENTS IN THIS DOCUMENT. THESE COMMENTS THAT ARE
IN BLACK ARE INTENDED SPECIFICALLY FOR THAT COURSE. THESE COMMENTS THAT ARE
IN BLUE ARE MORE GENERAL AND APPLY TO ANY SRS. PLEASE, MAKE SURE TO DELETE ALL
OF THE COMMENTS BEFORE SUBMITTING THE DOCUMENT. ............................................................ III

THE EXPLANATIONS PROVIDED BELOW, DO NOT COVER ALL OF THE MATERIAL, BUT
MERELY, THE GENERAL NATURE OF THE INFORMATION YOU WOULD USUALLY FIND IN SRS
DOCUMENTS. IT IS BASED ON THE IEEE REQUIREMENTS AND WAS ADAPTED SPECIFICALLY
FOR THE NEEDS OF SOFTWARE ENGINEERING 3K04/3M04 COURSES. MOST OF THE SECTIONS
IN THIS TEMPLATE ARE REQUIRED SECTIONS, I.E. YOU MUST INCLUDE THEM IN YOUR
VERSION OF THE DOCUMENT. FAILURE TO DO SO WILL RESULT IN MARKS DEDUCTIONS.
OPTIONAL SECTIONS WILL BE EXPLICITLY MARKED AS OPTIONAL. .............................................. III

1 INTRODUCTION .................................................................................................................................................... 1

2 OVERALL DESCRIPTION .................................................................................................................................... 3

3 SPECIFIC REQUIREMENTS ................................................................................................................................ 5

4 OTHER NON-FUNCTIONAL REQUIREMENTS .............................................................................................. 7

5 OTHER REQUIREMENTS .................................................................................................................................... 8

Fundamental of S/W Development SUBCODE: -3341603

1 Introduction

1.1 Document Purpose

Identify the product whose software requirements are specified in this document, including the
revision or release number. Describe the scope of the product that is covered by this SRS,
particularly if this SRS describes only part of the system or a single subsystem.
TO DO: Write 1-2 paragraphs describing the purpose of this document as explained above.
1.2 Product Scope
Provide a short description of the software being specified and its purpose, including relevant
benefits, objectives, and goals.
TO DO: 1-2 paragraphs describing the scope of the product. Make sure to describe the benefits
associated with the product.
1.3 Intended Audience and Document Overview
Describe the different types of reader that the document is intended for, such as developers,
project managers, marketing staff, users, testers, and documentation writers (In your case it would
probably be the “client” and the professor). Describe what the rest of this SRS contains and how it
is organized. Suggest a sequence for reading the document, beginning with the overview sections
and proceeding through the sections that are most pertinent to each reader type.
1.4 Definitions, Acronyms and Abbreviations
Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project in each SRS.
TO DO: Please provide a list of all abbreviations and acronyms used in this document sorted in
alphabetical order.
1.5 Document Conventions
In general this document follows the IEEE formatting requirements. Use Arial font size 11, or 12
throughout the document for text. Use italics for comments. Document text should be single
spaced and maintain the 1” margins found in this template. For Section and Subsection titles
please follow the template.

TO DO: Describe any standards or typographical conventions that were followed when writing this
SRS, such as fonts or highlighting that have special significance. Sometimes, it is useful to divide
this section to several sections, e.g., Formatting Conventions, Naming Conventions, etc.
1.6 References and Acknowledgments
List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603
2 Overall Description

2.1 Product Perspective

Describe the context and origin of the product being specified in this SRS. For example, state
whether this product is a follow-on member of a product family, a replacement for certain existing
systems, or a new, self-contained product. If the SRS defines a component of a larger system,
relate the requirements of the larger system to the functionality of this software and identify
interfaces between the two. In this part, make sure to include a simple diagram that shows the
major components of the overall system, subsystem interconnections, and external interface. In
this section it is crucial that you will be creative and provide as much information as possible.

TO DO: Provide at least one paragraph describing product perspective. Provide a general diagram
that will illustrate how your product interacts with the environment and in what context it is being
used.

2.2 Product Functionality

Summarize the major functions the product must perform or must let the user perform. Details will
be provided in Section 3, so only a high level summary is needed here. Organize the functions to
make them understandable to any reader of the SRS. A picture of the major groups of related
requirements and how they relate, such as a top level data flow diagram or object class diagram,
will be effective.
TO DO:
1. Provide a bulleted list of all the major functions of the system
2. (Optional) Provide a Data Flow Diagram of the system to show how these functions relate to
each other.

2.3 Users and Characteristics

Identify the various users that you anticipate will use this product. Users may be differentiated
based on frequency of use, subset of product functions used, technical expertise, security or
privilege levels, educational level, or experience.
TO DO:
1. Describe the pertinent characteristics of each user. Certain requirements may pertain only to
certain users.
3. Distinguish the most important users for this product from those who are less important to
satisfy.

2.4 Operating Environment

Describe the environment in which the software will operate, including the hardware platform,
operating system and versions, and any other software components or applications with which it
must peacefully coexist. In this part, make sure to include a simple diagram that shows the major
components of the overall system, subsystem interconnections, and external interface
TO DO: As stated above, in at least one paragraph, describe the environment your system will
have to operate in. Make sure to include the minimum platform requirements for your system.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603
2.5 Design and Implementation Constraints
Describe any items or issues that will limit the options available to the developers. These might
include: hardware limitations (timing requirements, memory requirements); interfaces to other
applications; specific technologies, tools, and databases to be used; parallel operations; language
requirements; communications protocols; security considerations; design conventions or
programming standards (for example, if the customer’s organization will be responsible for
maintaining the delivered software).
TO DO: In this section you need to consider all of the information you gathered so far, analyze it
and correctly identify at least 5 constraints.

2.6 User Documentation

List the user documentation components (such as user manuals, on-line help, and tutorials) that
will be delivered along with the software. Identify any known user documentation delivery formats
or standards.
TO DO: You will not actually develop any user-manuals, but you need to describe what kind of
manuals and what kind of help is needed for the software you will be developing. One paragraph
should be sufficient for this section.

2.7 Assumptions and Dependencies

List any assumed factors (as opposed to known facts) that could affect the requirements stated in
the SRS. These could include third-party or commercial components that you plan to use, issues
around the development or operating environment, or constraints. The project could be affected if
these assumptions are incorrect, are not shared, or change. Also identify any dependencies the
project has on external factors, such as software components that you intend to reuse from
another project.
TO DO: Provide a short list of some major assumptions that might significantly affect your design.
For example, you can assume that your client will have 1, 2 or at most 50 Automated Banking
Machines. Every number has a significant effect on the design of your system.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603
3 Specific Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces

Describe the logical characteristics of each interface between the software product and the users.
This may include sample screen images, any GUI standards or product family style guides that are
to be followed, screen layout constraints, standard buttons and functions (e.g., Cancel) that will
appear on every screen, error message display standards, and so on. Define the software
components for which a user interface is needed.
TO DO: The least you can do for this section is to describe in words the different User Interfaces
and the different screens that will be available to the user. Those who will be able to provide
optional Graphical User Interface screenshots, will be rewarded by extra marks.

3.1.2 Hardware Interfaces

Describe the logical and physical characteristics of each interface between the software product
and the hardware components of the system. This may include the supported device types, the
nature of the data and control interactions between the software and the hardware. You are not
required to specify what protocols you will be using to communicate with the hardware, but it will
be usually included in this part as well.
TO DO: Please provide a short description of the different hardware interfaces. If you will be using
some special libraries to communicate with your software mention them here. In case you have
more than one hardware interface divide this section into subsections.

3.1.3 Software Interfaces

Describe the connections between this product and other specific software components (name
and version), including databases, operating systems (Windows? Linux? Etc…), tools, libraries,
and integrated commercial components. Identify the data items or messages coming into the
system and going out and describe the purpose of each. Describe the services needed and the
nature of communications. Identify data that will be shared across software components. If the
data sharing mechanism must be implemented in a specific way (for example, use of a global data
area in a multitasking operating system), specify this as an implementation constraint.

TO DO: The previous part illustrates some of the information you would usually include in this part
of the SRS document. To make things simpler, you are only required to describe the specific
interface with the operating system.

3.1.4 Communications Interfaces

Describe the requirements associated with any communications functions required by this product,
including e-mail, web browser, network server communications protocols, electronic forms, and so
on. Define any pertinent message formatting. Identify any communication standards that will be
used, such as FTP or HTTP. Specify any communication security or encryption issues, data
transfer rates, and synchronization mechanisms.

TO DO: Do not go into too much detail, but provide 1-2 paragraphs were you will outline the major
communication standards. For example, if you decide to use encryption there is no need to specify
the exact encryption standards, but rather, specify the fact that the data will be encrypted and
name what standards you consider using.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

3.2 Functional Requirements

Functional requirements capture the intended behavior of the system. This behavior may be
expressed as services, tasks or functions the system is required to perform. This section is the
direct continuation of section 2.2 where you have specified the general functional requirements.
Here, you should list in detail the different product functions with specific explanations regarding
every function.

TO DO: Brake the functional requirements to several functional areas and divide this section into
subsections accordingly. Provide a detailed list of all product operations related to these functional
areas.

3.3 Behaviour Requirements

3.3.1 Use Case View

A use case defines a goal-oriented set of interactions between external actors and the system
under consideration. Since sometimes we will not be able to specify completely the behaviour of
the system by just State Diagrams, we use use-cases to complete what we have already started in
section 3.3.1.

TO DO: Provide a use case diagram which will encapsulate the entire system and all possible
actors. Do not include detailed use case descriptions (these will be needed when you will be
working on the Test Plan), but make sure to include a short description of what every use-case is,
who are the actors in your diagram. For more information please refer to your UML guide and the
MiniThermostat SRS example file.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603
4 Other Non-functional Requirements

4.1 Performance Requirements

If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make suitable
design choices. Specify the timing relationships for real time systems. Make such requirements as
specific as possible. You may need to state performance requirements for individual functional
requirements or features.
TODO: Provide at least 5 different performance requirements based on the information you
collected from the client. For example you can say “1. Any transaction will not take more than 10
seconds, etc…

4.2 Safety and Security Requirements

Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well as
actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the product’s design or use. Define any safety certifications that must be
satisfied. Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product. Define any user identity
authentication requirements.
TODO:
 Provide at least 3 different safety requirements based on your interview with the client or,
on your ABM related research, and again you need to be creative here.
 Describe briefly what level of security is expected from this product by your client and
provide a bulleted (or numbered) list of the major security requirements.

4.3 Software Quality Attributes

Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability,
and usability. Write these to be specific, quantitative, and verifiable when possible. At the least,
clarify the relative preferences for various attributes, such as ease of use over ease of learning.

TODO: Use subsections (e.g., 4.3.1 Reliability, 4.3.2 Portability, etc…) provide requirements
related to the different software quality attributes. Base the information you include in these
subsections on the material you have learned in the class. Make sure, that you do not just write
“This software shall be maintainable…” Indicate how you plan to achieve it, & etc…Do not forget to
include such attributes as the design for change. Please note that you need to include at least 2
quality attributes, but it is the mere minimum and it will not receive the full marks.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603
5 Other Requirements
This section is Optional. Define any other requirements not covered elsewhere in the SRS. This
might include database requirements, internationalization requirements, legal requirements, reuse
objectives for the project, and so on. Add any new sections that are pertinent to the project.

Appendix A – Data Dictionary

Data dictionary is used to track all the different variables, states and functional requirements that
you described in your document. Make sure to include the complete list of all constants, state
variables (and their possible states), inputs and outputs in a table. In the table, include the
description of these items as well as all related operations and requirements.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Practical -4

AIM:- Design Activity Diagram for system

General Description:

UML is a standard language for specifying, visualizing, constructing, and documenting the
artifacts of software systems.

UML was created by Object Management Group (OMG) and UML 1.0 specification draft was
proposed to the OMG in January 1997.

OMG is continuously putting effort to make a truly industry standard.

 UML stands for Unified Modeling Language.

 UML is different from the other common programming languages like C++, Java,
COBOL etc.
 UML is a pictorial language used to make software blue prints.

So UML can be described as a general purpose visual modeling language to visualize, specify,
construct and document software system. Although UML is generally used to model software
systems but it is not limited within this boundary. It is also used to model non software systems
as well like process flow in a manufacturing unit etc.

UML is not a programming language but tools can be used to generate code in various languages
using UML diagrams. UML has a direct relation with object oriented analysis and design.

Goals of UML:

A picture is worth a thousand words, this absolutely fits while discussing about UML. Object
oriented concepts were introduced much earlier than UML. So at that time there were no
standard methodologies to organize and consolidate the object oriented development.

There are a number of goals for developing UML but the most important is to define some
general purpose modeling language which all modelers can use and also it needs to be made
simple to understand and use.

UML diagrams are not only made for developers but also for business users, common people and
anybody interested to understand the system. The system can be a software or non software. So it
must be clear that UML is not a development method rather it accompanies with processes to
make a successful system.

At the conclusion the goal of UML can be defined as a simple modeling mechanism to model all
possible practical systems in today’s complex environment

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Overview of Activity diagram:

Activity diagram is one of the important diagram in UML to describe dynamic aspects of the
system.

Activity diagram is basically a flow chart to represent the flow form one activity to another
activity. The activity can be described as an operation of the system.

So the control flow is drawn from one operation to another. This flow can be sequential,
branched or concurrent. Activity diagrams deals with all type of flow control by using different
elements like fork, join etc.

Purpose:

The basic purposes of activity diagrams are similar to other four diagrams. It captures the
dynamic behavior of the system. Other four diagrams are used to show the message flow from
one object to another but activity diagram is used to show message flow from one activity to
another.

Activity is a particular operation of the system. Activity diagrams are not only used for
visualizing dynamic nature of a system but they are also used to construct the executable system
by using forward and reverse engineering techniques. The only missing thing in activity diagram
is the message part.

It does not show any message flow from one activity to another. Activity diagram is some time
considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows
different flow like parallel, branched, concurrent and single.

So the purposes can be described as:

 Draw the activity flow of a system.

 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.

How to draw Activity Diagram?

Activity diagrams are mainly used as a flow chart consists of activities performed by the system.
But activity diagram are not exactly a flow chart as they have some additional capabilities. These
additional capabilities include branching, parallel flow, swimlane etc.

Before drawing an activity diagram we must have a clear understanding about the elements used
in activity diagram. The main element of an activity diagram is the activity itself. An activity is a
function performed by the system. After identifying the activities we need to understand how
they are associated with constraints and conditions.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

So before drawing an activity diagram we should identify the following elements:

 Activities
 Association
 Conditions
 Constraints

Once the above mentioned parameters are identified we need to make a mental layout of the
entire flow. This mental layout is then transformed into an activity diagram.

Activity diagrams are constructed from a limited number of shapes, connected with arrows.[4]
The most important shape types:

 rounded rectangles represent actions;

 diamonds represent decisions;

 bars represent the start (split) or end (join) of concurrent activities;

 a black circle represents the start (initial state) of the workflow;

 an encircled black circle represents the end (final state).

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Practical -5

AIM: - Design Use-case Diagram for system

General Description:

UML is a standard language for specifying, visualizing, constructing, and documenting the
artifacts of software systems.

UML was created by Object Management Group (OMG) and UML 1.0 specification draft was
proposed to the OMG in January 1997.

OMG is continuously putting effort to make a truly industry standard.

 UML stands for Unified Modeling Language.

 UML is different from the other common programming languages like C++, Java,
COBOL etc.
 UML is a pictorial language used to make software blue prints.

So UML can be described as a general purpose visual modeling language to visualize, specify,
construct and document software system. Although UML is generally used to model software
systems but it is not limited within this boundary. It is also used to model non software systems
as well like process flow in a manufacturing unit etc.

UML is not a programming language but tools can be used to generate code in various languages
using UML diagrams. UML has a direct relation with object oriented analysis and design.

Goals of UML:

A picture is worth a thousand words, this absolutely fits while discussing about UML. Object
oriented concepts were introduced much earlier than UML. So at that time there were no
standard methodologies to organize and consolidate the object oriented development.

There are a number of goals for developing UML but the most important is to define some
general purpose modeling language which all modelers can use and also it needs to be made
simple to understand and use.

UML diagrams are not only made for developers but also for business users, common people and
anybody interested to understand the system. The system can be a software or non software. So it
must be clear that UML is not a development method rather it accompanies with processes to
make a successful system.

At the conclusion the goal of UML can be defined as a simple modeling mechanism to model all
possible practical systems in today’s complex environment

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Overview of Use-case diagram:

Use-case diagram is one of the important diagrams in UML to represent the different ways in
which a system can be used by the users.

Use-case diagram capture a contract that describes the systems behavior under various conditions
as the system responds to a requests from one of its stakeholders.

A use-case tells a stylized story about how an end user interacts with the system under the
specific set of circumstances.

Purpose:

The purpose of a use case is to define a piece of coherent behavior without revealing the internal
structure of the system. The use cases do not mention any specific algorithm to be used or the
internal data representation, internal structure of the software, etc. A use case typically represents
a sequence of interactions between the user and the system. These interactions consist of one
mainline sequence. The mainline sequence represents the normal interaction between a user and
the system. The mainline sequence is the most occurring sequence of interaction

How to draw use-case Diagram?

One widely used approach to documenting requirements is “use cases”. These are textual
descriptions which can be augmented by UML use case diagrams. Use cases take the point of
view of the user or users of the system. A user who is carrying out a particular role is called an
actor. A use case is a task that an actor needs the system to carry out.

A use case both specifies what the user does and what the system does, but says nothing about
how the system performs its tasks.

You will see that a use case diagram does not contain the detail associated with a (textual) use
case. However, it does give an overall picture of the actors and the use cases. Thus a use case
diagram is an informal graphical representation of requirements.

Representation of use cases

Use cases can be represented by drawing a use case diagram and writing an accompanying text
elaborating the drawing.

In the use case diagram, each use case is represented by an ellipse with the name of the use case
written inside the ellipse.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

All the ellipses (i.e. use cases) of a system are enclosed within a rectangle which represents the
system boundary. The name of the system being modeled (such as Library Information System)
appears inside the rectangle.

The different users of the system are represented by using the stick person icon.

Each stick person icon is normally referred to as an actor. An actor is a role played by a user with
respect to the system use. It is possible that the same user may play the role of multiple actors.
Each actor can participate in one or more use cases. The line connecting the actor and the use
case is called the communication relationship. It indicates that the actor makes use of the
functionality provided by the use case.

Both the human users and the external systems can be represented by stick person icons.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Practical -6

AIM: - Design Data Dictionary of your system.

General Description:

A data dictionary lists all data items appearing in the DFD model of a system. The data items
listed include all data flows and the contents of all data stores appearing on the DFDs in the DFD
model of a system. A data dictionary lists the purpose of all data items and the definition of all
composite data items in terms of their component data items Goals of UML:

A data dictionary is a "centralized repository of information about data such as meaning,

relationships to other data, origin, usage, and format." The term may have one of several closely
related meanings pertaining to databases and database management systems (DBMS)

Data dictionary (also called information repositories) are mini database management systems
that manages metadata. It is a repository of information about a database that documents data
elements of a database. The data dictionary is an integral part of the database management
systems (DBMSs) and stores metadata, or information about the database, attribute names and
definitions for each table in the database.

Purpose:

A data dictionary plays a very important role in any software development process because of
the following reasons:

 A data dictionary provides a standard terminology for all relevant data for use by the
engineers working in a project. A consistent vocabulary for data items is very important,
since in large projects, different engineers of the project have a tendency to use different
terms to refer to the same data, which unnecessary causes confusion.
 The data dictionary provides the analyst with a means to determine the definition of
different data structures in terms of their component elements.

 These dictionaries, usually called data dictionaries or data dictionary/directories, are in

reality application systems which have been designed to manage documentation.
Although the majority of the documentation within them pertains to data, most of them
also contain provisions for documenting the other components of the systems
environment: systems, users, reports, forms, functions, processes, etc.
 Dictionary systems and their files, unlike most systems, do not contain data, but rather
they contain "data about data." This "data about data," usually called "metadata,"
describes and defines the components of the data processing environment and allows for
each type of component to be related to every other type of component, thus creating a
powerful research, analytical, and cross-reference tool.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

 Because of their automated nature, and normal ease of updating and maintenance,
dictionaries are the primary documentation tool for most well-run data processing
organizations. In some cases the dictionary is also the repository for the control and
definition information which drives the DBMS.

How to design Data Dictionary?

Create a dictionary of names for the data elements that you uncovered while identifying host
transactions and journal entries in the previous step.

The data dictionary ensures that each data element has a common identity in all parts of the
system, whether it is being sent to the host, stored in the journal, or printed. Although the
dictionary may seem trivial for the sample application, it is important in a real project.

The data dictionary ensures that the same concepts are used in the teller application processes
running on the first and second tiers, and in the host application that runs the main business
logic.

The following is the data dictionary for the Base Sample Application (the bulleted items
represent elements of a data structure):

Internal name of Data Data Type of Data

element element Data element description

Date Date Date of Transaction

AccountNumber Number(10) Account number
AccountBalance Number(10) Account balance
MaxAmount Number(10) Maximum amount
CustomerId Number(10) Customer identifier
CustomerName String Customer name
TrxId Number(10) Transaction identifier
Amount Number(5) Operation amount
BranchId Number(4) Branch identifier
TrxReplyCode Boolean Host transaction reply code
TrxErrorMessage String Host transaction error message

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Representation of Data Dictionary

Data dictionary is usually a part of the system catalog that is generated for each database. A
useful data dictionary system usually stores and manages the following types of information:

 Descriptions of the schema of the database.

 Detailed information on physical database design, such as storage structures, access paths
and file and record sizes.

 Description of the database users, their responsibilities and their access rights.

 High-level descriptions of the database transactions and applications and of the

relationships of users to transactions.

 The relationship between database transactions and the data items referenced by them.
This is useful in determining which transactions are affected when certain data definitions
are changed.

 Usage statistics such as frequencies of queries and transactions and access counts to
different portions of the database.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Practical -7

AIM: - Prepare E-R Diagram of System

General Description:

An entity-relationship diagram is a data modeling technique that creates a graphical

representation of the entities, and the relationships between entities, within an information
system.

Entity Relationship diagrams (also known as E-R or ER diagrams) provide database designers
with a valuable tool for modeling the relationships between database entities in a clear, precise
format. This industry standard approach uses a series of block shapes and lines to describe the
structure of a database in a manner understandable to all database professionals.

Many database software packages, including Microsoft Access, SQL Server, and Oracle, provide
automated methods to quickly create E-R diagrams from existing databases.

Overview of E-R Diagram:

Main components of an ER Diagram :-

Entity:

 The entity is a person, object, place or event for which data is collected. For example, if
you consider the information system for a business, entities would include not only
customers, but the customer's address, and orders as well. The entity is represented by a
rectangle and labeled with a singular noun.

For example, a database containing information about individual people would likely
have an entity called Person. This would correspond to a table with the same name in the
database and every person tracked in the database would be an instance of that Person
entity and have a corresponding row in the Person table. Database designers creating an
E-R diagram would draw the Person entity using a shape similar to this:

Person

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Attributes
 The Attributes: - Tracking entities alone is not sufficient to develop a data model.
Databases contain information about each entity. This information is tracked in individual
fields known as attributes, which normally correspond to the columns of a database table.

For example, the Person entity might have attributes corresponding to the person's first
and last name, date of birth, and a unique person identifier. Each of these attributes is
depicted in an E-R diagram as an oval, as shown in the figure below:

F_Name L_name

PID DOB
Person

Relationship

 The relationship is the interaction between the entities. A relationship may be represented
by a diamond shape, or more simply, by the line connecting the entities. In either case,
verbs are used to label the relationships.

The power of the E-R diagram lies in its ability to accurately display information about
the relationships between entities. For example, we might track information in our
database about the city where each person lives. Information about the city itself is
tracked within a City entity and a relationship is used to tie together Person and City
instances.

Relationships are normally given names that are verbs, while attributes and entities are
named after nouns. This convention makes it easy to express relationships. For example,
if we name our Person/City relationship "Lives In", we can string them together to say "A
person lives in a city." We express relationships in E-R diagrams by drawing a line

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

between the related entities and placing a diamond shape that contains the relationship
name in the middle of the line. Here's how our Person/City relationship would look:

F_Name L_name

CID C_Name
PID DOB
Person Live in City

Cardinality

 The cardinality defines the relationship between the entities in terms of numbers. An
entity may be optional: for example, a sales rep could have no customers or could have
one or many customers; or mandatory: for example, there must be at least one product
listed in an order. There are several different types of cardinality notation; crow's foot
notation, used here, is a common one.

In crow's foot notation,

A single bar indicates one,
A double bar indicates one and only one
(For example, a single instance of a product can only be stored in one warehouse),
A circle indicates zero, and a crow's foot indicates many.
The three main cardinal relationships are:
one-to-one, expressed as 1:1;
one-to-many, expressed as 1:M; and
many-to-many, expressed as M:N.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Purpose:

The steps involved in creating an ERD are:

 Identify the entities.

 Determine all significant interactions.
 Analyze the nature of the interactions.
 Draw the ERD.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Practical -8

AIM: - Design Data Flow Diagram of System

General Description:
Data flow diagram (DFD) represents the flows of data between different processes in a
business. It is a graphical technique that depicts information flow and the transforms that
are applied as data move form input to output. It provides a simple, intuitive method for
describing business processes without focusing on the details of computer systems. DFDs
are attractive technique because they provide what users do rather than what computers
do.

A DFD shows what kind of information will be input to and output from the system,
where the data will come from and go to, and where the data will be stored. It does not
show information about the timing of processes, or information about whether processes
will operate in sequence or in parallel

Representation of Components

DFDs only involve four symbols. They are:

 Process
 Data Object
 Data Store
 External entity

Process
Transform of incoming data flow(s) to outgoing flow(s).

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Data Flow
Movement of data in the system.

Data Store
Data repositories for data that are not moving. It may be as simple as a buffer or a
queue or a s sophisticated as a relational database.

External Entity
Sources of destinations outside the specified system boundary.

Relationship and Rules

Relationship
The DFD may be used for any level of data abstraction. DFD can be partitioned into levels. Each
level has more information flow and data functional details than the previous level.

Highest level is Context Diagram. Some important points are:

 1 bubble (process) represents the entire system.
 Data arrows show input and output.
 Data Stores NOT shown. They are within the system.

Next Level is Level 1 DFD. Some important points are:

 Level 1 DFD must balance with the context diagram it describes.
 Inputs going into a process are different from outputs leaving the process.
 Data stores are first shown at this level.

Next level is Level 2 DFD. Some important points are:

 Level 2 DFD must balance with the Level 1 it describes.
 Inputs going into a process are different from outputs leaving the process.
 Continue to show data stores.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

A DFD may look similar to a flow chart. However, there is a significant difference with
the data flow diagram. The arrows in DFDs show that there is a flow of data between the
two components and not that the component is sending the data that must be executed in
the following component. A component in DFD may not continue execution when
sending data and during execution of the component receiving the data. The component
sending data can send multiple sets of data along several connections. In fact, a DFD
node can be a component that never ends.

Rules
 In DFDs, all arrows must be labeled.
 The information flow continuity, that is all the input and the output to each refinement,
must maintain the same in order to be able to produce a consistent system.

Strengths and Weaknesses Of DFD

Strengths
 DFDs have diagrams that are easy to understand, check and change data.
 DFDs help tremendously in depicting information about how an organization operations.
 They give a very clear and simple look at the organization of the interfaces between an
application and the people or other applications that use it.

Weaknesses
 Modification to a data layout in DFDs may cause the entire layout to be changed. This is
because the specific changed data will bring different data to units that it accesses.
Therefore, evaluation of the possible of the effect of the modification must be considered
first.
 The number of units in a DFD in a large application is high. Therefore, maintenance is
harder, more costly and error prone. This is because the ability to access the data is
passed explicitly from one component to the other. This is why changes are impractical to
be made on DFDs especially in large system.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Practical -9

AIM: - Prepare Gantt chart of system

Overview:

A timeline is a chart that depicts how a set of resources are used over time. If you're managing a
software project and want to illustrate who is doing what and when, or if you're organizing a
conference and need to schedule meeting rooms, a timeline is often a reasonable visualization
choice. One popular type of timeline is the Gantt chart.

General Description:
A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry
L. Gantt, an American engineer and social scientist. Frequently used in project management, a
Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track
specific tasks in a project.

Gantt charts are widely used in business to describe and monitor all kinds of projects according
to the rules of project management.

A Gantt chart is constructed with a horizontal axis representing the total time span of the project,
broken down into increments (for example, days, weeks, or months) and a vertical axis
representing the tasks that make up the project (for example, if the project is outfitting your
computer with new software, the major tasks involved might be: conduct research, choose
software, install software).

Horizontal bars of varying lengths represent the sequences, timing, and time span for each task.
Put first task at the top of the vertical axis and draw a bar on the graph that represents the amount
of time you expect to spend on the research, and then enter the other tasks below the first one and
representative bars at the points in time when you expect to undertake them.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

The bar spans may overlap, as, for example, you may conduct research and choose software
during the same time span. As the project progresses, secondary bars, arrowheads, or darkened
bars may be added to indicate completed tasks, or the portions of tasks that have been completed.
A vertical line is used to represent the report date.

Basic Gantt chart Shapes

The basic shapes required to make a Gantt chart include tables, Gantt bars, milestone markers,
and link lines.

Gantt bars indicate the duration of tasks.

Milestone markers signal a major turning

point in the project such an approval
meeting or the release of a product. They
can also mark the beginning and end of
tasks.
Links lines show the relationship between
two tasks, often indicating that a task can
only begin when another ends.

Sample of Time Line Chart:

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Typically, Gantt charts indicate the exact duration of specific tasks, but they can also be used to
indicate the relationship between tasks, planned and actual completion dates, cost of each task,
the person or persons responsible for each task, and the milestones in a project's development.

Gantt charts give a clear illustration of project status, but one problem with them is that they
don't indicate task dependencies - you cannot tell how one task falling behind schedule affects
other tasks.

The PERT chart, another popular project management charting method, is designed to do this.
Automated Gantt charts store more information about tasks, such as the individuals assigned to
specific tasks, and notes about the procedures. They also offer the benefit of being easy to
change, which is helpful. Charts may be adjusted frequently to reflect the actual status of project
tasks as, almost inevitably; they diverge from the original plan.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Practical -10
AIM: - Prepare suitable test case for system testing.
General Description:

“A test case has components that describe an input, action or event and an expected response, to
determine if a feature of an application is working correctly.”

There are levels in which each test case will fall in order to avoid duplication efforts.
Level 1:
In this level you will write the basic test cases from the available specification and user
documentation.
Level 2:
This is the practical stage in which writing test cases depend on actual functional and
system flow of the application.
Level 3:
This is the stage in which you will group some test cases and write a test procedure.
Test procedure is nothing but a group of small test cases maximum of 10.
Level 4: Automation of the project
This will minimize human interaction with system and thus QA can focus on current
updated functionalities to test rather than remaining busy with regression testing.

So you can observe a systematic growth from no testable item to a Automation suit.

Purpose:
The basic objective of writing test cases is to validate the testing coverage of the
application. If you are working in any CMMi company then you will strictly follow test cases
standards. So writing test cases brings some sort of standardization and minimizes the ad-hoc
approach in testing.

Steps to write test cases:

Simple test case format

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Fields in test cases:

Test case id:
Unit to test: What to be verified?
Assumptions:
Test data: Variables and their values
Steps to be executed:
Expected result:
Actual result:
Pass/Fail:
Comments:

A good test case has certain characteristics which are:

1. Should be accurate and tests what it is intended to test.
2. No unnecessary steps should be included in it.
3. It should be reusable.
4. It should be traceable to requirements.
5. It should be compliant to regulations.
6. It should be independent i.e. You should be able to execute it in any order without any
dependency on other test cases.
7. It should be simple and clear, any tester should be able to understand it by reading once.
8. Now keeping in mind these characteristics you can write good and effective test cases.

Testing Techniques
It's not possible to check every possible condition in your software application. Testing
techniques help you select a few test cases with the maximum possibility of finding a defect.
Boundary Value Analysis (BVA): As the name suggests it's the technique that defines the
testing of boundaries for specified range of values.
Equivalence Partition (EP) :This technique partitions the range into equal parts/groups that
tend to have same behavior.
State Transition Technique: This method is used when software behavior changes from one
state to another following particular action.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Error Guessing Technique: This is guessing/anticipating the error that may arise while
testing.This is not a formal method and takes advantages of a tester's experience with the
application

Guidelines/Best Practice/Tips for writing test cases.

1. Test Cases need to be simple and transparent:
Create test cases which are as simple as possible. They must be clear and concise as
author of test case may not execute them.
Use assertive language like go to home page, enter data, click on this and so on. This
makes the understanding the test steps easy and test execution faster.
2. Create Test Case with End User in mind
Ultimate goal of any software project is to create test cases that meets customer
requirements and is easy to use and operate. A tester must create test cases keeping in
mind the end user perspective
3. Avoid test case repetition.
Do not repeat test cases. If a test case is needed for executing some other test case , call
the test case by its test case id in the pre-condition column
4. Do not assume
Do not assume functionality and features of your software application while preparing
test case. Stick to the Specification Documents.
5. Ensure 100% Coverage
Make sure you write test cases to check all software requirements mentioned in the
specification document. Use Traceability Matrix to ensure no functions/conditions is left
untested.
6. Test Cases must be identifiable.
Name the test case IDs such that they are identified easily while tracking defects or
identifying a software requirement at a later stage.
7. Implement Testing Techniques
Testing techniques must be used for effective testing.

SEMESTER –IV IT DEPARTMENT

Fundamental of S/W Development SUBCODE: -3341603

Suppose you encounter a scenario to test a good deal of values. In such a case apply both
Boundary Value Analysis and Equivalence Partitioning techniques. This will aid in
covering a good range of value and avoid unnoticed defects.
In case Application has many pages/integrations then create test cases for each State
Change by implementing the State Transition Technique.
8. Peer Review.
After creating test cases, get them reviewed by your colleagues. Your peers can uncover
defects in your test case design, that you may easily miss.

2). Test cases for one Rupees Coin Box (Telephone box)?
Positive test cases:

TC1 : Pick up the Handset

Expected : Should display the message " Insert one rupee coin"
TC2 : Insert the coin
Expected : Should display the message " Dial the Number"
TC3 : When you get a busy tone, hang-up the receiver
Expected : The inserted one rupee coin comes out of the exit door.
TC4 : Finish off the conversation and hang-up the receiver
Expected : The inserted coin should not come out.
TC5 : During the conversation, in case of a local call, (assume the duration is of 60
sec), when 45 as are completed
Expected : It should prompt you to insert another coin to continue by giving beeps.
TC6 : In the above scenario, if another coin is inserted
Expected : 60 sec will be added to the counter.
TC7 : In the TC5 scenario, if you don't insert one more coin.
Expected : The call gets ended.
TC8 : Pick up the receiver. Insert appropriate one rupee coin; Dial the number after
. hearing the ring tone. Assume it got connected and you are getting the ring tone.
. Immediately you end up the call.

SEMESTER –IV IT DEPARTMENT