Scribd
Upload
14 views

Experiment 4& 5

Uploaded by

DIKSHA SURYAWANSHI
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
14 views

Experiment 4& 5

Uploaded by

DIKSHA SURYAWANSHI
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

EXPERIMENT NO.

04

Aim: Do requirement analysis and develop Software Requirement Specification Sheet


(SRS).

Theory: Typically a SRS is written by a technical writer, a systems architect, or a


software programmer.

An SRS can be simply summarized into four Ds:

1. Define your product's purpose.


2. Describe what you're building
3. Detail the requirements.
4. Deliver it for approval.

An SRS gives us a complete picture of our entire project. It provides a single source of
truth that every team involved in development will follow. It is our plan of action and
keeps all our teams — from development to maintenance.

SRS (Software Requirement Specification)


Software Requirement Specification (SRS) Format as the name suggests, is a
complete specification and description of requirements of the software that need to be
fulfilled for the successful development of the software system. These requirements can
be functional as well as non-functional depending upon the type of requirement. The
interaction between different customers and contractors is done because it is necessary to
fully understand the needs of customers.
Scope of SRS
Defining the scope in an SRS document helps the customer understand the goals and
worth of the software. It also has details about how much it will cost to create and how
long it will take, so that the project’s limits are clear.

Writing a Good SRS for Your Project


Quality characteristics of a good Software Requirements Specification (SRS)
document include:
1. Complete: The SRS should include all the requirements for the software system,
including both functional and non-functional requirements.

2. Consistent: The SRS should be consistent in its use of terminology and formatting,
and should be free of contradictions.
3. Unambiguous: The SRS should be clear and specific, and should avoid using
vague or imprecise language.

4. Traceable: The SRS should be traceable to other documents and artefacts, such as
use cases and user stories, to ensure that all requirements are being met.

5. Verifiable: The SRS should be verifiable, which means that the requirements can
be tested and validated to ensure that they are being met.

6. Modifiable: The SRS should be modifiable, so that it can be updated and changed
as the software development process progresses.

7. Prioritized: The SRS should prioritize requirements, so that the most important
requirements are addressed first.

8. Testable: The SRS should be written in a way that allows the requirements to be
tested and validated.

9. High-level and low-level: The SRS should provide both high-level requirements
(such as overall system objectives) and low-level requirements (such as detailed
functional requirements).

10.Human-readable: The SRS should be written in a way that is easy for non-
technical stakeholders to understand and review.

The important parts of the Software Requirements Specification (SRS) document are:

1. Functional requirements of the system


2. Non-functional requirements of the system, and
3. Goals of implementation

These are explained as follows.

Functional Requirements
The purposeful requirements part discusses the functionalities needed from the system.
1. The system is taken into account to perform a group of high-level functions Fi.
The functional view of the system is shown in the below diagram
2. Each function Fi of the system can be considered as a transformation of a set of
input data Ii to the corresponding set of output knowledge Oi.
Non-functional Requirements
Non-functional necessities accommodate the characteristics of the system which may not
be expressed as functions – like the maintainability of the system, mobility of the system,
the usability of the system, etc. Non-functional requirements may include:
1. Reliability issues
2. Accuracy of results
3. Human-computer interface issues
4. Constraints on the system implementation, etc.

Goals of Implementation
The goals of implementation part documents some general suggestions relating to
development. These suggestions guide trade-off among style goals.
1. The goals of the implementation section would possibly document problems like
revisions to the system functionalities that will be needed within the future, new
devices to be supported within the future, reusability problems, etc.
2. These are the things that the developers would possibly detain their mind
throughout development in order that the developed system may meet some
aspects that don’t seem to be needed straightaway.
EXPERIMENT NO. 05

Aim: To perform the function oriented diagram: Data Flow Diagram (DFD) and Structured
chart.

Theory:
Function Oriented Design Strategies:
Function Oriented Design Strategies are as follows:
1. Data Flow Diagram (DFD):
A data flow diagram (DFD) maps out the flow of information for any process or
system. It uses defined symbols like rectangles, circles and arrows, plus short text
labels, to show data inputs, outputs, storage points and the routes between each
destination.
2. Data Dictionaries:
Data dictionaries are simply repositories to store information about all data items
defined in DFDs. At the requirement stage, data dictionaries contains data items.
Data dictionaries include Name of the item, Aliases (Other names for items),
Description / purpose, Related data items, Range of values, Data structure definition
/ form.
3. Structure Charts:
It is the hierarchical representation of system which partitions the system into black
boxes (functionality is known to users but inner details are unknown). Components
are read from top to bottom and left to right. When a module calls another, it views
the called module as black box, passing required parameters and receiving results.

Function Oriented Design is an approach to software design where the design is


decomposed into a set of interacting units where each unit has a clearly defined
function.
a. Generic Procedure:
Start with a high level description of what the software / program does. Refine
each part of the description one by one by specifying in greater details the
functionality of each part. These points lead to Top-Down Structure.
b. Problem in Top-Down design method:
Mostly each module is used by at most one other module and that module is
called its Parent module.
Solution to the problem:
Designing of reusable module. It means modules use several modules to do their
required functions.

You might also like