SOFTWARE ENGINEERING-DATA FLOW DIAGRAM(DFD) AND BASICS.pptx

SOFTWARE ENGINEERING

1. SOFTWARE ENGINEERING

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

3. 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. Example (Functional Requirement):"The system shall allow users to log in using a valid username and password."

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

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

6. Functional vs Non-Functional Requirements Functional Requirements , which are related to functional/working aspect of software fall into this category. Describes what the system should do (features, behavior). Derived from business needs , user tasks , and processes . Easier to test using functional testing (e.g., black-box testing). Examples: User login, data processing, report generation. Non-Functional Requirements are expected characteristics of target software. (Security, Storage, Configuration, Performance, Cost, Interoperability, Flexibility, Disaster recovery, Accessibility) Describes how the system performs or constraints on system design. Derived from user expectations , industry standards , regulations . Requires non-functional testing (e.g., performance, security). Examples: Load time, security, availability, scalability.

7. Software Design Approaches Function Oriented Design System is designed from a functional viewpoint. Top-down decomposition. Divide & Conquer approach. DFD (Data Flow Diagram) is used. Examples noted: LMS (Library Management System), Issue/Return. Object Oriented Design System is viewed as a collection of objects (i.e., entities). Bottom-up approach. UML (Unified Modeling Language) is used. Examples noted: Student, Faculty, Book.

8. 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. DFD Elements: External Entity Data Flows Processes Data Stores For Example:

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

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

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

12. EXAMPLE 1.1 OF LEVEL 0 DFD

13. EXAMPLE 1.2 OF LEVEL 1 DFD

14. EXAMPLE 2.1 OF LEVEL 0 DFD

15. EXAMPLE 2.2 OF LEVEL 1 DFD

16. EXAMPLE 3.1 OF LEVEL 0 DFD

17. EXAMPLE 3.2 OF LEVEL 1 DFD

18. EXAMPLE 3.3 OF LEVEL 2 DFD