Laboratory file on
SOFTWARE ENGINEERING AND METHODOLOGY
School of Engineering and Technology
Department of Computer Science and Engineering
CSP 357
SUBMITTED BY:
Deepak Yadav
210101160
SUBMITTED TO:
Mr. Mohammad Asim
(Assistant Professor)
Sharda University
Greater Noida, Uttar Pradesh
EXPERIMENT - 1
Objective
To create a comprehensive Software Requirement Specification (SRS) document for the Inventory
Management System.
SRS Document Structure
The SRS document will follow the IEEE standard format, which typically includes the following sections:
1. Introduction
• Purpose
• Scope
• Definitions, Acronyms, and Abbreviations
• References
• Overview
2. Overall Description
• Product Perspective
• Product Functions
• User Classes and Characteristics
• Operating Environment
• Design and Implementation Constraints
• Assumptions and Dependencies
3. Specific Requirements
• Functional Requirements
• Non-Functional Requirements
4. Appendices
• Additional Information
1. Introduction
1.1 Purpose
The purpose of this SRS document is to provide a detailed description of the Inventory Management
System. It will serve as a guide for the development team and stakeholders to understand the requirements
and functionalities of the system.
1.2 Scope
The Inventory Management System will allow users to manage inventory levels, track stock movements,
and generate reports. The system will include features for adding, updating, and deleting inventory items.
1.3 Definitions, Acronyms, and Abbreviations
• IMS: Inventory Management System.
• SRS: Software Requirement Specification.
1.4 References
• IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications.
1.5 Overview
This document outlines the functional and non-functional requirements for the Inventory Management
System.
2. Overall Description
2.1 Product Perspective
The Inventory Management System is a web-based application that will be accessible via standard web
browsers. It will interact with a database to manage inventory data.
2.2 Product Functions
• User registration and authentication
• Add, update, and delete inventory items
• Track stock levels and movements
• Generate inventory reports
2.3 User Classes and Characteristics
• Inventory Manager: Users who manage inventory items and stock levels.
• Admin: Users who manage user accounts and system settings.
2.4 Operating Environment
The system will operate in a web environment, compatible with major browsers (Chrome, Firefox, Safari)
and will be hosted on a cloud server.
2.5 Design and Implementation Constraints
• The system must comply with data protection regulations.
• The website must be responsive and accessible on mobile devices.
2.6 Assumptions and Dependencies
• Users will have internet access to use the website.
• The system will depend on a database for data storage.
3. Specific Requirements
3.1 Functional Requirements
1. User Registration and Login
• Users must be able to register with an email and password.
• Users must be able to log in using their credentials.
2. Inventory Management
• Users must be able to add new inventory items.
• Users must be able to update existing inventory items.
• Users must be able to delete inventory items.
3. Stock Tracking
• The system must track stock levels for each item.
• Users must be able to view stock movements.
4. Reporting
• Users must be able to generate reports on inventory levels and movements.
3.2 Non-Functional Requirements
1. Performance Requirements
• The system should handle up to 500 concurrent users.
• Page load time should not exceed 3 seconds.
2. Security Requirements
• User data must be encrypted during transmission.
• The system must implement secure authentication mechanisms.
3. Usability Requirements
• The website must have an intuitive user interface.
• The system must provide help and support documentation.
4. Appendices
• Additional diagrams (e.g., use case diagrams, flowcharts) can be included here to support the
requirements.
EXPERIMENT - 2
Draw the user’s view analysis for the suggested system: Use case diagram, Activity Diagram and
State chart Diagram.
Use Case Diagram:
A use case diagram illustrates the system's functionality from the user's perspective. It shows the interactions
between actors (users or external systems) and use cases (specific functionalities or features).
Actors: These represent the external entities interacting with the system. Actors can be people, other systems, or
even time-triggered events.
Use Cases: These are specific functionalities or features that the system offers to its users. Each use case represents a
specific interaction or task that a user can perform.
Activity Diagram:
An activity diagram illustrates the workflow or process flow of a specific use case or scenario. It can help you detail
how a particular use case is carried out.
Actions: These represent specific steps or actions within the workflow.
Control Flow: Arrows show the sequence of actions, indicating the order in which they occur.
Decision Nodes: These represent decision points where the workflow can take different paths based on conditions.
Fork and Join Nodes: These indicate parallel processing and synchronization of flows.
State Chart Diagram:
A state chart diagram shows the different states that an object or system can be in and the transitions between these
states. It's often used to model the behavior of an entity over time.
States: These represent conditions or phases that an object can be in.
Transitions: Arrows show the triggers and conditions that cause an object to move from one state to another. Events:
Events are triggers or stimuli that initiate state transitions.
Actions: Actions represent the activities or operations that occur when a state transition happens.
EXPERIMENT - 3
Draw the structural view diagram for the system: Class diagram, object diagram and Sequence
diagram.
Class Diagram:
A class diagram is used to represent the static structure of a system, showcasing the classes, their attributes, methods,
and their relationships.
Classes: Rectangles represent classes. Each class includes the class name, attributes, and methods.
Attributes: These are represented as name: type pairs within the class rectangle.
Methods: These are listed beneath the class name within the class rectangle.
Associations: Lines connecting classes represent associations or relationships between classes. You can label
associations to indicate their nature (e.g., one-to-many).
Inheritance: An open arrowhead line indicates inheritance or a parent-child relationship between classes.
Sequence Diagram:
A sequence diagram illustrates the interactions and messages exchanged between objects or components in a
particular scenario or use case.
Lifelines: Vertical lines represent the lifelines of objects or actors involved in the scenario.
Messages: Horizontal arrows show the flow of messages between objects. Labels on the arrows describe the type
of message or method call.
Activation Bars: Activation bars show the period during which an object is active and processing a message. Return
Messages: Dashed arrows represent return messages when an object responds to a message.
Object Diagram:
An object diagram represents a specific snapshot of a system at a particular point in time, showing instances of
classes and their relationships.
Objects: These are represented by rectangles with the object's name and its class name inside.
Links: Lines connecting objects show relationships between objects. Label these lines to describe the nature of the
relationship.
Attributes and Values: You can show the values of the object's attributes within the object rectangle.
EXPERIMENT - 4
Perform Unit testing of calculator program using Junit testing framework.
import org.junit.Test;
import static org.junit.Assert.assertEquals;
public class CalculatorTest {
@Test
public void testAddition() {
Calculator calculator = new Calculator();
assertEquals(5, calculator.add(2, 3));
}
@Test
public void testSubtraction() {
Calculator calculator = new Calculator();
assertEquals(2, calculator.subtract(5, 3));
}
@Test
public void testMultiplication() { Calculator
calculator = new Calculator();
assertEquals(15, calculator.multiply(5, 3));
}
@Test
public void testDivision() {
Calculator calculator = new Calculator();
assertEquals(2, calculator.divide(10, 5));
}
}
EXPERIMENT - 5
Perform Integration testing of calculator program using Junit testing framework
you have a Calculator class that provides methods for performing arithmetic operations: public
class Calculator {
public int add(int a, int b) { return a
+ b;
}
public int subtract(int a, int b)
{ return a - b;
}
public int multiply(int a, int b)
{ return a * b;
}
public int divide(int a, int b) { if (b
== 0) {
throw new ArithmeticException("Division by zero");
}
return a / b;
}
}
Now, let's create an integration test for the Calculator class to verify that the operations work correctly when
combined:
java
import org.junit.Test;
import static org.junit.Assert.assertEquals; public
class CalculatorIntegrationTest {
@Test
public void testAdditionAndSubtraction() { Calculator
calculator = new Calculator();
int result = calculator.subtract(calculator.add(5, 3), 2);
assertEquals(6, result);
}
@Test
public void testMultiplicationAndDivision() { Calculator
calculator = new Calculator();
int result = calculator.divide(calculator.multiply(4, 6), 2);
assertEquals(12, result);
}
}
EXPERIMENT - 6
Design Test Case for Inventory Management System based on System Specification.
Designing test cases for an Inventory Management System (IMS) based on system specifications involves
creating scenarios and inputs to validate that the system functions correctly. Below, I'll provide a sample set of test
cases that cover various aspects of an IMS. Please note that this is a simplified example, and in a real- world
scenario, you would need to create more extensive test cases.
1. Test Case: Adding a New Item
Input:
Item Name: "Widget A" Item
Category: "Electronics" Item
Quantity: 100
Item Price: $10.99 Expected
Output:
Item "Widget A" is added to the inventory with the correct details. The
total number of items in the inventory is updated to 101.
2. Test Case: Updating Item Information
Input:
Select item "Widget A"
Update Item Name to "Super Widget"
Update Item Category to "Gadgets"
Update Item Price to $12.99 Expected
Output:
Item information is updated correctly.
Item "Widget A" is now "Super Widget" in the "Gadgets" category with a price of $12.99.
3. Test Case: Deleting an Item
Input:
Select item "Super Widget" Delete
item
Expected Output:
Item "Super Widget" is removed from the inventory.
The total number of items in the inventory is reduced by 1.
4. Test Case: Stock Replenishment
Input:
Select item "Super Widget"
Add 50 units to the existing stock
Expected Output:
The stock quantity for "Super Widget" is updated to 150.
The total number of items in the inventory is adjusted accordingly.
5. Test Case: Selling an Item
Input:
Select item "Super Widget" Sell
10 units
Expected Output:
The stock quantity for "Super Widget" is reduced to 140.
The system records the sale and updates revenue and sales history.
6. Test Case: Generating Reports
Input:
Generate a sales report for the last month
Expected Output:
The system generates a report with accurate sales data for the specified period.
7. Test Case: User Permissions
Input:
Log in as a regular employee and try to delete an item
Expected Output:
The regular employee should receive a permission error when attempting to delete an item.
8. Test Case: Searching for Items
Input:
Search for items containing the keyword "Widget" Expected
Output:
The system returns a list of items with names or descriptions containing "Widget."
9. Test Case: Handling Invalid Input
Input:
Attempt to add an item with a negative price
Expected Output:
The system should display an error message indicating that the price is invalid.
10. Test Case: Performance and Scalability
Input:
Add a large number of items to the inventory (e.g., 10,000 items).
Expected Output:
The system should handle this load without significant performance degradation.
EXPERIMENT - 7
Design Test cases and perform manual testing of login module of FlipKart (as an example).
Test Cases for Flipkart Login Module:
Valid Login Credentials:
Input: Valid username and password.
Expected Output: Successful login; user is directed to their account page.
Invalid Username:
Input: Invalid/Non-existent username and a valid password.
Expected Output: An error message indicating that the username is incorrect.
Invalid Password:
Input: Valid username and an incorrect password.
Expected Output: An error message indicating that the password is incorrect.
Blank Username:
Input: Leaving the username field blank and providing a valid password. Expected
Output: An error message indicating that the username is required.
Blank Password:
Input: Providing a valid username and leaving the password field blank. Expected
Output: An error message indicating that the password is required.
Password Case Sensitivity:
Input: Valid username and password with incorrect case (e.g., "Password" instead of "password"). Expected
Output: An error message indicating that the password is case-sensitive and incorrect.
Forgot Password Link:
Input: Clicking on the "Forgot Password" link.
Expected Output: The user is directed to a password recovery/reset page.
Remember Me Option:
Input: Checking the "Remember Me" checkbox during login.
Expected Output: The user's login session persists even after closing and reopening the browser.
Account Lockout After Multiple Failed Attempts:
Input: Providing incorrect login details multiple times (e.g., three times).
Expected Output: The account is locked, and the user is informed to reset their password or contact customer support.
Login with Social Media Account:
Input: Logging in using a social media account (e.g., Google or Facebook).
Expected Output: Successful login and association of the social media account with the Flipkart account.
