S

Experiment CO
No.
Identifying the Requirements from Problem
1 Statements CO1

2 Estimation of Project Metrics CO2

Modeling UML Use Case Diagrams and Capturing

3 Use Case Scenarios CO4

4 E-R Modeling from the Problem Statements CO4

Identifying Domain Classes from the Problem

5 Statements CO3

6 State chart and Activity Modeling CO4

Modeling UML Class Diagrams and Sequence

7 diagrams CO4

8 Modeling Data Flow Diagrams CO4

Estimation of Test Coverage Metrics and

9 Structural Complexity

10 Designing Test Suites

 Experiment -1
Identifying the Requirements from Problem Statements

Software Requirements Specification (SRS) To prepare SRS, first requirements have to be identified from the
given problem statement. Requirements identification is the first step of any software development project. Until
the requirements of a client have been clearly identified, and verified, no other task (design, coding, testing)
could begin.

Requirements specify how the target system should behave. It specifies what to do, but not how to do.
Requirements engineering refers to the process of understanding what a customer expects from the system to be
developed, and to document them in a standard and easily readable and understandable format.

It is necessary and important that before we start planning, design and implementation of the software system
for our client, we are clear about it's requirements. If we don't have a clear vision of what is to be developed and
what all features are expected, there would be serious problems, and customer dissatisfaction as well.

 Properties Of Requirements Unambiguity Consistency Completeness

Types Of Requirements User requirements System requirements Functional requirements Non-functional

requirements

Functional requirements (FRs): These describe the functionality of a system -- how a system should react to a
particular set of inputs and what should be the corresponding output. Non-functional requirements (NFRs): They
are not directly related what functionalities are expected from the system. They define how the system should
behave under certain situations.

Non Functional Requirements Types Product requirements: For example, a specification that the web
application should use only plain HTML, and no frames. Performance requirements: For example, the system
should remain available 24x7 Organizational requirements: The development process should comply to SEI
CMM level 4

Preparing Software Requirements Specifications Once all possible FRs and non-FRs have been identified,
which are complete, consistent, and non-ambiguous, the Software Requirements Specification (SRS) is to be
prepared. The SRS is prepared by the service provider, and verified by its client. This document serves as a legal
agreement between the client and the service provider.

Steps to Prepare SRS 1. Identify functional requirements 2. Prepare a table of Identifier and priority for
software requirements 3.Identify Non-functional requirements 4. Once all the functional and non-functional
requirements have been identified, they are documented formally in SRS.

Example Internet has led to discussion of e-democracy and online voting. Many peoples think that the internet
could replace representative democracy, enabling everyone to vote on everything and anything by online
voting.Online voting could reduce cost and make voting more convenient. This type of voting can be done for e-
democracy, or it may be used for finalizing a solution, if many alternatives are present. Online voting make’s
use of authentication, hence it needs security, and the system must be able to address obtaining, marking,
delivering and counting ballots via computer. Advantage of online voting is it could increase voter turnout
because of convenience, and it helps to reduce fraud voting.

Identification of functional requirements User registration User Login Publish Manifesto Vote Count Vote:
system should be able to Publish results: Admin must be able to Prevent fraud voting Only one vote E-mail
notification Error handling

Table Requirement NoRequirementPriority 1User Registrationhigh 2User loginhigh 3……..….

Identification of non-functional requirements Performance Requirements: This system should remain accessible
to thousands of users at a time Security Requirements: This system should be accessible only to valid users The
database of LIS should not store any password in plain text -- a hashed value has to be stored Software Quality
Attributes Database Requirements Design Constraints: The system should be developed using HTML 5

Example 2 As the size and capacity of the institute is increasing with the time, it has been proposed to develop a
Library Information System (LIS) for the benefit of students and employees of the institute. LIS will enable the
members to borrow a book (or return it) with ease while sitting at his desk/chamber. The system also enables a
 member to extend the date of his borrowing if no other booking for that particular book has been made. For the
library staff, this system aids them to easily handle day-to-day book transactions. The librarian, who has
administrative privileges and complete control over the system, can enter a new record into the system when a
new book has been purchased, or remove a record in case any book is taken off the shelf. Any non-member is
free to use this system to browse/search books online. However, issuing or returning books is restricted to valid
users (members) of LIS only. The final deliverable would a web application (using the recent HTML 5), which
should run only within the institute LAN. Although this reduces security risk of the software to a large extent,
care should be taken no confidential information (eg., passwords) is stored in plain text.

Identification of functional requirements New user registration Search book User login Issue book Return book
Reissue book

Table Requirement No Requirement Priority

Identification of non-functional requirements Performance Requirements: This system should remain accessible
24x7 Security Requirements: This system should be accessible only within the institute LAN The database of
LIS should not store any password in plain text -- a hashed value has to be stored Software Quality Attributes
Database Requirements Design Constraints: The system should be developed using HTML 5

Experiment -2
Estimation of Project Metrics
After gathering the entire requirements specific to software project usually we need to think
about different solution strategy for the project. Expert business analysts are analyzing their
benefits and as well as their shortcomings by means of cost, time and resources require to
develop it.
In this experiment, we will learn how to estimate cost, effort and duration for a software
project, and then select one solution approach which will be found suitable to fulfill the
organizational goal.
A software project is not just about writing a few hundred lines of source code to achieve a
particular objective. The scope of a software project is comparatively quite large, and such a
project could take several years to complete. However, the phrase "quite large" could only
give some (possibly vague) qualitative information. As in any other science and engineering
discipline, one would be interested to measure how complex a project is. One of the major
activities of the project planning phase, therefore, is to estimate various project parameters in
order to take proper decisions. Some important project parameters that are estimated include:
 Project size: What would be the size of the code written say, in number of lines, files,
modules?
 Cost: How much would it cost to develop a software? A software may be just pieces of
code, but one has to pay to the managers, developers, and other project personnel.
 Duration: How long would it be before the software is delivered to the clients?
 Effort: How much effort from the team members would be required to create the
software?
In this experiment we will focus on two methods for estimating project metrics: COCOMO
and Halstead's method.

COCOMO
COCOMO (Constructive Cost Model) was proposed by Boehm. According to him, there
could be three categories of software projects: organic, semidetached, and embedded. The
classification is done considering the characteristics of the software, the development team
and environment. These product classes typically correspond to application, utility and system
programs, respectively. Data processing programs could be considered as application
programs. Compilers, linkers, are examples of utility programs. Operating systems, real-time
system programs are examples of system programs. One could easily apprehend that it would
take much more time and effort to develop an OS than an attendance management system.
The concept of organic, semidetached, and embedded systems are described below.
 Organic: A development project is said to be of organic type, if
 The project deals with developing a well understood application
 The development team is small
 The team members have prior experience in working with similar types of
projects
Semidetached: A development project can be categorized as semidetached type, if
 The team consists of some experienced as well as inexperienced staff
 Team members may have some experience on the type of system to be
developed
Embedded: Embedded type of development project are those, which
 Aims to develop a software strongly related to machine hardware
 Team size is usually large
Boehm suggested that estimation of project parameters should be done through three stages:
Basic COCOMO, Intermediate COCOMO, and Complete COCOMO.

Advantages of COCOMO
COCOMO is a simple model, and should help one to understand the concept of project
metrics estimation.
Drawbacks of COCOMO
COCOMO uses KDSI, which is not a proper measure of a program's size. Indeed, estimating
the size of a software is a difficult task, and any slight miscalculation could cause a large
deviation in subsequent project estimates. Moreover, COCOMO was proposed in 1981
keeping the waterfall model of project life cycle in mind [2]. It fails to address other popular
approaches like prototype, incremental, spiral, agile models. Moreover, in present day a
software project may not necessarily consist of coding of every bit of functionality. Rather,
existing software components are often used and glued together towards the development of a
new software. COCOMO is not suitable in such cases.
COCOMO II was proposed later in 2000 to many of address these issues.

Halstead's Complexity Metrics

Halstead took a linguistic approach to determine the complexity of a program. According to
him, a computer program consists of a collection of different operands and operators. The
definition of operands and operators could, however, vary from one person to another and one
programming language to other. Operands are usually the implementation variables or
constants -- something upon which an operation could be performed. Operators are those
symbols that affects the value of operands. Halstead's metrics are computed based on the
operators and operands used in a computer program. Any given program has the following
four parameters:
 n1: Number of unique operators used in the program
 n2: Number of unique operands used in the program
 N1: Total number of operators used in the program
 N2: Total number of operands used in the program
Using the above parameters one compute the following metrics:
 Program Length: N = N1 + N2
 Program Vocabulary: n = n1 + n2
 Volume: V = N * lg n
  Difficulty: D = (n1 * N2) / (2 * n2)
 Effort: E = D * V
 Time to Implement: T = E / 18 (in seconds) [vi]
The program volume V is the minimum number of bits needed to encode the program. It
represents the size of the program while taking into account the programming language.
The difficulty metric indicates how difficult a program is to write or understand.
Effort denotes the "mental effort" required to develop the software, or to recreate the same in
another programming language .

Experiment -3
Modeling UML Use Case Diagrams and Capturing Use Case Scenarios
a. Use case Diagram
 Experiment -4
E-R Modeling from the Problem Statements
 Experiment -5
Identifying Domain Classes from the Problem Statements
From the object-oriented perspective, the world as made of objects.
Objects can represent material things, but they can also represent abstract things such as
events, roles, and descriptions.
If requested by another object, an object can execute one of its methods/functions.
Executing a method may change the object's internal state, it may change the object's
environment, it may send requests to other objects to execute some of their methods,
and/or it may simply provide information to the original requesting object.
Here are some basic definitions:
 Objects, Classes, and Packages

An object model consists of one or more UML class diagrams. A class diagram is a graph:
nodes connected by arrows. The nodes represent packages, interfaces, classes, and objects:
UML Package, Class, and Object Icons

Domains
A domain is a package of related concepts, roles, procedures, events, and entities.
(See Domain Modeling).
Examples of domains include:
business
engineering
science
government
health care

In UML:

Examples of sub-domains of the business might include:

sales
marketing
management
finance

In UML we can represent this as packages connected by dependency arrows.

A dependency arrow connecting the sales package to the business package indicates that
some of the concepts contained in business�profit, overhead, employee, customer,
etc.�are used in the sales package:
Experiment -6
 State chart and Activity Modeling.
Capturing the dynamic view of a system is very important for a developer to develop the logic
for a system. State chart diagrams and activity diagrams are two popular UML diagram to
visualize the dynamic behavior of an information system.
In this experiment, we will learn about the different components of activity diagram and state
chart diagram and how these can be used to represent the dynamic nature of an information
system.
Statechart Diagrams
In case of Object Oriented Analysis and Design, a system is often abstracted by one or more
classes with some well definedbehaviour and states. A statechart diagram is a pictorial
representation of such a system, with all it's states, and different events that lead transition
from one state to another.
To illustrate this, consider a computer. Some possible states that it could have are: running,
shutdown, hibernate. A transition from running state to shutdown state occur when user
presses the "Power off" switch, or clicks on the "Shut down" button as displayed by the OS.
Here, clicking on the shutdown button, or pressing the power off switch act as external events
causing the transition.
Statechart diagrams are normally drawn to model the behaviour of a complex system. For
simple systems this is optional.
Building Blocks of a Statechart Diagram
State
A state is any "distinct" stage that an object (system) passes through in it's lifetime. An object
remains in a given state for finite time until "something" happens, which makes it to move to
another state. All such states can be broadly categorized into following three types:
 Initial: The state in which an object remain when created
 Final: The state from which an object do not move to any other state [optional]
 Intermediate: Any state, which is neither initial, nor final
As shown in figure-01, an initial state is represented by a circle filled with black. An
intermediate state is depicted by a rectangle with rounded corners. A final state is represented

by a unfilled circle with an inner black-filled circle. Figure-

01: Representation of initial, intermediate, and final states of a statechartdiagramIntermediate
states usually have two compartments, separated by a horizontal line, called the name
compartment and internal transitions compartment [iv]. They are described below:
 Name compartment: Contains the name of the state, which is a short, simple, descriptive
string
 Internal transitions compartment: Contains a list of internal activities performed as long
as the system is in this state
The internal activities are indicated using the following syntax: action-label / action-
expression. Action labels could be any condition indicator. There are, however, four special
action labels:
 Entry: Indicates activity performed when the system enter this state
 Exit: Indicates activity performed when the system exits this state
 Do: indicate any activity that is performed while the system remain in this state or until the
action expression results in a completed computation
 Include: Indicates invocation of a sub-machine

Any other action label identify the event (internal transition) as a result of which the
corresponding action is triggered. Internal transition is almost similar to self transition, except
that the former doesn't result in execution of entry and exit actions. That is, system doesn't exit
or re-enter that state. Figure-02 shows the syntax for representing a typical (intermediate) state

Figure-02: A typical state in a state chart diagram States

could again be either simple or composite (a state congaing other states). Here, however, we
will deal only with simple states.
Transition
Transition is movement from one state to another state in response to an external stimulus (or
any internal event). A transition is represented by a solid arrow from the current state to the
next state. It is labeled by: event [guard-condition]/[action-expression], where
 Event is the what is causing the concerned transition (mandatory) -- Written in past
tense [iii]
 Guard-condition is (are) precondition(s), which must be true for the transition to happen
[optional]
 Action-expression indicate action(s) to be performed as a result of the transition [optional]
It may be noted that if a transition is triggered with one or more guard-condition(s), which
evaluate to false, the system will continue to stay in the present state. Also, not all transitions
do result in a state change. For example, if a queue is full, any further attempt to append will
fail until the delete method is invoked at least once. Thus, state of the queue doesn't change in
this duration.
Action
As mentioned in [ii], actions represents behaviour of the system. While the system is
performing any action for the current event, it doesn't accept or process any new event. The
order in which different actions are executed, is given below:
1. Exit actions of the present state
2. Actions specified for the transition
3. Entry actions of the next state
Figure-03 shows a typical statechart diagram with all it's syntaxes.

Figu
re-03: A statechart diagram showing transition from state A to B
Guidelines for drawing State chart Diagrams
Following steps could be followed, as suggested in [i] to draw a state chart diagram:
 For the system to developed, identify the distinct states that it passes through
 Identify the events (and any precondition) that cause the state transitions. Often these
would be the methods of a class as identified in a class diagram.
 Identify what activities are performed while the system remains in a given state
Activity Diagrams
Activity diagrams fall under the category of behavioural diagrams in Unified Modeling
Language. It is a high level diagram used to visually represent the flow of control in a system.
It has similarities with traditional flow charts. However, it is more powerful than a simple
flow chart since it can represent various other concepts like concurrent activities, their joining,
and so on [vii, viii].
Activity diagrams, however, cannot depict the message passing among related objects. As
such, it can't be directly translated into code. These kind of diagrams are suitable for
confirming the logic to be implemented with the business users. These diagrams are typically
used when the business logic is complex. In simple scenarios it can be avoided entirely [ix].
Components of an Activity Diagram
Below we describe the building blocks of an activity diagram.
Activity
An activity denotes a particular action taken in the logical flow of control. This could simply
be invocation of a mathematical function, alter an object's properties and so on [x]. An activity
is represented with a rounded rectangle, as shown in table-01. A label inside the rectangle
identifies the corresponding activity.
There are two special type of activity nodes: initial and final. They are represented with a
filled circle, and a filled in circle with a border respectively (table-01). Initial node represents
the starting point of a flow in an activity diagram. There could be multiple initial nodes, which
means that invoking that particular activity diagram would initiate multiple flows.
A final node represents the end point of all activities. Like an initial node, there could be
multiple final nodes. Any transition reaching a final node would stop all activities.
Flow
A flow (also termed as edge, or transition) is represented with a directed arrow. This is used to
depict transfer of control from one activity to another, or to other types of components, as we
will see below. A flow is often accompanied with a label, called the guard condition,
indicating the necessary condition for the transition to happen. The syntax to depict it
is [guard condition].
Decision
A decision node, represented with a diamond, is a point where a single flow enters and two or
more flows leave. The control flow can follow only one of the outgoing paths. The outgoing
edges often have guard conditions indicating true-false or if-then-else conditions. However,
they can be omitted in obvious cases. The input edge could also have guard conditions.
Alternately, a note can be attached to the decision node indicating the condition to be tested.
Merge
This is represented with a diamond shape, with two or more flows entering, and a single flow
leaving out. A merge node represents the point where at least a single control should reach
before further processing could continue.
Fork
Fork is a point where parallel activities begin. For example, when a student has been
registered with a college, he can in parallel apply for student ID card and library card. A fork
is graphically depicted with a black bar, with a single flow entering and multiple flows leaving
out.
Join
A join is depicted with a black bar, with multiple input flows, but a single output flow.
Physically it represents the synchronization of all concurrent activities. Unlike a merge, in
case of a join all of the incoming controls must be completed before any further progress
could be made. For example, a sales order is closed only when the customer has receive the
product, and the sales company has received it's payment.

Note
UML allows attaching a note to different components of a diagram to present some textual
information. The information could simply be a comment or may be some constraint. A note
can be attached to a decision point, for example, to indicate the branching criteria.
Partition
Different components of an activity diagram can be logically grouped into different areas,
called partitions or swimlanes. They often correspond to different units of an organization
or different actors. The drawing area can be partitioned into multiple compartments using
Component Graphical Notation vertical (or horizontal) parallel
lines. Partitions in an activity
Activity diagram are not mandatory.
The following table shows
commonly used components
Flow
with a typical activity diagram.

Decision
Table-01: Typical components used in
an activity diagram
Apart from the above stated
components, there are few
other components as well
(representing events, sending
of signals, nested activity
diagrams), which won't be
Merge discussed here. The reader is
suggested to go through [x] for
further knowledge.

Fork

Join

Note
Experiment -6
 Modeling UML Class Diagram & Sequence diagrams

UML
Class Diagram
Sequence diagrams, commonly used by developers, model the interactions between
objects in a single use case.
Sequence Diagram Notations
A sequence diagram is structured in such a way that it represents a timeline which begins at the top and
descends gradually to mark the sequence of interactions.
A Quick Overview of the Various Parts of a Sequence Diagram
 Lifeline Notation

 Activation Bars
 Message Arrows

o Synchronous message
o Asynchronous message
o Return message
o Participant creation message
o Participant destruction message
o Reflexive message

Sequence Diagram Best Practices

Manage complex interactions with sequence fragments
A sequence fragment is represented as a box that frames a section of interactions between objects (as
shown in the examples below) in a sequence diagram.

It is used to show complex interactions such as alternative flows and loops in a more structured way. On
the top left corner of the fragment sits an operator. This – the fragment operator – specifies what sort of
a fragment it is.

Sequence Diagram of an Online Exam System

Experiment – 8
 Modeling Data Flow Diagrams

DFD/ Framework

Experiment – 9
Estimation of Test Coverage Metrics and Structural Complexity
Study on test cases

Estimation of the size of the software is an essential part of Software Project Management. It
helps the project manager to further predict the effort and time which will be needed to build
the project. Various measures are used in project size estimation. Some of these are:
1. Lines of Code (LOC): As the name suggests, LOC count the total number of lines of source code in a
project.
 KLOC- Thousand lines of code
 NLOC- Non-comment lines of code
 KDSI- Thousands of delivered source instruction
2. Number of entities in ER diagram: ER model provides a static view of the project. It describes the entities
and their relationships. The number of entities in ER model can be used to measure the estimation of the size of
the project.
3. Total number of processes in detailed data flow diagram: Data Flow Diagram(DFD) represents the
functional view of software. The model depicts the main processes/functions involved in software and the flow
of data between them. Utilization of the number of functions in DFD to predict software size.

4. Function Point Analysis: In this method, the number and type of functions supported by the software are
utilized to find FPC(function point count). The steps in function point analysis are:
  Count the number of functions of each proposed type.
 Compute the Unadjusted Function Points(UFP).
 Find Total Degree of Influence(TDI).
 Compute Value Adjustment Factor(VAF).
 Find the Function Point Count(FPC).

Experiment – 10
Designing Test Suites

The SE VLabs Institute has been recently setup to provide state-of-the-art research facilities in the field of
Software Engineering. Apart from research scholars (students) and professors, it also includes quite a large
number of employees who work on different projects undertaken by the institution.
As the size and capacity of the institute is increasing with the time, it has been proposed to develop a Library
Information System (LIS) for the benefit of students and employees of the institute. LIS will enable the
members to borrow a book (or return it) with ease while sitting at his desk/chamber. The system also enables a
member to extend the date of his borrowing if no other booking for that particular book has been made. For the
library staff, this system aids them to easily handle day-to-day book transactions. The librarian, who has
administrative privileges and complete control over the system, can enter a new record into the system when a
new book has been purchased, or remove a record in case any book is taken off the shelf. Any non-member is
free to use this system to browse/search books online. However, issuing or returning books is restricted to valid
users (members) of LIS only.
The final deliverable would a web application (using the recent HTML 5), which should run only within the
institute LAN. Although this reduces security risk of the software to a large extent, care should be taken no
confidential information (eg., passwords) is stored in plain text.

As already discussed under the theory section, test case preparation could begin
right after requirements identification stage. It is desirable (and advisable) to create a
Requirements Traceability Matrix (RTM) showing a mapping from individual
requirement to test case(s). A simplified form of the RTM is shown in table 1 (the
numbers shown in this table are arbitrary; not specific to LIS).
Table 1: A simplified mapping from requirements to
test cases
Requirement # Test Case #
R1 TC1

R2 TC2, TC3, TC4

R3 TC5

R4 TC6

Table 1 states which test case should help us to verify that a specified feature has been implemented and
working correctly. For instance, if test case # TC6 fails, that would indicate requirement # R4 has not fully
realized yet. Note that it is possible that a particular requirement might need multiple test cases to verify
whether it has been implemented correctly.
To be specific to our problem, let us see how we can design test cases to verify the "User Login" feature. The
simplest scenario is when both user name and password have been typed in correctly. The outcome will be that
the user could then avail all features of LIS. However, there could be multiple unsuccessful conditions:
 User ID is wrong
 Password is wrong
 User ID & password are wrong
 Wrong password given twice consecutively
 Wrong password given thrice consecutively
 Wrong password given thrice consecutively, and security question answered correctly
 Wrong password given thrice consecutively, and security question answered incorrectly
We would create test case for the above stated login scenarios. These test cases together would constitute a test
suite to verify the concerned requirement. Table 2 shows the details of this test suite.
We would create test case for the above stated login scenarios. These test cases together would constitute a test
suite to verify the concerned requirement. Table 2 shows the details of this test suite.
In a similar way, test suites corresponding to other user requirements could be created as well. A good test plan can reduce
the burden of testing team by specifying what exactly they should focus on.

Viva Question

Q1.What is computer software?

A. Computer software is a complete package, which includes software

program, its documentation and user guide on how to use the software.
Q2. What is software process or Software Development Life Cycle
(SDLC)?

A.Software Development Life Cycle, or software process is the systematic

development of software by following every stage in the development
process namely, Requirement Gathering, System Analysis, Design, Coding,
Testing, Maintenance and Documentation in that order.

What are SDLC models

Q3

available?
A. There are several SDLC
models available such as
Waterfall Model,
Iterative Model, Spiral model,
V-model and Big-bang Model
etc
Q3.What are SDLC models available?

A. There are several SDLC models available such as Waterfall Model,

Iterative Model, Spiral model, V-model and Big-bang Model etc

Q.What is Software
configuration management?
A. Software Configuration
management is a process of
tracking and
 controlling the changes in
software in terms of the
requirements, design,
functions and development of
the product.
Q4.What is Software configuration management?

A. Software Configuration management is a process of tracking and

controlling the changes in software in terms of the requirements, design,
functions and development of the product.

Q.What is SRS?
A. SRS or Software
Requirement Specification is a
document produced at
the time of requirement
gathering process. It can be also
seen as a process
of refining requirements and
documenting them.
Q5.What is SRS?
A. SRS or Software Requirement Specification is a document produced at
the time of requirement gathering process. It can be also seen as a process
of refining requirements and documenting them.

What is software measure?

 A. Software Measures can be
understood as a process of
quantifying and
symbolizing various attributes
and aspects of software.
Q6.What is software measure?
A. Software Measures can be understood as a process of quantifying and
symbolizing various attributes and aspects of software.

Q7.What is level-0 DFD?

A. Highest abstraction level DFD is known as Level 0 DFD also called a

context level DFD, which depicts the entire information system as one
diagram concealing all the underlying details

Q8.What is data dictionary?

A. Data dictionary is referred to as meta-data. Meaning, it is a repository of
data about data. Data dictionary is used to organize the names and their

Q9.What are CASE tools?

A. CASE stands for Computer Aided Software Engineering. CASE tools are
set of automated software application programs, which are used to support,
accelerate and smoothen the SDLC activities.

Q10.Differentiate validation and verification?

A. Validation checks if the product is made as per user requirements

whereas verification checks if proper steps are followed to develop the
product.
Validation confirms the right product and verification confirms if the product
is built in a right way.

Q.Mentions some software

analysis & design tools?
 A. These can be: DFDs
(Data Flow Diagrams),
Structured Charts,
Structured English, Data
Dictionary, HIPO
(Hierarchical Input Process
Output) diagrams, ER (Entity
Relationship) Diagrams and
Decision tables.
Q11.Mentions some software analysis & design tools?

A. These can be: DFDs (Data Flow Diagrams), Structured Charts,

Structured English, Data Dictionary, HIPO (Hierarchical Input Process
Output) diagrams, ER (Entity Relationship) Diagrams and Decision tables.

Q.What is SRS?
A. SRS or Software
Requirement Specification is a
document produced at
the time of requirement
gathering process. It can be also
seen as a process
 of refining requirements and
documenting them.
Q12.What is SRS?

A. SRS or Software Requirement Specification is a document produced at

the time of requirement gathering process. It can be also seen as a process
of refining requirements and documenting them.

Q13.What is feasibility study?

A. It is a measure to assess how practical and beneficial the software

project development will be for an organization. The software analyzer
conducts a thorough study to understand economic, technical and
operational feasibility of the project.
Economic - Resource transportation, cost for training, cost of additional utilities
and tools and overall estimation of costs and benefits of the project.
Technical - Is it possible to develop this system ? Assessing suitability of
machine(s) and operating system(s) on which software will execute, existing
developers’ knowledge and skills, training, utilities or tools for project.
Operational - Can the organization adjust smoothly to the changes done as per
the demand of project ? Is the problem worth solving ?