A

LAB FILE

on

SOFTWARE ENGINEERING

[IT-301]

Submitted by

Name:

Roll No.:

Submitted to the Department of Computer Science

in partial fulfillment of the requirements

for the degree of

Bachelor of Technology

in

Department of Computer Science

Amity School of Engineering and Technology

Amity University Greater Noida Campus
Plot no.48 A, Knowledge Park III, Greater Noida (U.P.) - 201308.
November- December, 2017
 INDEX
LAB NAME: SOFTWARE ENGINEERING LAB [LAB CODE: IT-301] [YEAR : III, SEMESTER : 5]

Name: _______________________________________________ Roll No.:____________________________

PAGE
S.NO. EXPERIMENT NAME DATE SIGNATURE REMARK
NO.

10

11

12

13

14

15

HOD Signature:_____________ Student Signature:_______________ Faculty Signature:_____________

Page 1 of 85
 Software Engineering Lab

Lab Name: Software Engineering Lab Lab Code: IT301 [UG][P/S - 2]

Branch: Computer Science and Engineering Semester: 5th

List of Experiments:
1. Develop software requirements specification for a given problem (The requirements specification should
include both functional and non-functional requirements.
2. Develop DFD Model (Level 0, Level 1 DFD and data dictionary) of the sample problem. (1 class)
3. Develop Structured design for the DFD model developed. (1 class)
4. Develop UML Use case model for a problem.
5. Develop Sequence Diagrams.
6. Develop Class diagrams.

Lab Objective:
The Software Engineering Lab has been developed by keeping in mind the following objectives:
1. To impart state-of-the-art knowledge on Software Engineering and UML in an interactive manner
through the Web.
2. Present case studies to demonstrate practical applications of different concepts.
3. Provide a scope to students where they can solve small, real life problems.

Lab Outcome:
1. Can produce the requirements and use cases the client wants for the software being produced.
2. Participate in drawing up the project plan. The plan will include at least extent and work assessments
of the project, the schedule, available resources, and risk management can model and specify the
requirements of mid-range software and their architecture.
3. create and specify such a software design based on the requirement specification that the software
can be implemented based on the design.
4. Can assess the extent and costs of a project with the help of several different assessment methods.

Page 2 of 85
 Lab/ Practical’s detail

Experiments:

1. Develop software requirements specification for a given problem.

2. Develop DFD Model (Level 0, Level 1 DFD and data dictionary) of the sample problem.
3. Develop Structured design for the DFD model developed. (1 class)
4. Class Diagram in UML
5. Use Case Diagram in UML
6. State Diagram in UML
7. Object Diagram in UML
8. Activity Diagram in UML
9. Sequence Diagram in UML
10.Collaboration Diagram in UML
11.Component Diagram in UML
12.Deployment Diagram in UML

Lab/ Practical/ Studio Assessment:

End Term
Continuous Assessment/Internal Assessment
Examination
(30)

Components Lab
Lab File Viva Attendance Total TOTAL
(Drop down) Performance
Weightage
10 10 5 5 30 70
(%)

Page 3 of 85
INTRODUCTION TO UNIFIIED MODELING LANGUAGE (UML)
UML
UML stands for Unified Modeling Language. This object-oriented system of notation has evolved from the
work of Grady Booch, James Rum Baugh, Ivar Jacobson, and the Rational Software Corporation. These
renowned computer scientists fused their respective technologies into a single, standardized model. Today,
UML is accepted by the Object Management Group (OMG) as the standard for modeling object oriented
programs.

Types of UML Diagrams

UML defines nine types of diagrams: class (package), object, use case, sequence, collaboration, state chart,
activity, component, and deployment.

Class Diagrams
Class diagrams are the backbone of almost every object oriented method, including UML. They describe the
static structure of a system.

Package Diagrams
Package diagrams are a subset of class diagrams, but developers sometimes treat them as a separate technique.
Package diagrams organize elements of a system into related groups to minimize dependencies between
packages.

Object Diagrams
Object diagrams describe the static structure of a system at a particular time. They can be used to test class
diagrams for accuracy.

Page 4 of 85
 Use Case Diagrams
Use case diagrams model the functionality of system using actors and use cases.

Sequence Diagrams
Sequence diagrams describe interactions among classes in terms of an exchange of messages over time.

Collaboration Diagrams
Collaboration diagrams represent interactions between objects as a series of sequenced messages. Collaboration
diagrams describe both the static structure and the dynamic behavior of a system.

State chart Diagrams

State chart diagrams describe the dynamic behavior of a system in response to external stimuli. Statechart
diagrams are especially useful in modeling reactive objects whose states are triggered by specific events.

Page 5 of 85
 Activity Diagrams
Activity diagrams illustrate 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.

Component Diagrams
Component diagrams describe the organization of physical software components, including source code, run-
time (binary) code, and executables.

Deployment Diagrams
Deployment diagrams depict the physical resources in a system, including nodes, components, and connections.

Page 6 of 85
 Basic Class Diagram Symbols and Notations

Class diagrams are the backbone of almost every object-oriented method including UML. They describe the
static structure of a system.

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 signifiy 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.

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

Page 7 of 85
 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 other. The diamond end in both a composition and aggregation
relationship points toward the "whole" class or the aggregate.

Page 8 of 85
 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 super class.
Package diagrams organize the elements of a system into related groups to minimize dependencies among them.
Basic Package Diagram Symbols and Notations

Packages
Use a tabbed folder to illustrate packages. Write the name of the package on the tab or inside the folder. Similar
to classes, you can also list the attributes of a package.

Page 9 of 85
 Visibility
Visibility markers signify who can access the information contained within a package. Private visibility means
that the attribute or the operation is not accessible to anything outside the package. Public visibility allows an
attribute or an operation to be viewed by other packages. Protected visibility makes an attribute or operation
visible to packages that inherit it only.

Dependency
Dependency defines a relationship in which changes to one package will affect another package. Importing is a
type of dependency that grants one package access to the contents of another package.

Page 10 of 85
 Basic Use Case Diagram Symbols and Notations

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.

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.

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 of 85
Page 12 of 85
 Basic Sequence Diagram Symbols and Notations

Sequence diagrams describe interactions among classes in terms of an exchange of messages over time.

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.

Various message types for Sequence and Collaboration diagrams

Page 13 of 85
 Lifielines
Lifielines 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.

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 14 of 85
 Basic Collaboration Diagram Symbols and Notations

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.

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 15 of 85
 Basic State-chart Diagram Symbols and Notations

A state chart 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.

States
States represent situations during the life of an object.

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 16 of 85
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 state chart diagram, it uses some of the same
modeling conventions.

Basic Activity Diagram Symbols and Notations

Action states
Action states represent the no interruptible actions of objects.

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.

Initial State

Page 17 of 85
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.

Swim lanes
Swim lanes group related activities into one column

Page 18 of 85
 Basic Component Diagram Symbols and Notations

A component diagram describes the organization of the physical components in a system.

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 19 of 85
 Basic Deployment Diagram Symbols and Notations

Deployment diagrams depict the physical resources in a system including nodes, components, and connections.

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.

Page 20 of 85
 Lab Experiment No.1

Develop requirements specification for a given problem

Objective:
To find the requirement specification (both functional and nonfunctional) of a given Problem.

Procedure:

Step 1:
Introduction:

Purpose
Identify the product whose software requirements are specified in this document. 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. Describe the different types of user that the document is intended for, such as developers, project
managers, marketing staff, users, testers, and documentation writers. 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.

Project Scope
Provide a short description of the software being specified and its purpose, including relevant benefits,
objectives, and goals. Relate the software to corporate goals or business strategies. If a separate vision and
scope document is available, refer to it rather than duplicating its contents here. An SRS that specifies the next
release of an evolving product should contain its own scope statement as a subset of the long-term strategic
product vision.

Step 2:
Overall Description

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. A simple diagram that
shows the major components of the overall system, subsystem interconnections, and external interfaces can be
helpful.

Product Features
Summarize the major features the product contains or the significant functions that it performs or lets the
user perform. 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 a class diagram, is often effective.

Page 21 of 85
User Classes and Characteristics
Identify the various user classes that you anticipate will use this product. User classes may be
differentiated based on frequency of use, subset of product functions used, technical expertise, security or
privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class.
Certain requirements may pertain only to certain user classes. Distinguish the favored user classes from those
who are less important to satisfy.

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.

Design and Implementation Constraints

Describe any items or issues that will limit the options available to the developers. These might include:
corporate or regulatory policies; 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).

Step 3:
System Features
This template illustrates organizing the functional requirements for the product by system features, the
major services provided by the product. You may prefer to organize this section by use case, mode of operation,
user class, object class, functional hierarchy, or combinations of these, whatever makes the most logical sense
for your product.

System Feature 1
Don’t really say “System Feature 1.” State the feature name in just a few words.

1 Description and Priority

Provide a short description of the feature and indicate whether it is of High, Medium, or Low
priority. You could also include specific priority component ratings, such as benefit, penalty, cost,
and risk (each rated on a relative scale from a low of 1 to a high of 9).

2 Stimulus/Response Sequences
List the sequences of user actions and system responses that stimulate the behavior defined for
this feature. These will correspond to the dialog elements associated with use cases.
3 Functional Requirements
Itemize the detailed functional requirements associated with this feature. These are the software
capabilities that must be present in order for the user to carry out the services provided by the feature, or
to execute the use case. Include how the product should respond to anticipated error conditions or invalid
inputs. Requirements should be concise, complete, unambiguous, verifiable, and necessary.

<Each requirement should be uniquely identified with a sequence number or a meaningful tag of
some kind.>

REQ-1:
REQ-2:
Page 22 of 85
Step 4:
External Interface Requirements

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., help) that will appear on every screen, keyboard
shortcuts, error message display standards, and so on. Define the software components for which a user
interface is needed. Details of the user interface design should be documented in a separate user interface
specification.

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, and communication protocols to be used.

Software Interfaces
Describe the connections between this product and other specific software components (name and
version), including databases, operating systems, 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. Refer to documents that describe detailed
application programming interface protocols. 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.

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.

Nonfunctional Requirements

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.

Safety 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.

Security Requirements
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.
Page 23 of 85
Refer to any external policies or regulations containing security issues that affect the product. Define any
security or privacy certifications that must be satisfied.

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.
Other Requirements
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.

Questions

1. Document the SRS of College automation system.

2. Document the SRS of Banking Management System.
3. Why we need SRS in any Project.
4. Which part of SRS is more important?
5. What is the difference between functional and nonfunctional requirement.

Page 24 of 85
 Lab Experiment No. 2

AIM OF THE EXPERIMENT:

Develop DFD model (level-0, level-1 DFD and Data dictionary) of the project.

OVERALL DESCRIPTION :
Data analysis attempts to answer four specific questions:
What processes make up a system?
What data are used in each process?
What data are stored?
What data enter and leave the system?

Data drive business activities and can trigger events (e.g. new sales order data) or be processed to provide
information about the activity. Data flow analysis, as the name suggests, follows the flow of data through
business processes and determines how organization objectives are accomplished. In the course of handling
transactions and completing tasks, data are input, processed, stored, retrieved, used, changed and output. Data
flow analysis studies the use of data in each activity and documents the findings in data flow diagrams,
graphically showing the relation between processes and data.

Physical and Logical DFDs

There are two types of data flow diagrams, namely physical data flow diagrams and logical data flow diagrams
and it is important to distinguish clearly between the two:

Physical Data Flow Diagrams

An implementation-dependent view of the current system, showing what tasks are carried out and how they are
performed. Physical characteristics can include:
Names of people
Form and document names or numbers
Master and transaction files
Equipment and devices used

Logical Data Flow Diagrams

An implementation-independent view of the a system, focusing on the flow of data between processes without
regard for the specific devices, storage locations or people in the system. The physical characteristics listed
above for physical data flow diagrams will not be specified.

Page 25 of 85
 Fig. A typical
DFD

ORDERS

CUSTOMER
S

INVOICES

Data Flow Diagram (DFD)

The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows the
different processing activities or functions that the system performs and the data interchange among these
functions. Each function is considered as a processing station (or process) that consumes some input data and
produces some output data. The system is represented in terms of the input data to the system, various
processing carried out on these data, and the output data generated by the system. A DFD model uses a very
limited number of primitive symbols [as shown in fig.1(a)] to represent the functions performed by a system
and the data flow among these functions.

Page 26 of 85
Symbols used for designing DFDs
Here, two examples of data flow that describe input and validation of data are considered. In Fig.1(b), the two
processes are directly connected by a data flow. This means that the ‘validate-number’ process can start only
after the ‘read-number’ process had supplied data to it. However in Fig. 1(c), the two processes are connected
through a data store. Hence, the operations of the two bubbles are independent. The first one is termed
‘synchronous’ and the second one ‘asynchronous’.

Importance of DFDs in a good software design

The main reason why the DFD technique is so popular is probably because of the fact that DFD is a very
simple formalism – it is simple to understand and use. Starting with a set of high-level functions that a system
performs, a DFD model hierarchically represents various sub-functions. In fact, any hierarchical model is
simple to understand. Human mind is such that it can easily understand any hierarchical model of a system –
because in a hierarchical model, starting with a very simple and abstract model of a system, different details of
the system are slowly introduced through different hierarchies. The data flow diagramming technique also
follows a very simple set of intuitive concepts and rules. DFD is an elegant modeling technique that turns out to
be useful not only to represent the results of structured analysis of a software problem, but also for several other
applications such as showing the flow of documents or items in an organization.

Page 27 of 85
Data dictionary
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. For example, a data dictionary entry may represent that the data grossPay consists of the
components regularPay and overtimePay.

Balancing a DFD
The data that flow into or out of a bubble must match the data flow at the next level of DFD. This is known as
balancing a DFD. The concept of balancing a DFD has been illustrated in fig. 5.3. In the level 1 of the DFD,
data items d1 and d3 flow out of the bubble 0.1 and the data item d2 flows into the bubble 0.1. In the next level,
bubble 0.1 is decomposed. The decomposition is balanced, as d1 and d3 flow out of the level 2 diagram and d2
flows in.

Questions
1 what are the symbols used in a DFD.
2. What is an external entity?
3. What is a context free diagram?
4. What is Data-dictionary?
5. Why balancing of DFD is required.

Page 28 of 85
 Lab Experiment No.3

Develop Structured design for the DFD model developed.

A DFD model of a system graphically depicts the transformation of the data input to the system to the final
result through a hierarchy of levels. A DFD starts with the most abstract definition of the system (lowest level)
and at each higher level

DFD, more details are successively introduced. To develop a higher-level DFD model, processes are
decomposed input data to these functions and the data output by these functions and represent them
appropriately in the diagram.

If a system has more than 7 high- level functional requirements, then some of the related requirements have to
be combined and represented in the form of a bubble in the level 1 DFD. Such a bubble can be split in the lower
DFD levels. If a system has less than three high-level functional requirements, then some of them need to be
split into their sub-functions so that we have roughly about 5 to 7 bubbles on the diagram.

Decomposition:-

Each bubble in the DFD represents a function performed by the system. The bubbles are decomposed into sub-
functions at the successive levels of the DFD.
Decomposition of a bubble is also known as factoring or exploding a bubble. Each bubble at any level of DFD
is usually decomposed to anything between 3 to 7 bubbles. Too few bubbles at any level make that level
superfluous. For example, if a bubble is decomposed to just one bubble or two bubbles, then this decomposition
becomes redundant. Also, too many bubbles, i.e. more than 7 bubbles at any level of a DFD makes the DFD
model hard to understand. Decomposition of a bubble should be carried on until a level is reached at which the
function of the bubble can be described using a simple algorithm.

Numbering of Bubbles:-

It is necessary to number the different bubbles occurring in the DFD. These numbers help in uniquely
identifying any bubble in the DFD by its bubble number. The bubble at the context level is usually assigned the
number 0 to indicate that it is the 0 level DFD. Bubbles at level 1 are numbered, 0.1, 0.2, 0.3, etc, etc. When a
bubble numbered x is decomposed, its children bubble are numbered x.1, x.2, x.3, etc. In this numbering
scheme, by looking at the number of a bubble we can unambiguously determine its level, its ancestors, and its
successors.
Example:-
A supermarket needs to develop the following software to encourage regular customers. For this, the customer
needs to supply his/her residence address, telephone number, and the driving license number. Each customer
who registers for this scheme is assigned a unique customer number (CN) by the computer. A customer can
present his CN to the check out staff when he makes any purchase. In this case, the value of his purchase is
credited against his CN. At the end of each year, the supermarket intends to award surprise gifts to 10 customers
who make the highest total purchase over the year. Also, it intends to award a 22 caret gold coin to every
customer whose purchase exceeded Rs.10,000. The entries against the CN are the reset on the day of every year
after the prize winners’ lists are generated.
Page 31 of 85
Questions

1. Draw the DFD of College Automation System.

2. How we balance a DFD.
3. Draw the DFD of Banking Mgmt System.
4. How we choose the level of DFD.
5. What is the need of DFD in a project.

Page 32 of 85
 Lab Experiment No.4

Develop UML Use case model for a problem

Objective :
To understand the users view of a project using Use case Diagram

Software Required :-
Visual Paradigm for UML 8.2

Procedure :-
You can draw use case diagrams in VP-UML as well as to document the event flows of use cases using the
flow-of-events editor of UML 8.2 .The steps are as follows.

Step 1:
Right click Use Case Diagram on Diagram Navigator and select New Use Case Diagram from the pop-up
menu.

Step 2:-
Enter name for the newly created use case
diagram in the text field of pop-up box on the
top left corner.

Page 33 of 85
Step 3:
Drawing a system
To create a system, select System on the diagram toolbar and then click it on the diagram pane. Finally, name
the newly created system when it is created.

Step 4:

Drawing an actor
To draw an actor, select Actor on the diagram toolbar and then click it on the diagram pane. Finally, name the
newly created actor when it is created.

Step 5 :-

Drawing a use case

Besides creating a use case through diagram toolbar, you can also create it through resource icon.
Move the mouse over a shape and press a resource icon that can create use case. Drag it and then release the
mouse button until it reaches to your preferred place. The source shape and the newly created use case are
connected. Finally, name the newly created use case.

Page 34 of 85
Step 6:-
Create a use case through resource icon
Line wrapping use case name
If a use case is too wide, for a better outlook, you may resize it by dragging the filled selectors. As a result, the
name of use case will be line-wrapped automatically.

Step 7:
Resize a use case

To create an extend relationship, move the mouse over a use case and press its resource iconExtend -> Use
Case. Drag it to your preferred place and then release the mouse button. The use case with extension points and
a newly created use case are connected. After you name the newly created use case, a pop-up dialog box will
ask whether you want the extension point to follow the name of use case. Click Yes if you want it to do so;
click NO if you want to enter another name for extension point.

Step 8:
Create an extend relationship
Drawing <<Include>> relationship
To create an include relationship, mouse over a use case and press its resource icon Include -> Use Case. Drag
it to your preferred place and then release the mouse button. A new use case together with an include
relationship is created. Finally, name the newly created use case.

Page 35 of 85
Step 9:
Include relationship is created
Structuring use cases with package
You can organize use cases with package when there are many of them on the diagram.
Select Package on the diagram toolbar (under Common category).

Step 10:
Create a package
Drag the mouse to create a package surrounding those use cases.

Step 11:
Surround use cases with
package
Finally, name the package.

Page 36 of 85
Step 12
Name the package
Assigning IDs to actors/Use cases
You may assign IDs to actors and use cases. By default, IDs are assigned with the order of object creation,
starting from one onwards. However, you can define the format or even enter an ID manually.
Defining the format of ID
To define the format of ID, select Tools > Options from the main menu to unfold the Options dialog box.
Select Diagramming from the list on the left hand side and select the Use Case Diagram tab on the right hand
side. You can adjust the format of IDs under Use Case Diagram tab. The format of ID consists of prefix,
number of digits and suffix.

Page 37 of 85
 Step 13:
Use Case Diagram tab
The description of options for ID generator format is shown below.
Option
Description
Prefix The prefix you enter in Prefix text field will be inserted before the number.
Num of digits The number of digits for the number. For example, when digit is 3, ID "1"
will become "001".
Suffix The suffix you enter in Suffix text field will be inserted behind the number.
Options for formatting ID
Showing ID on diagram
By default, ID is just a text property. It usually doesn't appear on diagram. However, you can make it shown
within a use case.
Right click on the diagram background, select Presentation Options and the specific model element display
option from the pop-up menu.

Step 14 :
Show ID on diagram
As a result, the use case is displayed with ID.

A use case with ID displayed

The feature of showing ID does only support for use case, but not
NOTE:
for actor.
ID assignment
There are several ways that you can assign an ID to a model element, including:
 Through the specification dialog box (Right click on the selected model element and select Open
Specification... from the pop-up menu)
 Through the Property Pane
Drawing business use case
1. Right click on a use case and select Model Element Properties > Business Model from the pop-up
menu.

Page 38 of 85
 Step 15:
1.
Click Business Model
2. After selected, an extra slash will be shown on the left edge of the use case.

Business model

And Finally The Use case Diagram is ready.

Questions
1.What is the importance of UML.
2.What are the UML foundations.
3. What is Use case.
4.Who are the actors in a UML.
5.What is boundary in a USE CASE.

Page 39 of 85
 Lab Experiment No.5

Develop sequence diagram

Objective :
To understand the interactions between objects that are represented as lifelines in a sequential order of a project
using Sequence Diagram.

Software Required :-
Visual Paradigm for UML 8.2

Procedure :-
A sequence diagram is used primarily to show the interactions between objects that are represented as lifelines
in a sequential order.

Step 1:-
Right click Sequence diagram on Diagram Navigator and select New Sequence Diagram from the pop-up
menu to create a sequence diagram.

Step 2:-
Enter name for the newly created sequence diagram in the text field of pop-up box on the top left corner.
Creating actor
To create actor, click Actor on the diagram toolbar and then click on the diagram.

Creating lifeline
To create lifeline, you can click LifeLine on the diagram toolbar and then click on the diagram.
Page 40 of 85
Alternatively, a much quicker and more efficient way is to use the resource-centric interface. Click on
the Message -> LifeLine resource beside an actor/lifeline and drag.

Step 3:-
Move the mouse to empty space of the diagram and then release the mouse button. A new lifeline will be
created and connected to the actor/lifeline with a message.

Auto extending activation

When create message between lifelines/actors, activation will be automatically extended.

Step 4:-
Using sweeper and magnet to manage sequence diagram
Sweeper helps you to move shapes aside to make room for new shapes or connectors. To use sweeper,
click Sweeper on the diagram toolbar (under the Tools category).

Page 41 of 85
The picture below shows the message specify visit time is being swept downwards, thus new room is made for
new messages.

Page 42 of 85
Step 5:-
You can also use magnet to pull shapes together. To use magnet, click Magnet on the diagram toolbar (under
the Tools category).

Magnet

Click on empty space of the diagram and drag towards top, right, bottom or left. Shapes affected will be pulled
to the direction you dragged.
The picture below shows when drag the magnet upwards, shapes below dragged position are pulled upwards.

Page 43 of 85
Step 6:-
Creating combined fragment for messages
To create combined fragment to cover messages, select the messages, right-click on the selection and
select Create Combined Fragment, and then select a combined fragment type (e.g. loop) from the popup
menu.

Page 44 of 85
 Step 7:-
A combined fragment of selected type will be created to cover the messages.

Step 8:-
Adding/removing covered lifelines
After you've created a combined fragment on the messages, you can add or remove the covered lifelines.
1. Move the mouse over the combined fragment and select Add/Remove Covered Lifeline... from the
pop-up menu.

Page 45 of 85
2. In the Add/Remove Covered Lifelines dialog box, check the lifeline(s) you want to cover or uncheck
the lifeline(s) you don't want to cover. Click OK button.

3. As a result, the area of covered lifelines is extended or narrowed down according to your selection.

Page 46 of 85
 Managing Operands
After you've created a combined fragment on the messages, you can also add or remove operand(s).
1. Move the mouse over the combined fragment and select Operand > Manage Operands... from the
pop-up menu.

Step 9:-
1. To remove an operand, select the target operand from Operands and click Remove button.
ClickOK button.

2. Otherwise, click Add button to add a new operand and then name it. Click OK button.

Developing sequence diagram with quick editor or keyboard shortcuts

Page 47 of 85
In sequence diagram, an editor appears at the bottom of diagram by default, which enables you to construct
sequence diagram with the buttons there. The shortcut keys assigned to the buttons provide a way to construct
diagram through keyboard. Besides constructing diagram, you can also access diagram elements listing in the
editor.

There are two panes, Lifelines and Messages. The Lifelines pane enables you to create different kinds of actors
and lifelines.

Butto
Shortcut Description
n
Alt-
To create an actor
Shift-A
Alt-
To create a general lifeline
Shift-L
Page 48 of 85
 Alt-
To create an <<entity>> lifeline
Shift-E
Alt-
To create a <<control>> lifeline
Shift-C
Alt-
To create a <<boundary>> lifeline
Shift-B
Alt-
To open the specification of the element chosen in quick editor
Shift-O
Ctrl-Del To delete the element chosen in quick editor
To link with the diagram, which cause the diagram element to be selected when
Ctrl-L
selecting an element in editor, and vice versa

Step 10:-
Buttons in Lifelines
pane
Editing messages
The Messages pane enables you to connect lifelines with various kinds of messages.

Messages pane in quick editor

Button
Sho
Descriptio
rtcu
n
t
Alt-Shift-
To create a message that connects actors/lifelines in diagram
M
Alt-Shift-
To create a duration message that connects actors/lifelines in diagram
D
Alt-Shift- To create a create message that connects actors/lifelines in diagram
Page 49 of 85
 C
Alt-Shift-
To create a self message on an actor/lifeline in diagram
S
Alt-Shift-
To create a recursive message on an actor/lifeline in diagram
R
Alt-Shift-
To create a found message that connects to an actor/lifeline
F
Alt-Shift-
To create a lost message from an actor/lifeline
L
Alt-Shift-
To create a reentrant message that connects actors/lifelines in diagram
E
Ctrl-Shift-
To swap the chosen message with the one above
Up
Ctrl-Shift-
To swap the chosen message with the one below
Down
Ctrl-R To revert the direction of chosen message
Alt-Shift-
To open the specification of the message chosen in quick editor
O
Ctrl-Del To delete the message chosen in quick editor
To link with the diagram, which cause the message to be selected when
Ctrl-L
selecting a message in editor, and vice versa
Buttons in Messages pane
Expanding and collapsing the editor
To hide the editor, click on the down arrow button that appears at the bar on top of the quick editor. To expand,
click on the up arrow button.

Collapse the quick

editor
Setting different ways of numbering sequence messages
You are able to set the way of numbering sequence messages either on diagram base or frame base.
Diagram-based sequence message
Right click on the diagram's background, select Sequence Number and then either Single Levelor Nested
Level from the pop-up menu.

Page 50 of 85
Step 11:-
If you choose Single Level, all sequence messages will be ordered with integers on diagram base. On the other
hand, if you choose Nested Level, all sequence messages will be ordered with decimal place on diagram base.

Right click on the diagram's background, select Sequence Number and then either Frame-based Single
Level or Frame-based Nested Level from the pop-up menu.

When you set the way of numbering sequence messages on frame base, the sequence messages in frame will
restart numbering sequence message since they are independent and ignore the way of numbering sequence
message outside the frame.

Page 51 of 85
QUESTIONS
1. Draw the Sequence diagram of College Automation System.
2. What is the need of sequence diagram in a project?
3. What is the difference between nested level and single level sequence?
4. Draw the Sequence diagram of Banking Management system.

Page 52 of 85
 Lab Experiment No. 6:

Develop Class diagram

Objective:-
To show diagrammatically the objects required and the relationships between them while developing a software
product.

Software Required :-
Visual Paradigm for UML 8.2

Procedure :-
Step 1:-
Right click Class Diagram on Diagram Navigator and select New Class Diagram from the pop-up menu to
create a class diagram.

Step 2:-
Creating class
To create class, click Class on the diagram toolbar and then click on the diagram.

A class will be created.

Creating association

Page 53 of 85
To create association from class, click the Association -> Class resource beside it and drag.

Drag to empty space of the diagram to create a new class, or drag to an existing class to connect to it. Release
the mouse button to create the association.

To create aggregation, use the Aggregation -> Class resource instead.

Step 3:-

To edit multiplicity of an association end, right-click near the association end,

select Multiplicity from the popup menu and then select a multiplicity.

To show the direction of an association, right click on it and select Presentation

Options > Show Direction from the pop-up menu.

Page 54 of 85
Step 4:-
The direction arrow is shown beside the association.

Creating generalization
To create generalization from class, click the Generalization -> Class resource beside it and drag.

Drag to empty space of the diagram to create a new class, or drag to an existing class to connect to it. Release
the mouse button to create the generalization.

Page 55 of 85
Creating attribute
To create attribute, right click the class and select Add > Attribute from the pop-up menu.

An attribute is created.

Creating attribute with enter key

After creating an attribute, press the Enter key, another attribute will be created. This method lets you create
multiple attributes quickly and easily.

Creating operation
To create operation, right click the class and select Add > Operation from the pop-up menu.

Page 56 of 85
An operation is created.

Similar to creating attribute, you can press the Enter key to create multiple operations continuously.
Drag-and-Drop reordering, copying and moving of class members
To reorder a class member, select it and drag within the compartment, you will see a thick black line appears
indicating where the class member will be placed.

Release the mouse button, the class member will be reordered.

To copy a class member, select it and drag to the target class while keep pressing the Ctrl key, you will see a
thick black line appears indicating where the class member will be placed. A plus sign is shown beside the
mouse cursor indicating this is a copy action.

Release the mouse button, the class member will be copied.

Page 57 of 85
To move a class member, select it and drag to the target class, you will see a thick black line appears indicating
where the class member will be placed. Unlike copy, do not press the Ctrl key when drag, the mouse cursor
without the plus sign indicates this is a move action.

Release the mouse button, the class member will be moved.

Model name completion for class

The model name completion feature enables quick creation of multiple views for the same class model. When
create or rename class, the list of classes is shown.

Type text to filter classes in the list.

Page 58 of 85
Press up or down key to select class in the list, press Enter to confirm. Upon selecting an existing class, all class
members and relationships are shown immediately.

Step 5:-
Continue to complete the diagram.

Page 59 of 85
Generalization set
A generalization set defines a particular set of generalization relationships that describe the way
in which a general classifier (or superclass) may be divided using specific subtypes. To define a generalization
set, select the generalizations to include, right click and select Generalization set > Create Generalization Set...
from the popup menu.

Step 6:-
Name the set in the Manage Generalization Sets dialog box, and confirm by pressing OK.

Page 60 of 85
The selected generalizations are grouped. Adjust the connector to make the diagram tidy.

Repeat the steps for other generalizations.

Page 61 of 85
Questions :
1.Define Class.
2.What is the difference between Class diagram and UML.
3. What is dependency.
4.What is composition.
5. Define Recursive Association.

Page 62 of 85
 Lab Experiment No. 7: Application

ONLINE COURSE REGISTRATION SYSTEM

Use Case Diagram

Page 63 of 85
Component Diagram

Page 64 of 85
 Class Diagram

Page 65 of 85
Sequence Diagram

Page 66 of 85
State Chart Diagram

Page 67 of 85
Activity Diagram

Page 68 of 85
Colloboration Diagram

Page 69 of 85
Class Diagram

Page 70 of 85
 Lab Experiment No. 8: Application

WITHDRAW MONEY: USE CASE SPECIFIICATION

1 Brief Description
This use case describes how the Bank Customer uses the ATM to withdraw money to his/her bank account.

2 Actors

2.1 Bank Customer

2.2 Bank

3 Preconditions

There is an active network connection to the Bank.

The ATM has cash available.

4 Basic Flow of Events

1. The use case begins when Bank Customer inserts their Bank Card.
2. Use Case: Validate User is performed.
3. The ATM displays the different alternatives that are available on this unit. [See Supporting Requirement SR-
xxx for list of alternatives]. In this case the Bank Customer always selects "Withdraw Cash".
4. The ATM prompts for an account. See Supporting Requirement SR-yyy for account types that shall be
supported.
5. The Bank Customer selects an account.
6. The ATM prompts for an amount.
7. The Bank Customer enters an amount.
8. Card ID, PIN, amount and account is sent to Bank as a transaction. The Bank Consortium replies with a
go/no go reply telling if the transaction is ok.
9. Then money is dispensed.
10. The Bank Card is returned.
11. The receipt is printed.
12. The use case ends successfully.

5 Alternative Flows

5.1 Invalid User

If in step 2 of the basic flow Bank Customer the use case: Validate User does not complete successfully, then
1. The use case ends with a failure condition

5.2 Wrong account

If in step 8 of the basic flow the account selected by the Bank Customer is not associated with this bank card,
then
1. The ATM shall display the message "Invalid Account – please try again".
2. The use case resumes at step 4.

Page 71 of 85
5.3 Wrong amount
If in step 7 in the basic flow, the Bank Customer enters an amount that can't be 'created' with the kind of in the
ATM (See Special Requirement WC-1 for valid amounts), then
1. The ATM shall display a the message indicating that the amount must be a multiple of the bills on hand, and
ask the Bank Customer to reenter the amount.
2. The use case resumes at step 7.

5.4 Amount Exceeds Withdrawal Limit

If in step 7 in the basic flow, the Bank Customer enters an amount that exceeds the withdrawal limit (See
Special Requirement WC-2 for maximum amount), then
1. the ATM shall display a warning message, and ask the Bank Customer to reenter the amount
2. The use case resumes at step 7

5.5 Amount Exceeds Daily Withdrawal Limit

If in step 8 in the basic flow, the Bank response indicates the daily withdrawal limit has been exceeded (this is
determined by the Bank and depends upon the specifiic account), then
1. The ATM shall display a warning message, and ask the Bank Customer to reenter the amount.
2. The use case resumes at step 7.

5.6 Insufficient Cash

If in step 7 in the basic flow, the Bank Customer enters an amount that exceeds the amount of cash available in
the ATM, then
1. The ATM will display a warning message, and ask the Bank Customer to reenter the amount.
2. The use case resumes at step 7.

5.7 No Response from Bank

If in step 8 of the basic there is no response from the Bank within 3 seconds, then
1. The ATM will re-try, up to three times.
2. If there is still no response from the Bank, the ATM shall display the message "Network unavailable – try
again later".
3. The ATM shall return the card.
4. The ATM shall indicate that it is "Closed".
5. The use case ends with a failure condition.

5.8 Money Not Removed

Ifi in step 9 of the basic flow the money is not removed from the machine within 15 seconds, then
1. The ATM shall issue a warning sound and display the message "Please remove cash".
2. If there is still no response from the Bank Customer within 15 seconds the ATM will re-tract the money and
note the failure in the log.
3. the use case end with a failure condition.

5.9 Quit
If at point prior to step 8 in the basic flow the Bank Customer selects Quit, then
1. The ATM shall print a receipt indicating the transaction was cancelled.
2. The ATM shall return the card.
3. The use case ends.

Page 72 of 85
6 Key Scenarios

6.1 No Response from Bank

7 Post-conditions

7.1 Successful Completion

The user has received their cash and the internal logs have been updated.

7.2 Failure Condition

The logs have been updated accordingly.

8 Special Requirements
[SpReq:WC-1] The ATM shall dispense cash in multiples of $20.
[SpReq2:WC-2] The maximum individual withdrawal is $500.
[SpReq:WC-1] The ATM shall keep a log, including date and time, of all complete and incomplete transactions
with the Bank.

Page 73 of 85
 Lab Experiment No. 9: Application

IEEE SOFTWARE REQUIREMENTS SPECIFIICATION TEMPLATE

5.1 Introduction The introduction of the SRS should provide an overview of the entire SRS. It should contain
the following Subsections:

a) Purpose;
b) Scope;
c) Definitions, acronyms, and abbreviations;
d) References;
e) Overview.

5.1.1 Purpose
This subsection should
a) Delineate the purpose of the SRS;
b) Specify the intended audience for the SRS.

5.1.2 Scope
This subsection should
a) Identify the software product(s) to be produced by name (e.g., Host DBMS, Report Generator, etc.);
b) Explain what the software product(s) will, and, ifi necessary, will not do;
c) Describe the application of the software being specified, including relevant benefits, objectives, and goals;
d) Be consistent with similar statements in higher-level specifications (e.g., the system requirements
specification), ifi they exist.

5.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.

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

5.1.5 Overview
This subsection should
a) Describe what the rest of the SRS contains;
b) Explain how the SRS is organized.

Page 74 of 85
5.2 Overall description
This section of the SRS should describe the general factors that affect the product and its requirements. This
section does not state specific requirements. Instead, it provides a background for those requirements, which are
defined in detail in Section 3 of the SRS, and makes them easier to understand. This section usually consists of
six subsections, as follows:

a) Product perspective;
b) Product functions;
c) User characteristics;
d) Constraints;
e) Assumptions and dependencies;
f) Apportioning of requirements.

5.2.1 Product perspective

This subsection of the SRS should put the product into perspective with other related products. If the product is
independent and totally self-contained, it should be so stated here. If the SRS defines a product that is a
component of a larger system, as frequently occurs, then this subsection should relate the requirements of that
larger system to functionality of the software and should identify interfaces between that system and the
software. A block diagram showing the major components of the larger system, interconnections, and external
interfaces can be helpful.

This subsection should also describe how the software operates inside various constraints. For example,
these constraints could include

a) System interfaces;
b) User interfaces;
c) Hardware interfaces;
d) Software interfaces;
e) Communications interfaces;
f) Memory;
g) Operations;
h) Site adaptation requirements.

5.2.1.1 System interfaces

This should list each system interface and identify the functionality of the software to accomplish the system
requirement and the interface description to match the system.

5.2.1.2 User interfaces

This should specify the following:
a) The logical characteristics of each interface between the software product and its users.
This includes those configuration characteristics (e.g., required screen formats, page or window layouts, content
of any reports or menus, or availability of programmable function keys) necessary to accomplish the software
requirements.
b)All the aspects of optimizing the interface with the person who must use the system.
This may simply comprise a list of do’s and dont’s on how the system will appear to the user. One example may
be a requirement for the option of long or short error messages. Like all others, these requirements should be
verifiable,

Page 75 of 85
5.2.1.3 Hardware interfaces
This should specify the logical characteristics of each interface between the software product and the hardware
components of the system. This includes configuration characteristics (number of ports, instruction sets, etc.). It
also covers such matters as what devices are to be supported, how they are to be supported, and protocols. For
example, terminal support may specify full-screen support as opposed to line-by-line support.

5.2.1.4 Software interfaces

This should specify the use of other required software products ( e.g., a data management system, an operating
system, or a mathematical package), and interfaces with other application systems (e.g., the linkage between an
accounts receivable system and a general ledger system). For each required software product, the following
should be provided:
Name;
Mnemonic;
Specification number;
Version number;
Source.
For each interface, the following should be provided:
Discussion of the purpose of the interfacing software as related to this software product.
Definition of the interface in terms of message content and format. It is not necessary to detail any well-
documented interface, but a reference to the document defining the interface is required.

5.2.1.5 Communications interfaces

This should specify the various interfaces to communications such as local network protocols, etc.

5.2.1.6 Memory constraints

This should specify any applicable characteristics and limits on primary and secondary memory.

5.2.1.7 Operations
This should specify the normal and special operations required by the user such as
a) The various modes of operations in the user organization (e.g., user-initiated operations)
b) Periods of interactive operations and periods of unattended operations;
c) Data processing support functions;
d) Backup and recovery operations.

5.2.1.8 Site adaptation requirements

This should
a) Define the requirements for any data or initialization sequences that are specific to a given site, mission, or
operational mode (e.g., grid values, safety limits, etc.);
b) Specify the site or mission-related features that should be modified to adapt the software to a particular
installation.

5.2.2 Product functions

This subsection of the SRS should provide a summary of the major functions that the software will perform. For
example, an SRS for an accounting program may use this part to address customer account maintenance,
customer statement, and invoice preparation without mentioning the vast amount of detail that each of those
functions requires.
Sometimes the function summary that is necessary for this part can be taken directly from the section of the
higher-level specification (if one exists) that allocates particular functions to the software product. Note that for
the sake of clarity
Page 76 of 85
a) The functions should be organized in a way that makes the list of functions understandable to the customer or
to anyone else reading the document for the First time.
b) Textual or graphical methods can be used to show the different functions and their relationships. Such a
diagram is not intended to show a design of a product, but simply shows the logical relationships among
variables.

5.2.3 User characteristics

This subsection of the SRS should describe those general characteristics of the intended users of the product
including educational level, experience, and technical expertise. It should not be used to state specific
requirements, but rather should provide the reasons why certain specific requirements are later specified

5.2.4 Constraints
This subsection of the SRS should provide a general description of any other items that will limit the developer
options. These include

a) Regulatory policies;
b) Hardware limitations (e.g., signal timing requirements);
c) Interfaces to other applications;
d) Parallel operation;
e) Audit functions;
f) Control functions;
g) Higher-order language requirements;
h) Signal handshake protocols (e.g., XON-XOFF, ACK-NACK);
i) Reliability requirements;
j) Criticality of the application;
k) Safety and security considerations.

5.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 may be that a specific operating system will be available
on the hardware designated for the software product. Ifi, in fact, the operating system is not available,
the SRS would then have to change accordingly.

5.2.6 Apportioning of requirements

This subsection of the SRS should identify requirements that may be delayed until future versions of the system.

5.3 Specific requirements

This section of the SRS should contain all of the software requirements to a level of detail sufficient to enable
designers to design a system to satisfy those requirements, and testers to test that the system satisfies those
requirements. Throughout this section, every stated requirement should be externally perceivable by users,
operators, or other external systems. These requirements should include at a minimum a description of every
input (stimulus) into the system, every output (response) from the system, and all functions performed by the
system in response to an input or in support of an output. As this is often the largest and most important part of
the SRS, the following principles apply:
a) Specific requirements should be stated in conformance with all the characteristics described in 4.3.
b) Specific requirements should be cross-referenced to earlier documents that relate.
c) All requirements should be uniquely identifiable.
d) Careful attention should be given to organizing the requirements to maximize readability.
Page 77 of 85
Before examining specific ways of organizing the requirements it is helpful to understand the various items that
comprise requirements as described in 5.3.1 through 5.3.7.

5.3.1 External interfaces

This should be a detailed description of all inputs into and outputs from the software system. It should
complement the interface descriptions in 5.2 and should not repeat information there.It should include both
content and format as follows:
a) Name of item;
b) Description of purpose;
c) Source of input or destination of output;
d) Valid range, accuracy, and/or tolerance;
e) Units of measure;
f) Timing;
g) Relationships to other inputs/outputs;
h) Screen formats/organization;
i) Window formats/organization;
j) Data formats;
k) Command formats;
l) End messages.

5.3.2 Functions
Functional requirements should define the fundamental actions that must take place in the software in accepting
and processing the inputs and in processing and generating the outputs. These are generally listed as shall
statements starting with The system shall
These include:
a) Validity checks on the inputs
b) Exact sequence of operations
c) Responses to abnormal situations, including
1) Overflow
2) Communication facilities
3) Error handling and recovery
d) Effect of parameters
e) Relationship of outputs to inputs, including
1) Input/output sequences
2) Formulas for input to output conversion
It may be appropriate to partition the functional requirements into sub functions or sub processes. This does not
imply that the software design will also be partitioned that way.

5.3.3 Performance requirements

This subsection should specify both the static and the dynamic numerical requirements placed on the software
or on human interaction with the software as a whole. Static numerical requirements may include the following:
a) The number of terminals to be supported;
b) The number of simultaneous users to be supported;
c) Amount and type of information to be handled.

Static numerical requirements are sometimes identified under a separate section entitled Capacity. Dynamic
numerical requirements may include, for example, the numbers of transactions and tasks and the amount of data
to be processed within certain time periods for both normal and peak workload conditions. All of these
requirements should be stated in measurable terms. For example,
Page 78 of 85
95% of the transactions shall be processed in less than 1 s.
rather than, An operator shall not have to wait for the transaction to complete.

NOTE Numerical limits applied to one specific function are normally specified as part of the processing
subparagraph description of that function.

5.3.4 Logical database requirements

This should specify the logical requirements for any information that is to be placed into a database. This may
include the following:
a) Types of information used by various functions;
b) Frequency of use;
c) Accessing capabilities;
d) Data entities and their relationships;
e) Integrity constraints;
f) Data retention requirements.

5.3.5 Design constraints

This should specify design constraints that can be imposed by other standards, hardware limitations, etc.

5.3.5.1 Standards compliance

This subsection should specify the requirements derived from existing standards or regulations. They may
include the following:
a) Report format;
b) Data naming;
c) Accounting procedures;
d) Audit tracing.
For example, this could specify the requirement for software to trace processing activity. Such traces are needed
for some applications to meet minimum regulatory or Financial standards. An audit trace requirement may, for
example, state that all changes to a payroll database must be recorded in a trace Fle with before and after values.

5.3.6 Software system attributes

There are a number of attributes of software that can serve as requirements. It is important that required
attributes be specified so that their achievement can be objectively verified. Subclasses 5.3.6.1 through 5.3.6.5
provide a partial list of examples.

5.3.6.1 Reliability
This should specify the factors required to establish the required reliability of the software system at time of
delivery.

5.3.6.2 Availability
This should specify the factors required to guarantee a defined availability level for the entire system such as
checkpoint, recovery, and restart.

5.3.6.3 Security
This should specify the factors that protect the software from accidental or malicious access, use, modification,
destruction, or disclosure. Specific requirements in this area could include the need to
a) Utilize certain cryptography techniques;
b) Keep specific log or history data sets;
c) Assign certain functions to different modules;
Page 79 of 85
d) Restrict communications between some areas of the program;
e) Check data integrity for critical variables.

5.3.6.4 Maintainability
This should specify attributes of software that relate to the ease of maintenance of the software itself. There may
be some requirement for certain modularity, interfaces, complexity, etc. Requirements should not be placed here
just because they are thought to be good design practices.

5.3.6.5 Portability
This should specify attributes of software that relate to the ease of porting the software to other host machines
and/or operating systems. This may include the following:
a) Percentage of components with host-dependent code;
b) Percentage of code that is host dependent;
c) Use of a proven portable language;
d) Use of a particular compiler or language subset;
e) Use of a particular operating system.

5.3.7 Organizing the specific requirements

For anything but trivial systems the detailed requirements tend to be extensive. For this reason, it is
recommended that careful consideration be given to organizing these in a manner optimal for understanding.
There is no one optimal organization for all systems. Different classes of systems lend themselves to different
organizations of requirements in Section 3 of the SRS. Some of these organizations are described in 5.3.7.1
Through 5.3.7.7.

5.3.7.1 System mode

Some systems behave quite differently depending on the mode of operation. For example, a control system may
have different sets of functions depending on its mode: training, normal, or emergency. When organizing this
section by mode, the outline in A.1 or A.2 should be used. The choice depends on whether interfaces and
performance are dependent on mode.

5.3.7.2 User class

Some systems provide different sets of functions to different classes of users. For example, an elevator control
system presents different capabilities to passengers, maintenance workers, and Fire Fighters. When organizing
this section by user class, the outline in A.3 should be used.

5.3.7.3 Objects
Objects are real-world entities that have a counterpart within the system. For example, in a patient monitoring
system, objects include patients, sensors, nurses, rooms, physicians, medicines, etc. Associated with each object
is a set of attributes (of that object) and functions (performed by that object). These functions are also called
services, methods, or processes. When organizing this section by object, the outline in A.4 should be used. Note
that sets of objects may share attributes and services. These are grouped together as classes.

5.3.7.4 Feature
A feature is an externally desired service by the system that may require a sequence of inputs to effect the
desired result. For example, in a telephone system, features include local call, call forwarding, and conference
call. Each feature is generally described in a sequence of stimulus-response pairs. When organizing this section
by feature, the outline in A.5 should be used.

Page 80 of 85
5.3.7.5 Stimulus
Some systems can be best organized by describing their functions in terms of stimuli. For example, the
functions of an automatic aircraft landing system may be organized into sections for loss of power, wind shear,
sudden change in roll, vertical velocity excessive, etc. When organizing this section by stimulus, the outline in
A.6 should be used.

5.3.7.6 Response
Some systems can be best organized by describing all the functions in support of the generation of a response.
For example, the functions of a personnel system may be organized into sections corresponding to all functions
associated with generating paychecks, all functions associated with generating a current list of employees, etc.
The outline in A.6 (with all occurrences of stimulus replaced with response) should be used.

5.3.7.7 Functional hierarchy

When none of the above organizational schemes prove helpful, the overall functionality can be organized into a
hierarchy of functions organized by common inputs, common outputs, or common internal data access. Data
flow diagrams and data dictionaries can be used to show the relationships between and among the functions and
data. When organizing this section by functional hierarchy, the outline in A.7 should be
used.

5.3.8 Additional comments

Whenever a new SRS is contemplated, more than one of the organizational techniques given in 5.3.7.7 may be
appropriate. In such cases, organize the specific requirements for multiple hierarchies tailored to the specific
needs of the system under specification. For example, see A.8 for an organization combining user class and
feature. Any additional requirements may be put in a separate section at the end of the SRS. There are many
notations, methods, and automated support tools available to aid in the documentation of
requirements. For the most part, their usefulness is a function of organization. For example, when organizing by
mode, Finite state machines or state charts may prove helpful; when organizing by object, object-oriented
analysis may prove helpful; when organizing by feature, stimulus-response sequences may prove helpful; and
when organizing by functional hierarchy, data flow diagrams and data dictionaries may prove helpful. In any of
the outlines given in A.1 through A.8, those sections called Functional Requirement may be described in native
language (e.g., English), in pseudo code, in a system definition language, or in four subsections titled:
Introduction, Inputs, Processing, and Outputs.

5.4 Supporting information

The supporting information makes the SRS easier to use. It includes the following:
a) Table of contents;
b) Index;
c) Appendixes.

5.4.1 Table of contents and index

The table of contents and index are quite important and should follow general compositional practices.

5.4.2 Appendixes
The appendixes are not always considered part of the actual SRS and are not always necessary. They may
include
a) Sample input/output formats, descriptions of cost analysis studies, or results of user surveys;
b) Supporting or background information that can help the readers of the SRS;
c) A description of the problems to be solved by the software;

Page 81 of 85
d) Special packaging instructions for the code and the media to meet security, export, initial loading, or other
requirements. When appendixes are included, the SRS should explicitly state whether or not the appendixes are
to be considered part of the requirements.

Page 82 of 85
 COMPANY NAME

Version <1.0>

Page 83 of 85
 Revision History

Date Version Description Author

October 30, 2017 V 01 First Draft Student Name

Page 84 of 85