SRS,UML,WBS

• Class Diagram
• Activity Diagram
• Sequence Diagram
• Data Flow Diagram(DFD)
• ER Diagram
Software Requirement
Specification(SRS):

Index:
• Definition
• Purpose of SRS
• SRS Format
• Types of Reader for Requirement Specification
• Characteristics of SRS
• Importance of SRS
What is an SRS?
 SRS is the official statement of what the system developers should implement.
 SRS is a complete description of the behavior of the system to be developed.
 SRS should include both a definition of user requirements and a specification of the system
requirements.
 The SRS fully describes what the software will do and how it will be expected to perform.
Purpose of SRS:

 The SRS precisely defines the software product that will be built.
 SRS used to know all the requirements for the software development and thus that will
help in designing the software.
 It provides feedback to the customer.
SRS Format:
1 Introduction
• Purpose
• Document Conventions
• Product Scope
• Reference
2 Overall Description
• Product Perspective
• Product Functions
• User Classes and Characteristics
• Operating Environment
• Design and Implementation constraints
• User Documentation
• Assumption and Dependencies
3 External Interface Requirements
• User Interfaces
• Hardware Interfaces
• Software Interfaces
• Communication Interfaces
 Continue………
4 System Features
• System Feature 1
• System Feature 2( and so on)
5 Other Nonfunctional Requirements
• Performance Requirements
• Safety Requirements
• Security Requirements
• Software Quality Attributes
• Business Rules
6 Other Requirements
• Appendix A: Glossary
• Appendix B: Analysis Models
 Types of Readers for Requirement
Specification:

System Customers Managers System Engineers

Specify the requirements Use the Requirements

and read them to check Document to plane a bid Use the requirements to
that they meet their needs. for he system and to plan understand what system is
Customer specify changes the system development to be deployed.
to the requirements. process.
Continue…………

System test Engineers System Maintains Engineers

Use the requirements to Use the requirements to

develop validation test for the understand the system and the
system. relationship between its parts.
Characteristics of SRS:
 Correct: Every requirement give in SRS is a requirement of the software.
 Unambiguous: Every requirement exactly one interpretation.
 Complete: Includes all functional, performance, design, external interface requirements;
definition of the response of the software to all inputs.
 Consistent: Internal Consistency.
 Ranked Importance: Essential vs desirable.
 Verifiable: A requirement is verifiable if and only if there exists some finite cost effective
process with which a person or a machine can check that the SW meets the requirement.
 Modification: SRS must be structured to permit effective modifications.
 Traceable: Origin of each requirement is clear.
Importance of SRS

1) Establish the basis for agreement between the customer and the suppliers on what the
software product is to do.
2) Reduce the development effort.
3) Provide a basis for estimating costs and schedules.
4) Provide a baseline for validation and verification.
5) Serve as a basis for enhancement.
Unified Modeling Language(UML)
What is UML?

• Unified Modeling Language for visualizing, specifying, constructing, documenting of

artifact of a software system.
• The blueprint of a system is written in it.
• UML is also used for modeling non-software system.
• It is standard for building object oriented and component base software system.
• UML is a notation system though which we can visualize a model of a system.
• It describe only design or structure of system.
Class Diagram:
• It depicts the static view of a model.
• It is the basic building block of the object oriented system.
• It illustrated the relationship between classes in the system.
• +sign with attributes or methods shows class member are public.
• -sign with attributes or methods shows class member are private.

Author

+Author_name: String
+Author_fname: String
+Author_bio: String
Author_email: String
 Activity Diagram:

• Activity Diagram is also dynamic view of the system.

• Activity Diagram similar to flow chart.
• Each activity consist of series of actions.
• Actions are represented by oval shapes.
• Actions are connected by arrow.
• Arrow shows the flow of the activity diagram.
• Activity diagram also shows decision point called decision node.
• Activity diagram is used to describe the individual se case.
• Use case is used to describe the user goal.
• Activity diagram can be used where we can use flow charts.
Activity Diagram
Sequence Diagram:

• Sequence diagrams provide a graphical representation of object interaction over time.

• One sequence diagram typically represents a single Use case ‘Scenario’ or flow of events.
• The diagrams show the flow of messages from one object to another and as such
correspond to the methods and events supported by a class/object.
Sequence Diagram:
Data Flow Diagram(DFD):

• DFD is the abbreviation for Data Flow Diagram. The flow of data of a system or a
process is represented by DFD.
• It also gives insight into the inputs and outputs of each entity and the process itself.
•  DFD does not have control flow and no loops or decision rules are present.
•  Specific operations depending on the type of data can be explained by a flowchart. 
• Data Flow diagrams are very popular because they help us to visualize the major steps and
data involved in software-system processes.
Components of DFD:

The Data Flow Diagram has 4 components:

• Process
Input to output transformation in a system takes place because of process function. The
symbols of a process are rectangular with rounded corners, oval, rectangle or a circle. The
process is named a short sentence, in one word or a phrase to express its essence
• Data Flow
Data flow describes the information transferring between different parts of the systems.
The arrow symbol is the symbol of data flow. A relatable name should be given to the flow
to determine the information which is being moved. Data flow also represents material
along with information that is being moved. Material shifts are modeled in systems that are
not merely informative. A given flow should only transfer a single type of information. The
direction of flow is represented by the arrow which can also be bi-directional.
 Continue…………
• Warehouse
The data is stored in the warehouse for later use. Two horizontal lines represent the symbol of the
store. The warehouse is simply not restricted to being a data file rather it can be anything like a
folder with documents, an optical disc, a filing cabinet. The data warehouse can be viewed
independent of its implementation. When the data flow from the warehouse it is considered as data
reading and when data flows to the warehouse it is called data entry or data updating.
Terminator
The Terminator is an external entity that stands outside of the system and communicates with the
system. It can be, for example, organizations like banks, groups of people like customers or
different departments of the same organization, which is not a part of the model system and is an
external entity. Modeled systems also communicate with terminator.
DFD:
 Data Flow Diagram:

Advantages of DFD Disadvantages of DFD

• It helps us to understand the functioning • At times DFD can confuse the
and the limits of a system. programmers regarding the system.
• It is a graphical representation which is • Data Flow Diagram takes long time to be
very easy to understand as it helps generated, and many times due to this
visualize contents. reasons analysts are denied permission to
• work on it.
Data Flow Diagram represent detailed
and well explained diagram of system
components.
• It is used as the part of system
documentation file.
• Data Flow Diagrams can be understood
by both technical or nontechnical person
because they are very easy to understand.
Entity Relationship Diagram(ERD):
• Entity Relationship Diagram, also known as ERD, ER Diagram or ER model, is a type of
structural diagram for use in database design.
• An ERD contains different symbols and connectors that visualize two important
information: The major entities within the system scope, and the inter-relationships
among these entities. And that's why it's called "Entity" "Relationship" diagram (ERD)!
• "Relationship" is about how these entities relate to each other within the system.
• While ER models are mostly developed for designing relational databases in terms of
concept visualization and in terms of physical database design, there are still other
situations when ER diagrams can help. Here are some typical use cases.
Use Cases:
• Database design - Depending on the scale of change, it can be risky to alter a database
structure directly in a DBMS. To avoid ruining the data in a production database, it is
important to plan out the changes carefully. ERD is a tool that helps. By drawing ER
diagrams to visualize database design ideas, you have a chance to identify the mistakes and
design flaws, and to make corrections before executing the changes in the database.
• Database debugging - To debug database issues can be challenging, especially when the
database contains many tables, which require writing complex SQL in getting the
information you need. By visualizing a database schema with an ERD, you have a full
picture of the entire database schema. You can easily locate entities, view their attributes
and identify the relationships they have with others. All these allow you to analyze an
existing database and to reveal database problems easier.
• Database creation and patching - Visual Paradigm, an ERD tool, supports a database
generation tool that can automate the database creation and patching process by means of
ER diagrams.
Continue………
So, with this ER Diagram tool, your ER design is no longer just
a static diagram but a mirror that reflects truly the physical
database structure.
•Aid in requirements gathering - Determine the requirements
of an information system by drawing a conceptual ERD that
depicts the high-level business objects of the system. Such an
initial model can also be evolved into a physical database model
that aids the creation of a relational database, or aids in the
creation of process maps and data flow modes.
Work Breakdown
Structure(WBS)
Introduction:
• Dividing complex projects to simpler and manageable tasks is the process identified as
Work Breakdown Structure(WBS).
• Usually, the project managers use this method for simplifying the project execution. In
WBS, much larger tasks are broken-down to manageable chunks of work. These chunks
can be easily supervised and estimated.
• In Project management and systems engineering, is a deliverable oriented decomposition
of a project into smaller components.
• A work breakdown structure element may be a product, data, a service, or any
combination. A WBS also provides the necessary framework for detailed cost estimating
and control along with providing guidance for schedule development and control.
Construction of a WBS

• Identifying the main deliverables of a project is the starting point for deriving a work
breakdown structure.
• This step is usually done by the project managers and the subject matter experts involved
in the project. Once this step is completed, the subject matter experts start breaking down
the high-level tasks into smaller chunks of work.
• In the process of breaking down the tasks, one can break them down into different levels of
detail. One can detail a high level task into ten sub tasks while another can detail the same
high level task into 20 sub tasks.
Goals for WBS

• Giving visibility to important work efforts.

• Giving visibility to risky work efforts.
• Illustrate the correlation between the activities and deliverables.
• Show clear ownership by task leaders.
Thank You 