Scribd
Upload
3 views

Software Engineering Lab 1

The document outlines the structure and purpose of a Software Requirements Specification (SRS), which details both functional and non-functional requirements for software development. It emphasizes the importance of clear communication between stakeholders, serves as a blueprint for the development process, and aids in project planning and validation. Additionally, it discusses user requirement specifications and the significance of data flow diagrams (DFDs) in understanding and analyzing system processes.

Uploaded by

MishtuDeep
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
3 views

Software Engineering Lab 1

The document outlines the structure and purpose of a Software Requirements Specification (SRS), which details both functional and non-functional requirements for software development. It emphasizes the importance of clear communication between stakeholders, serves as a blueprint for the development process, and aids in project planning and validation. Additionally, it discusses user requirement specifications and the significance of data flow diagrams (DFDs) in understanding and analyzing system processes.

Uploaded by

MishtuDeep
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 18

SOFTWARE ENGINEERING

SRS STRUCTURE

1. Introduction
1.1 Purpose
1.2 Intended Audience
1.3 Scope
1.4 Definitions
1.5 References

2. Overall Description
2.1 User Interfaces
2.2 System Interfaces
2.3 Constraints, assumptions and dependencies
2.4 User Characteristics

3. System Features and Requirements


3.1 Functional Requirements
3.2 Use Cases
3.3 External Interface Requirements
3.4 Logical database requirement
3.5 Nonfunctional Requirements

4. Deliver for Approval


SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
 SRS is a description of a software system to be developed.

 It lays out functional and non-functional requirements of the software to be developed.

 It may include a set of use cases that describe user interactions that the software must provide to the user for
perfect interaction.
 Serves as a blueprint for the design, development, and testing phases of the software lifecycle.

 Acts as a contract between the client and the development team, ensuring mutual understanding.

 Helps in resource planning by identifying the scope and effort needed for development.

 Supports project tracking and progress monitoring by serving as a reference document.

 Facilitates validation and verification by providing testable requirements.

 Allows for impact analysis when changes to requirements are proposed.

 Can include performance requirements, security constraints, and usability specifications to ensure comprehensive
coverage.
Purpose of an SRS:
 Acts as a blueprint for the development process.

 Ensures clear communication between stakeholders.

 Helps with project planning, design, development, and testing.Reduces chances of misunderstanding or scope
creep.

WHY IS AN SRS NECESSARY?
• Provides a clear, unambiguous description of the system's requirements.
• Ensures that both the client and developers agree on what the system will deliver.
• Serves as a baseline for software design, architecture, and coding.
• Helps in planning resources, timelines, and costs effectively.
• Prevents misunderstandings between stakeholders.
• Reduces the risk of building the wrong system.
• Facilitates verification and validation by defining expected functionalities.
• Makes testing easier as requirements can be mapped directly to test cases.
• Acts as a legal agreement between the client and the software development team.
• Protects both parties by documenting expectations.
• Helps manage changes in requirements during the software lifecycle.
• Provides a reference point for evaluating the impact of changes.
USER REQUIREMENT SPECIFICATION

 The user requirement(s) document (URD) or user requirement specification (URS) is a document
usually used in software engineering that specifies what the user expects the software to be able
to do.
 It is a contractual agreement.

• The URS captures user needs and expectations for the system, forming the foundation for the
development process.
• It is usually written in natural language so that both technical and non-technical stakeholders
can understand it easily.
• It serves as a baseline for validation, ensuring that the final system meets the user's needs.
FUNCTIONAL VS NON-FUNCTIONAL REQUIREMENTS

 Functional Requirements, which are  Non-Functional Requirements are expected

related to functional/working aspect of characteristics of target software. (Security,


Storage, Configuration, Performance, Cost,
software fall into this category.
Interoperability, Flexibility, Disaster recovery,
 Describes what the system should do Accessibility)
(features, behavior).  Describes how the system performs or constraints

 Derived from business needs, user tasks, on system design.


 Derived from user expectations, industry
and processes.
standards, regulations.
 Easier to test using functional testing (e.g.,
 Requires non-functional testing (e.g.,
black-box testing). performance, security).
 Examples: User login, data processing,  Examples: Load time, security, availability,
report generation. scalability.
SOFTWARE DESIGN APPROACHES

Function Oriented Design Object Oriented Design

 System is designed from a functional  System is viewed as a collection of objects


viewpoint. (i.e., entities).
 Top-down decomposition.  Bottom-up approach.

 Divide & Conquer approach.  UML (Unified Modeling Language) is used.

 DFD (Data Flow Diagram) is used.  Examples noted: Student, Faculty, Book.

 Examples noted: LMS (Library


Management System), Issue/Return.
DATA FLOW DIAGRAMS (DFD)
• A graphical tool, useful for communicating with users, managers, and other personnel.
• Useful for analyzing existing as well as proposed systems.
• Focus on the movement of data between external entities and processes, and between
processes and data stores.
• A relatively simple technique to learn and use.
For Example:
DFD Elements:
 External Entity

 Data Flows

 Processes

 Data Stores
WHY DFD?

Provides an overview of:


• What data a system processes
• What transformations are performed
• What data are stored
• What results are produced
Graphical nature makes it a good communication tool between:
• User and analyst
• Analyst and system designer
Purpose of DFD:
 To understand the flow of information in a system

 To analyze and design system processes clearly and efficiently.

 To break down complex systems into simpler parts.


DECOMPOSITION OF DFDS

• A system is too complex to be shown on a single DFD.


• Decomposition is the iterative process of exploding data flow diagrams to create more detail.
 Level 0 data flow diagrams may be exploded into successive low levels of detail. The next level
of detail would be a level 1 data flow diagram. Further decomposition leads to level 2 data flow
diagrams, which show even more detailed processes and data flows.
• The DFDs become linked together in a hierarchy, which would fully document the system.
WHY THERE ARE LEVELS OF DFD AND WHY IT IS
IMPORTANT?
Levels of Data Flow Diagrams (DFDs) are crucial for visualizing and understanding the flow of data within a system. They
provide a structured approach to represent processes, making it easier to analyze and enhance systems. Here are the
reasons why levels of DFD are important:
 Clarity and Understanding: Each level of DFD represents a different granularity of a system's processes. The 0-Level
DFD offers an overview of the entire system, while 1-Level and 2-Level DFDs provide detailed insights into specific
processes. This layered approach helps stakeholders understand complex systems more clearly.
 Breaking Down Complex Processes: Higher-level DFDs (like Level 0) simplify processes into a single overview, while
lower levels (like Level 2) can break a process into detailed subprocesses. This breakdown is essential for identifying
and managing specific functions within a system.
 Error Identification: By visualizing the flow of data across different levels, designers and analysts can identify potential
missteps in the system design. This can help in troubleshooting and optimizing processes.
 Improved Communication: DFDs facilitate better communication among stakeholders, as they provide a common
visual language to describe how data moves through a system. This is particularly useful in collaborative
environments such as system development.
 Documentation: DFDs serve as valuable documentation for current systems, which can assist in maintenance and
future upgrades. Understanding the data flow can guide developers and analysts in making informed decisions during
system changes.
EXAMPLE 1.1 OF LEVEL 0 DFD
EXAMPLE 1.2 OF LEVEL 1 DFD
EXAMPLE 2.1 OF LEVEL 0 DFD
EXAMPLE 2.2 OF LEVEL 1 DFD
EXAMPLE 3.1 OF LEVEL 0 DFD
EXAMPLE 3.2 OF LEVEL 1 DFD
EXAMPLE 3.3 OF LEVEL 2 DFD

You might also like