SRS CPP LAB.docx

1
SOFTWARE REQUIREMENT
SPECIFICATION
(SRS)
STOCK MAINTENANCE SYSTEM
(SMS)
November 17, 2022

2
TEAM MEMBERS
 AJITH P. KUMAR (12206015)
 AASHISH KUMAR (12205882)

3
CONTENTS
1. INTRODUCTION
1.1 Purpose .................................................................... 4
1.2 Scope ....................................................................... 4
1.3 Overviews................................................................ 4
2. GENERAL DESCRIPTION............................................5
2.1 Product Perspective.................................................... 5
2.2 Product Funtions........................................................ 5
2.3 User Characteristics ................................................... 5
2.4 Operating Environment.............................................. 5
2.5 Assumptions and Dependencies................................. 6
3. SOFTWARE REQUIREMENTS ....................................6
3.1 Requirements ........................................................... 7
3.2 Feasibility Study ...................................................... 7
3.3 Functional Requirements ......................................... 7
3.3.1 Functional Requirements for user ........................... 7
3.4 Non Functional Requirements.................................. 8
3.4.1 Performance Requirements..................................... 8
3.4.2 Security Requirements............................................ 8
3.4.3 Business Rules........................................................ 9
3.5 Other Requirements ................................................ 9
4. USE CASE DIAGRAM ................................................... 12

4
5. DESIGN OF STOCK MAINTENANCE SYSTEM ............... 15
5.1 Design Documentation........................................... 16
6. DATA FLOW DIAGRAM................................................ 16
6. CLASS DIAGRAM....................................................... 17
8. IMPLEMENTATION............................................... 17

5
1.INTRODUCTION
Now a days people should purchase things in stores. So, the stores must be maintaining the product details
and the stocks. So, in this stock maintenance have the details about the Product, Purchase, Sales, and Stock.
The product details contain Product code, Product name, Opening Stock, Prices. These details are
maintained in the database. Purchase details contain the stock, quantity, and price. The sales Details contain
Date, Customer name, Product code, Quantity and Prices. The Stock Details contain product id, opening
stock, purchase stock, sales stock, and current stock. It aims at standardizing data, consolidating data
ensuring data integrity and reducing inconsistencies. The document will describe the product functions,
requirements, and constraints of the Stock Maintain System.
1.1 Purpose
The purpose of the document is to define the requirements of the stock maintenance system. This
supplementary specification lists the requirements that are not readily captured in the use cases of the use
case model. The supplementary specification & the use case model together capture a complete set of
requirements on the system.
1.2 Scope
This supplementary specification applies to the stock maintenance system. This specification defines the
non-functional requirements of the system, such as reliability, usability, performance, and supportability as
well as functional requirements that are common across a number of use cases.
1.3 Overview
This Software Requirements Specification (SRS) is requirements work product that supports the Stock
Maintenance System "SMS". formally specified. It contains the results of both business analysis and system
analysis. Various techniques were used to gather requirements to identify, analyze and refine customer
needs. The purpose of this document is therefore to formally describe the general requirements of the

6
system, including functional and non-functional requirements and constraints. The detailed structure of this
document is as follows: This includes general product descriptions, user characteristics, general limitations,
and prerequisites for this system. Now let's talk about user and system requirements. After that, we review
the system design documentation and implementation decisions, as well as some test cases. Finally, the
report summarizes the progress made so far and describes any problems encountered during the work.
2.General Description
2.1 Product Perspective
The online stock maintenance system involves actors – the stock administrators, Manager, Customer, and
the supplier. The stock administrator controls the communication and services. The database system
manages application and financial information. Manager communicates with system to get report on stock
details. Product details, supplier details, customer details, sales details, and purchase order details.
2.2 Product Functions
a. Authentication through authors personal computer.
b. Customer is provided with product list, from which he can select and buy products.
c. Provide manager supplier details, product details, stock details, sales details, Purchase order details.
d. Provide supplier to receive purchase orders and send invoices.
e. Provide Stock Admin to the manager and update stock, product details, supplier details etc.
2.3 User Characteristics
1. Employee:
An employee needs to register and login, after logging the employee can add, change and/or
delete the information from the system.
2. Customer:
The customer can just view the products available in the system.
3. Manager:
The manager can order, re-order, change or delete purchase orders based on the arrival and
availability of stocks.
4. Administrator:
The administrator maintains all the databases and reports. He is responsible for changing the
information of the database and takes care of the payment and administrative reports.

7
2.4 Operating Environment
The Online Stock Maintenance system is an internet-oriented application, it is set to operate on a high
available network. Mostly a device that can access the internet and can support a huge web application is
used for sales and purchase of products. Any OS can support this system as it is not particularly software or
hardware dependent.
2.4 Assumptions and Dependencies
 All users have a computer, or any web enable device.
 Users should have internet access.
 The user must create or have an id and password for his/her first appearance.
 Admin should hold the authority to permit any activities regarding stocks.
3. Software Requirement Specification
This Software Requirements Specification (SRS) is requirements work product for the Stock Maintenance
System "SMS" formally specified. It contains the results of both business analysis and system analysis.
Various techniques were used to gather requirements to identify, analyze and refine customer needs. The
purpose of this document is therefore to formally describe the general requirements of the system, including
functional and non-functional requirements and constraints.
3.1 Requirements
• The system must store information about new entries.
• The system should display product details under different categories and the details about each
product.
• The system should keep quality records.
• The system should update and delete product records as needed.
3.2 Feasibility Study
A feasibility study is an in-depth analysis that considers all important aspects of a proposed project to
determine its likelihood of success. Business success can be defined primarily by return on investment.
That means the project will generate enough returns to justify the investment.

8
3.3Functional Requirements:
An online stock maintenance system has different functional requirements, from online registration to
specific product ordering. Here are some basic functional requirements:
3.3.1 Functional Requirement for User:
• The user interface should be attractive.
• The system shall save the product details, supplier details, sales details, purchase details and stock
details in a remote database.
• The system must store information about new entries.
• The system should allow internal staff to store information about items in stock and items that are
finished.
• The stock maintenance system that is developed is more accurate and is efficient.
• The system should keep quality records.
• The system will allow the admin to manage and update product details, stock details, customer details
and supplier details.
3.4 Non- Functional Requirements
3.4.1 Performance Requirements
 The system requires a fair amount of speed, especially while browsing through the products, selling
and purchasing products. The database shall be able to accommodate a minimum of 100000 records
of stocks, customers, and supplier.
 The software will support multiple users.
3.4.2 Security Requirements
The main security concern is for payment details during sales and purchase process, hence proper login
mechanism should be used to avoid hacking. The online Stock Maintenance system shall not disclose
personal information of passengers to unauthorized users or the public.
3.4.3 Business Rules
 The online ticket reservation system shall include four types of accounts: the stock administrator,
manager, supplier, and the customers.

9
 To log in to the system username and password is required.
 Managers will take the decision when to purchase stock by observing the demand of the product.
3.5Other Requirements
After the system has been fully constructed, the users will need a few sessions to become familiar with its
capabilities and some time to become used to it.
4.User Scenarios/ Use Cases
Login
It is a transaction performed by the user when he wishes to the stock maintenance system.
Maintain Stocks:
It is a transaction performed by the employee when he wishes to add change and/or delete product
information from the system.
Purchase Orders
It is a transaction performed by the manager when he wishes to create, change or delete purchase orders.
View Stocks
It is a transaction performed by the manager when he wishes to view the products available in the stock
maintenance system.

10
 Design of Stock Maintenance System
o Design Documentation
1. Login
1.1 Brief description:
This use case describes how a user logs into the stock maintenance system.
1.2Flow of events:
1.2.1Basic flow:
This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enter the name and password.
2. The user enters their name and password.
3. The system validates the entire name and password and logs the user into the system.
1.2.2 Alternative flow:
1. If in the basic flow, the user enters an invalid name and password the system displays an error message.
Maintain Stock
Employee
Manager
login
Database
Purchase order
Administrator
View stock
Customer

11
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which point the use case
ends.
2. Maintain Products
The use case describes how employees maintain products in the system.
2.2Flow of events:
2.2.1 Basic flow:
1 The system requests that the employee specify the function he/she would like to perform (add,
update, or delete). Once the employee provides the requested information, one of the sub-flows
is executed.
2 If the employee selected ‘add product’ then add product sub-flow is executed.
3 If the employee selected ‘update’ then update product sub flow is executed.
4 If the employee selected ‘delete product’ then delete product sub flow is executed.
2.2.1.1 Add Products
1. The system requires the employee to enter the product information. This includes
product name, cost.
2. Once the information is provided the system generates and assigns a unique product-id
number.
2.2.1.2 Update Products
1. The system requires entering id.
2. The employee enters the id, the system retrieves and displays product information.
3. The employee makes desired changes to the product information.
4. Once the employee updates information the system updates the product information.
2.2.1.3 Delete Products
3. The system specifies to enter id of the product.
4. The employee enters the id, the system retrieves and displays product information.
5. The system provides employees to confirm deletion of the products.
6. The employee verifies deletion.
7. The system deletes the products specified
3. Purchase Orders

12
This use case describes how the manager provides orders for new stock in the
stock maintenance system.
3.2Flow of events:
3.2.1 Basic flow:
This use case starts when the manager wishes to record and maintain purchase orders.
This includes adding, changing, and deleting purchase orders.
1. The system requests that the manager specify the function he/she would like to perform (add, change, or
delete).
2. Once the manager provides the required information, one of the sub flows is executed.
3. If the manager selected creates purchase order, it is executed.
4. If the manager selected change purchase order, the sub flow is executed.
5. If the manager selected delete purchase order, then that sub flow is executed.
3.2.1.1 Create Purchase Orders
1. The system requests the manager to enter the purchase order information; this includes
the name of the product
2. Once the information is provided, the system generates and assigns an order number.
3.2.1.2 Change Purchase Orders
1. The system requires you to enter the order number.
2. The manager enters the id number; the system retrieves and displays the information.
3. The manager makes the desired changes to the orders.
4. The system updates the information.
3.2.1.3 Delete Purchase Orders
1. The system requests the manager to enter the id number.
2. The manager enters the number; the system retrieves and displays information.
3. The system allows manager to confirm deletion of orders.
4. The manager verifies deletion.
5. The system deletes the orders specified.
4. View stock
4.1Brief description:
This use case describes how the customer views the stock maintenance system.
4.2 Flow of events:
4.2.1 Basic flow:
This use case starts when the customer wishes to view the product is available in the system.
o The system requests to customer to enter the details (name and price) of the product
required.
o Once the information is provided the system displays the product information.

13
6. Data Flow diagram
7. ER diagram

14
8. Class Diagram
1. Login:
Main form
Login()
Error messages
Incorrect()
Login controller
Verification()
Welcome screen
Correct()
Enter()
Login form
Username()
Password()
Re-login()

15
2.Maintain Products:
Add products
Product information
Product name()
Price()
Update product
Enter id()
Change()
Update()
Delete product
Retrieve details
Confirm()
Verify()
Delete specified()

16
3. Purchase Order:
4. View Stock:
Create purchase orders
 Assign order
 Confirm()
 Verify()
 Delete
specified()
Change purchase order
 Identify ID()
 Desired
changes()
 Updates()
Delete purchase orders
 Request()
 Confirm()
 Deletion()
 Display()
View Stock
Verification()
Product details
Products required()
Product specification()
displays()
Products available

17
Component Diagram
8.IMPLEMENTATION
#include<iostream>
#include<conio.h>
#include<iomanip>
#include<cstring>
#include<stdio.h>
#include<fstream>
using namespace std;
void menu();
int a;
// MANAGER CLASS;
Login
maintain products
view stock
purchase order

18
class item{
private:
int itemid;
char itemname[20];
float price;
public:
item(){
itemid=0;
strcpy(itemname,"no name");
price=0;
}
void getitemdata(){
cout<<"nEnter the idt:t";
cin>>itemid;
cin.ignore();
cout<<"nEnter the item namet:t";
cin.getline(itemname,19);
cout<<"nEnter the pricet:t";
cin>>price;

19
}
void showitemdata(){
cout<<setw(15)<<itemid<<setw(40)<<itemname<<setw(40
)<<price<<endl<<endl;
}
void show(){
cout<<"nIdtt:t"<<itemid;
cout<<"nItem namet:t"<<itemname;
cout<<"nEnter the pricet:t"<<price;
}
int storeitem(){
char ch;
getitemdata();
if(itemid==0 && price==0){
cout<<"Invalid item values";
}
else{
ofstream fout;
fout.open("D://file.dat", ios::app | ios::binary);

20
fout.write((char*)this,sizeof(*this));
fout.close();
cout<<"nGo to the main menut(Y/N):t";
cin>>ch;
if(ch=='Y'||ch=='y'){
system("cls");
menu();
}
else{
exit(0);
}
}
return 0;
}
int readitem(){
system("cls");
char ch;
ifstream obj;
obj.open("D://file.dat",ios::in | ios::binary);
if(!obj){
cout<<"file.found";
}

21
else{
obj.read((char*)this,sizeof(*this));
cout<<endl<<setw(20)<<"Idtt:t"<<setw(20)<<"Item
namet:t"<<setw(20)<<"Pricen";
while(!obj.eof()){
showitemdata();
obj.read((char*)this,sizeof(*this));
}
obj.close();
}
cout<<"nGo to the previous menu?t(Y/N):t";
cin>>ch;
if(ch=='Y'||ch=='y'){
system("cls");
menu();
}
else{
exit(0);
}
return 0;
}

22
void searchitem(){
int num;
char ch;
cout<<"nEnter the id of the itemt:t";
cin>>num;
ifstream fin;
fin.open("D://file.dat",ios::in | ios::binary);
if(!fin){
cout<<"n File not found";
}
else{
cout<<"found";
fin.read((char*)this, sizeof(*this));
while(!fin.eof()){
if(num==itemid){
showitemdata();
break;
}else{
cout<<"No such entry";
fin.read((char*)this,sizeof(*this));
}
}

23
}
fin.close();
cin>>ch;
if(ch=='Y'||ch=='y'){
system("cls");
menu();
}
else{
exit(0);
}
}
void deleteitem(){
int num;
char ch;
cout<<"Enter the item id to be deletedt:t";
cin>>num;
ifstream fin;
ofstream fout;
fin.open("D://file.dat",ios::in | ios::binary);
if(!fin){

24
cout<<"nNo such file or directoryn";
}
else{
fout.open("D://temp.dat",ios::out | ios::binary);
while(!fin.eof()){
if(itemid != num){
fout.write((char*)this,sizeof(*this));
}
}
fout.close();
fin.close();
}
remove("D://file.dat");
rename("D://temp.dat","D://file.dat");
cout<<"n The item has been deleted";
cin>>ch;
if(ch=='Y'||ch=='y'){
system("cls");
menu();

25
}
else{
exit(0);
}
}
};
item i;
class manager : public item{
int id;
string pswd;
item i;
public:
void details(){
cout<<"Enter the idt:t";
cin>>id;
cout<<"nEnter the passwordt:t";
cin>>pswd;
if(id==121 && pswd=="random"){
managermenu();
}

26
else{
cout<<"Enter the correct id and password";
menu();
}
}
void managermenu(); // defined in line 64
};
manager obj1;
void manager::managermenu(){
{
system("cls");
int ads;
cout<<"nWelcome Manager";
cout<<"n1.ViewList n2.Add itemn3Search
itemn4.Delete itemn5.Previous menun";
cin>>ads;
switch(ads){
case 1: i.readitem(); break;
case 2: i.storeitem();break;

27
case 3: i.searchitem();break;
case 4: i.deleteitem();break;
case 5: menu();break;
}
}
}
//EMPLOYEE CLASS
class emp : public item{
int id2;
string pswd2;
item i;
public:
void getdetails(){
start:
system("cls");
cout<<"Enter the idt:t";
cin>>id2;
cout<<"nEnter the passwordt:t";
cin>>pswd2;
if(id2==111 && pswd2=="qwer"){
empmenu();

28
}else{
cout<<"Enter the correct id and password";
goto start;
}
}
void empmenu();
void emplistitem(){
string line;
fstream obj;
obj.open("D://empfile.txt",ios::in | ios::app);
if(!obj){
cout<<"nERROR";
}
while(!obj.eof()){
getline(obj,line);
cout<<endl<<line<<endl;
}
obj.close();
}
void empdata(){

29
string itemname;
int noi;
cout<<"nEnter the employee idt:t";
cin>>noi;
cout<<"nEnter the employee namet:t";
cin>>itemname;
fstream obj("D://empfile.txt",ios::out | ios::app);
obj<<endl<<itemname + " ";
obj<<noi;
obj.close();
}
void emplistshow(){
string line;
ifstream obj;
obj.open("D://empfile.txt",ios::in);
obj.seekg(0);
getline(obj,line);
while(!obj.eof()){
cout<<endl<<line;
getline(obj,line);
}

30
}
};
emp obj2;
void emp::empmenu(){
system("cls");
int empadd;
cout<<"nWelcome Employee";
cout<<"n1.ViewList n2.Book Itemn3.Previous
menun";
cin>>empadd;
switch(empadd){
case 1: i.readitem(); break;
case 2: i.storeitem();break;
case 3: menu();break;
}
}
void menu(){
system("cls");
cout<<"Login as?n 1.Managern2.Employeen3.Exitn";
cout<<"Enter you choice heret:t";cin>>a;
switch(a){

31
case 1:obj1.details(); break;
case 2:obj2.getdetails();break;
case 3: exit(0);break;
}
}
int main(){
menu();
return 0;
}
Output:

SRS CPP LAB.docx

More Related Content

Similar to SRS CPP LAB.docx (20)

Recently uploaded (20)

SRS CPP LAB.docx