Prac cal 1: Develop So ware Requirements Specifica on (SRS)

Purpose of SRS:

An SRS provides a comprehensive descrip on of the intended func onality, constraints, and performance criteria of a
so ware project. It acts as a contract between the development team and stakeholders.

Sec ons of IEEE SRS Template:

1. Introduc on:

o Purpose: States the purpose of the so ware.

o Scope: Briefly describes the so ware, its func ons, and benefits.

o Defini ons, Acronyms, and Abbrevia ons: Lists key terms used in the document.

o References: Provides references to related documents.

o Overview: Describes what the document covers.

2. Overall Descrip on:

o Product Perspec ve: Describes the so ware context.

o Product Func ons: Lists major func ons of the so ware.

o User Characteris cs: Describes the intended users.

o Constraints: Lists system constraints like regulatory policies or hardware limita ons.

o Assump ons and Dependencies: Outlines assump ons affec ng the system.

3. Specific Requirements:

o Func onal Requirements: Detailed descrip on of system func onali es.

o External Interface Requirements: Specifies user, hardware, and so ware interfaces.

o Performance Requirements: Specifies performance criteria like response me and throughput.

o Design Constraints: Includes standards compliance and so ware limita ons.

o A ributes: Specifies reliability, availability, security, and maintainability.

4. Appendices:

o Addi onal informa on such as analysis models, data descrip ons, and glossary.

Example: Online Course Registra on System

1. Introduc on:

 Purpose: The system enables students to register for courses online, view schedules, and receive
no fica ons.

 Scope: This system will replace manual registra on, reducing errors and processing me.

 Defini ons: Terms like "student," "course," and "registra on" are defined.

 References: University course catalog, academic policies.

2. Overall Descrip on:

 Product Func ons: Register for courses, manage schedules, generate reports.

 User Characteris cs: Students and administrators with basic computer skills.

 Constraints: Must comply with university regula ons and be accessible 24/7.

 Assump ons: Students have access to the internet.

3. Specific Requirements:

 Func onal Requirements:

o Students can search and register for courses.

o Administrators can approve or reject registra ons.

 External Interface Requirements:

o Web-based interface for students.

o API integra on with the university's student informa on system.

 Performance Requirements: The system should handle 1000 simultaneous users with a maximum response
me of 2 seconds.

 Design Constraints: Follows university branding guidelines.

 A ributes: System up me of 99.9%, secure login using university creden als.

4. Appendices:

 Data dic onary, use case diagrams, and glossary.

Prac cal 2: Develop DFD Model (Level-0, Level-1 DFD, and Data Dic onary)

Purpose of DFDs:

Data Flow Diagrams (DFDs) provide a graphical representa on of the flow of data through a system, illustra ng how
inputs are processed into outputs through various processes.

Steps to Develop DFDs:

1. Level-0 DFD (Context Diagram):

 Provides an overview of the system, showing the system boundary, external en es interac ng with the
system, and the major data flows between them.

2. Level-1 DFD:

 Breaks down the main process into sub-processes.

 Shows more detailed data flow between processes, data stores, and external en es.

3. Data Dic onary:

 A structured repository that contains defini ons of all data elements, data flows, data stores, and processes
used in the DFDs.

 Provides details such as data types, lengths, rela onships, and constraints.
Example: Library Management System

1. Level-0 DFD:

 External En es:

o User (Student/Librarian)

o Book Supplier

 Main Process:

o Library Management System

 Data Flows:

o Book requests from users.

o Issued books informa on to users.

o Book orders to suppliers.

[User] --> (Request Book) --> [Library Management System]

[Library Management System] --> (Issue Book) --> [User]

[Library Management System] --> (Order Books) --> [Supplier]

2. Level-1 DFD:

 Sub-processes:

o Manage User Accounts

o Process Book Requests

o Maintain Book Inventory

 Data Stores:

o User Database

o Book Inventory Database

 Data Flows:

o User data, book request details, inventory updates.

(Process Book Requests) --> (Check Availability) --> [Book Inventory Database]

[Book Inventory Database] --> (Provide Book Details) --> (Issue Book)

3. Data Dic onary:

 Data Elements:

o User_ID: Unique iden fier for each user (Type: String, Length: 10).

o Book_ID: Unique iden fier for each book (Type: String, Length: 10).

o Request_Date: Date of book request (Type: Date).

 Data Flows:

o Book_Request: Flow of data from user to system containing User_ID, Book_ID, and Request_Date.
 o Issue_Details: Flow of data from system to user containing Book_ID, Issue_Date, Due_Date.

Prac cal 3: Develop Structured Design for the DFD Model

Purpose of Structured Design:

Structured design transforms the data flow diagrams into a modular and hierarchical structure, focusing on the
system's architecture, modules, and their interac ons. This approach enhances maintainability, scalability, and clarity
in the system's implementa on.

Steps to Develop Structured Design:

1. Iden fy Modules:

 Break down the system into smaller, manageable modules.

 Each module corresponds to a process or sub-process from the DFD.

2. Define Module Hierarchy:

 Organize modules into a hierarchy, showing parent-child rela onships.

 The top-level module represents the en re system, while sub-modules represent individual processes.

3. Specify Interfaces and Interac ons:

 Define how modules interact with each other through interfaces.

 Specify input and output for each module.

4. Create Structured Chart:

 Use a graphical representa on to depict the hierarchy and interac ons of modules.

Example: Library Management System

1. Iden fy Modules:

 Main Module: Library Management System

 Sub-Modules:

o User Account Management

o Book Request Processing

o Inventory Maintenance

o Book Issuance

o Supplier Interac on

2. Define Module Hierarchy:

Library Management System

├── User Account Management

├── Book Request Processing

│ └── Update Inventory

├── Inventory Maintenance

└── Supplier Interac on

└── Order Books

3. Specify Interfaces and Interac ons:

 User Account Management: Handles user login, registra on, and account details.

o Input: User creden als, personal details.

o Output: User authen ca on status, account informa on.

 Book Request Processing: Manages book search, request, and status.

o Input: Book request details.

o Output: Book availability status, request confirma on.

 Inventory Maintenance: Updates book stock and records new arrivals.

o Input: Book details, stock updates.

o Output: Updated inventory records.

 Supplier Interac on: Handles book orders and delivery confirma ons.

o Input: Book order details.

o Output: Order confirma on, delivery status.

4. Structured Chart:

[Library Management System]

+-- [User Account Management]

+-- [Book Request Processing]

| |

| +-- [Check Availability]

| |

| +-- [Update Inventory]

+-- [Inventory Maintenance]

+-- [Supplier Interac on]

+-- [Order Books]

Purpose of Structural UML Diagrams:

Structural UML diagrams capture the sta c structure of a system, showing how system components relate to each
other. They provide a blueprint for construc ng the system's architecture.

Types of Structural UML Diagrams:

1. Class Diagram:

 Depicts the system's classes, a ributes, methods, and rela onships.

 Shows inheritance, associa on, aggrega on, and composi on.

2. Object Diagram:

 A snapshot of instances of classes at a specific point in me.

 Represents objects and their rela onships.

3. Component Diagram:

 Represents the physical components or modules of the system.

 Shows dependencies among so ware components.

4. Deployment Diagram:

 Illustrates the physical deployment of ar facts on nodes.

 Represents the hardware environment where components are deployed.

Example: Online Shopping System

1. Class Diagram:

 Classes:

o User: A ributes: userID, name, email.

o Product: A ributes: productID, name, price.

o Order: A ributes: orderID, date, totalAmount.

o Rela onships:

 User has Order (1-to-many).

 Order includes Product (many-to-many).

[User]

| userID : String

| name : String

| email : String
 |

+-- [Order]

| orderID : String

| date : Date

| totalAmount : Double

+-- [Product]

| productID : String

| name : String

| price : Double

2. Object Diagram:

 Objects:

o User: JohnDoe

o Order: Order1234

o Product: Laptop, Product: Mouse

 Rela onships:

o JohnDoe has Order1234.

o Order1234 includes Laptop and Mouse.

[JohnDoe: User]

+-- [Order1234: Order]

+-- [Laptop: Product]

+-- [Mouse: Product]

3. Component Diagram:

 Components:

o Web Interface

o Order Processing System

o Payment Gateway

 Dependencies:

o Web Interface depends on Order Processing System.

o Order Processing System interacts with Payment Gateway.

[Web Interface] --> [Order Processing System] --> [Payment Gateway]

4. Deployment Diagram:
  Nodes:

o Client Machine

o Web Server

o Database Server

 Ar facts:

o Web Applica on

o Database

 Deployment:

o Web Applica on deployed on Web Server.

o Database deployed on Database Server.

[Client Machine] --> [Web Server]

+-- [Web Applica on]

[Database Server]

+-- [Database]

Prac cal 5: Develop Behavioral UML Diagrams of the Given Project

Purpose of Behavioral UML Diagrams:

Behavioral UML diagrams illustrate the dynamic aspects of the system, focusing on the behavior of objects, their
interac ons, and the flow of ac vi es.

Types of Behavioral UML Diagrams:

1. Use Case Diagram:

 Depicts the system's func onality from a user's perspec ve.

 Shows actors (users or external systems) and their interac ons with use cases (func onali es).

2. Sequence Diagram:

 Illustrates the sequence of messages exchanged between objects to carry out a specific func on or process.

 Highlights the order of interac ons over me.

3. Ac vity Diagram:

 Represents the flow of control or data from one ac vity to another.

 Emphasizes the flow of processes and the decision points within the system.

4. State Diagram:
  Shows the states of an object and transi ons between those states due to events.

 Useful for modeling the dynamic behavior of a system or an object.

Example: Online Booking System

1. Use Case Diagram:

 Actors:

o Customer

o Administrator

 Use Cases:

o Search for Services

o Book Service

o Cancel Booking

o Manage Bookings

[Customer]

+-- (Search for Services)

+-- (Book Service)

+-- (Cancel Booking)

[Administrator]

+-- (Manage Bookings)

2. Sequence Diagram:

 Scenario: Booking a Service

o Customer searches for a service.

o System displays available services.

o Customer selects a service.

o System confirms booking and updates records.

Customer --> System: Search for Services

System --> Customer: Display Services

Customer --> System: Select Service

System --> Customer: Confirm Booking

System --> Database: Update Records

3. Ac vity Diagram:
  Process: Booking a Service

o Start → Search Services → Select Service → Confirm Booking → End

o Includes decision points such as "Service Available?" leading to either booking confirma on or error
message.

(Start) --> [Search Services] --> [Select Service] --> [Service Available?]

| Yes | No

| |

[Confirm Booking] [Display Error]

(End)

4. State Diagram:

 Object: Booking

o States: New → Confirmed → Completed or Cancelled

o Transi ons: Created by customer, confirmed by system, completed a er service, or cancelled by

[New] --> [Confirmed]

[Confirmed] --> [Completed]

[Confirmed] --> [Cancelled]