Adama Science And Technology University(ASTU

School of Electrical Engineering & Computing(SoEEC)

Department Software Engineering(SE)

Software Requirements Engineering Project

Title : - Web-Based Inventory Management System

Submitted to :- instructor By Mr Rabira Geleta(Msc)

Submision date: Mar/18/2024

Adama

1|P age
 SECTION 1
GROUP NAME AND ID
Name ID No
1. Sabona Alemu… .............UGR/27724/14

2. Abdissa Reta… ................ UGR/27671/14

3. Abel belete……………...UGR/27673 /14

4. Besuffikad Balcha… ......UGR/27679/14

5. Kirubel Fisseha… ............ UGR/27704/14

2|Page
 Acknowledgment

The team has made all efforts possible to complete the project in this way. During this,
different bodies have taken in making this project possible, and we would like to extend our
sincere appreciation for them.
We would like to express our gratitude toward ADAMA SCIENCE AND TECHNOLOGY
UNIVERSITY for giving us this opportunity by which we can expand our knowledge of the
subject.
We would also like to thank our instructor Mr.Rabira Geleta(Msc) for the guidance,
inspiration, kind comments and constructive suggestions that helpful us in the preparation of
this project. Although she was always loaded with several other activities, she gave us more
than enough time for this work. Her comments and guidance helped us in preparing our
project report.
We are also thankful to all of our teachers of the department who helped us in a number of
ways by providing various resources and moral support

3|Page
 Abstract:
The Web-Based Inventory Management System is a comprehensive software solution
designed to streamline the inventory management process for businesses. The system
leverages web technologies to provide a user-friendly interface accessible from any device
with an internet connection. It aims to automate and optimize various inventory-related tasks,
such as tracking stock levels, managing purchase orders, monitoring sales, and generating
reports.

The system offers a range of features to improve efficiency and accuracy in inventory
management. It allows users to create and maintain a centralized database of products,
including details such as , description, price, and supplier information. Real-time inventory
tracking capabilities enable users to monitor stock levels, receive alerts for low stock items,
and automate the reordering process based on predefined thresholds.

The Web-Based Inventory Management System also facilitates the management of purchase
orders. Users can create and track purchase orders, generate supplier invoices, and manage
supplier relationships. The system assists in optimizing the procurement process by providing
insights into supplier performance, pricing trends, and delivery timelines.

4|Page
 Contents
Acknowledgment.............................................................................................................................Page 3
Abstract ......................................................................................................................................... Page 4
CHAPTER 1. Requirement engineering focus (introduction) ................................................. Page 7
1.1 Introduction .......................................................................................................... Page 7
1.2 Objectives ............................................................................................................ Page 7
1.3 Scope .................................................................................................................... Page 7
1.4 Stakeholders ......................................................................................................... Page 8
1.5 Methodology ........................................................................................................ Page 8
CHAPTER 2. Requirement engineering process..................................................................... Page 10
2.1 Introduction ....................................................................................................... Page 10
2.2 Requirement Gathering ..................................................................................... Page 10
2.3 Requirement Analysis ....................................................................................... Page 10
2.4 Requirement Prioritization................................................................................. Page 10
2.5 Requirement Documentation ............................................................................. Page 11
2.6 Requirement Validation..................................................................................... Page 11
2.7 Requirement Management................................................................................. Page 11
CHAPTER 3. Requirement engineering elicitation................................................................. Page 12
3.1 Introduction ....................................................................................................... Page 12
3.2 Techniques for Requirement Elicitation ............................................................Page 12
3.2.1 Interviews .................................................................................................. Page 12
3.2.2 Surveys ...................................................................................................... Page 12
3.2.3 Workshops ................................................................................................ Page 12
3.2.4 Observation ............................................................................................... Page 13
3.2.5 Prototyping ................................................................................................ Page 13
3.2.6 Document Analysis……………………..........................................,,,......... Page 13
3.2.7 Focus groups: ............................................................................................ Page 13
3.2.8 Domain experts consultation ....................................................................Page 13
3.2.9 Benchmarking............................................................................................ Page 13
3.2.10 Feedback and iteration............................................................................ Page 13
3.3 Stakeholder Collaboration ................................................................................. Page 14
3.4 Requirement Prioritization................................................................................. Page 14
3.5 Requirement Documentation ............................................................................. Page 14
CHAPTER 4 Requirement analysis and negotiation .............................................................. Page 15
4.1 Introduction ....................................................................................................... Page 15
4.2 Requirement Analysis ....................................................................................... Page 15
4.4 Requirement Validation and Verification .......................................................... Page 16
4.5 Requirement Documentation and Specification ................................................ Page 16
4.6 Requirement Negotiation................................................................................... Page 16
4.7 Requirement Management and Change Control................................................ Page 17
4.8 Resolve conflicts and inconsistencies ............................................................... Page 17
CHAPTER 5.Software requirement (FR, NFR) ......................................................................Page 18
5.1 Introduction………………..…………………...…………………………….,.Page 18
5.2 Functional Requirements (FR) .......................................................................... Page 18
5.3 Non-Functional Requirements (NFR) ............................................................... Page 19
CHAPTER 6 Software documentation .....................................................................................Page 21
6.1 Introduction ....................................................................................................... Page 21
6.2 Document Structure .......................................................................................... Page 21
6.2.1 Introduction ................................................................................................. Page 21
6.2.2 System Architecture .................................................................................... Page 21
6.2.3 Functional Requirements ............................................................................ Page 22

5|Page
 6.2.4 Non-Functional Requirements ..................................................................... Page 22
6.2.5 Data Model .................................................................................................. Page 22
6.2.6 User Interface Design .................................................................................. Page 22
6.2.7 System Components .................................................................................... Page 22
6.2.8 Installation and Configuration………………………………………….,, Page 22
6.2.9 Testing and Quality Assurance ....................................................................Page 22
6.2.10 Maintenance and Support .......................................................................... Page 22
6.2.11 Software Requirements Specification (SRS): ............................................. Page 23
6.2.12 System Design Document: ........................................................................ Page 23
6.2.13 User Manual: ............................................................................................. Page 23
6.2.14 API Documentation ................................................................................... Page 23
6.2.15 Change Log ................................................................................................ Page 23
6.2.16 System Maintenance and Troubleshooting Guide .................................... Page 23
6.2.17 Data Dictionary.......................................................................................... Page 24
6.2.18 Project Documentation ............................................................................. Page 24
6.3 Documentation Tools ........................................................................................ Page 24
CHAPTER 7 Software validation ............................................................................................ Page 25
7.1 Introduction ....................................................................................................... Page 25
7.2 Testing Approach ............................................................................................... Page 25
7.2.1 Functional Testing ....................................................................................... Page 25
7.2.2 Integration Testing ...................................................................................... Page 25
7.2.3 Performance Testing ................................................................................... Page 25
7.2.4 Security Testing ........................................................................................... Page 25
7.2.5 Usability Testing .......................................................................................... Page 25
7.3 Verification and Validation ................................................................................. Page 26
7.3.1 Verification ....................................................................................................Page 26
7.3.2 Validation ..................................................................................................... Page 26
7.4 User Acceptance Testing (UAT) .......................................................................... Page 26
7.4.1 Test Planning ............................................................................................... Page 26
7.4.2 Test Execution ............................................................................................. Page 26
7.4.3 Issue Resolution .......................................................................................... Page 26
7.4.4 UAT Sign-off ................................................................................................ Page 26
CHAPTER 8 Requirement managemet .................................................................................. Page 27
8.1 Introduction)....................................................................................................... Page 27
8.2 Requirement Elicitation) .................................................................................... Page 27
8.2.1 Stakeholder Identification) ......................................................................... Page 27
8.2.2 Requirement Gathering) ............................................................................ Page 27
8.2.3 Requirement Analysis and Prioritization) ................................................... Page 27
8.3 Requirement Documentation) ........................................................................... Page 28
8.3.1 Requirement Specification) ........................................................................Page 28
8.3.2 Requirement Traceability) .......................................................................... Page 28
8.4 Requirement Change Management) ................................................................. Page 28
8.4.1 Change Identification) ..................................................................................Page 28
8.4.2 Change Evaluation and Prioritization) .......................................................... Page 28
8.4.3 Change Approval and Implementation) ....................................................... Page 28
8.5 Requirement Validation)..................................................................................... Page 28
8.5.1 Requirement Review) .................................................................................. Page 28
8.5.2 Requirement Verification)............................................................................ Page 28
8.5.3 Communication and Collaboration) ............................................................. Page 29
8.6 Requirement Management Tools)....................................................................... Page 29
Potential of Web based Inventory Management System Diagram ...................................... Page 29

6|Page
 Chapter 1
Requirement Engineering Focus (Introduction)
1.1 Introduction

 In today's fast-paced business environment, effective inventory management is crucial

for the success of any organization.
 The ability to accurately track and control inventory levels can greatly impact a
company's profitability, customer satisfaction, and overall operational efficiency.
 Traditional manual inventory management systems are prone to errors, time-
consuming, and lack real-time visibility, making them inefficient and unreliable..
 Requirement engineering for a web-based inventory management system involves
identifying, analyzing, documenting, and validating the needs and expectations of the
system's stakeholders. steps and considerations in the requirement engineering
process:

1.2 Objectives

 The primary objective of this project is to develop a web-based inventory

management system that enhances the efficiency and accuracy of inventory
management processes.
 The system should enable stakeholders to easily monitor inventory levels, track stock
movements, generate reports, and optimize inventory replenishment.
 By implementing a web-based solution, it will provide real-time access to inventory
data from anywhere, improving collaboration and decision-making.

1.3 Scope
The scope of this project encompasses the development of a web-based inventory
management system with the following key features:

 User authentication and access control: The system should allow different
user roles with varying levels of access and permissions.
 Inventory tracking: The system should provide the ability to track inventory
levels, including stock quantities, locations, and any related details.
 Stock movement management: The system should record and track the
movement of stock, including purchasing, receiving, transfers, and sales.
 Reporting and analytics: The system should generate various reports and
provide analytics to help stakeholders make informed decisions.
 Supplier management: The system should facilitate managing supplier
information, including contact details, pricing, and delivery schedules.

7|Page
  Integration capabilities: The system should have the ability to integrate with
existing systems such as ERPs, POS systems, and e-commerce platforms.

1.4 Stakeholders
The stakeholders of the web-based inventory management system project include:

 Management: They require accurate and timely inventory information to make

informed decisions regarding procurement, sales, and resource allocation.
 Warehouse managers: They need a user-friendly interface to track and manage
inventory levels, stock movements, and generate necessary reports.
 Purchasing department: They need a system that can assist in optimizing inventory
replenishment, generating purchase orders, and managing suppliers effectively.
 Sales team: They require real-time inventory visibility to provide accurate stock
availability information to customers and avoid overselling.
 IT department: They are responsible for the system's deployment, maintenance, and
integration with other existing systems.

1.5 Methodology
The requirements engineering process will follow a structured approach, involving the
following key steps:

 Gathering requirements: This involves conducting interviews, surveys, and

workshops with stakeholders to identify their needs and expectations.
 Engage with stakeholders to gather their requirements. This can be done through
interviews, surveys, workshops, or other collaborative techniques.
 The goal is to understand the desired functionalities, constraints, and performance
expectations for the system
 Analyzing requirements: The gathered requirements will be analyzed to identify
commonalities, conflicts, and dependencies.
 Prioritizing requirements: A prioritization process will take place to determine the
most critical and essential requirements for the system's success.
 Documenting requirements: The identified requirements will be documented in a
clear and concise manner, including functional and non-functional requirements.
1. Identify stakeholders:
 Determine the individuals or groups who have an interest in the inventory
management system.
 This may include warehouse managers, inventory controllers, purchasing
departments, sales teams, and other relevant personnel
2. Categorize requirements:
 Organize the collected requirements into different categories, such as functional
requirements (what the system should do),

8|Page
  non-functional requirements (system qualities like performance, usability, security),
and constraints (limitations and dependencies).
3. Define use cases:
 Create detailed descriptions of how the system will be used in various scenarios.
 Use cases help to identify interactions between users and the system, and they provide
a basis for designing the system's functionalities.
4. Document requirements:
 Clearly document all the identified requirements, including functional and non-
functional requirements, constraints, use cases, and any other relevant information.
 Use standard documentation techniques like use case diagrams, user stories, or a
requirements specification document.
5. Manage requirements changes:
 As the project progresses, it's common for requirements to evolve or change.
 Establish a process to manage and track changes to requirements, ensuring proper
communication and agreement between stakeholders.
6. Prototype and feedback:
 Develop a prototype or mock-up of the web-based inventory management system to
gather feedback from stakeholders.
 This can help validate the requirements further and refine the system's design.

9|Page
 Chapter 2
Requirement Engineering Process
2.1 Introduction

 The requirement engineering process plays a vital role in the successful development
of a web-based inventory management system.
 It involves gathering, analyzing, prioritizing, and documenting the requirements of the
system based on the needs and expectations of the stakeholders.
 This chapter focuses on the requirement engineering process, outlining the key steps
involved in each phase.

2.2 Requirement Gathering

 The first step in the requirement engineering process is to gather the requirements
from the stakeholders.
 This can be achieved through various techniques such as interviews, surveys, and
workshops.
 The project team will engage with the stakeholders to understand their needs, pain
points, and desired functionalities of the web-based inventory management system.
During this phase, it is important to identify both functional and non-functional
requirements.

2.3 Requirement Analysis

 Once the requirements have been gathered, the next step is to analyze and evaluate
them.
 This involves identifying any conflicts, contradictions, or dependencies among the
requirements.
 The project team will carefully examine each requirement and ensure that they are
clear, specific, and consistent.
 Additionally, the team will assess the feasibility of implementing each requirement
and consider any potential risks or constraints.

2.4 Requirement Prioritization

 In order to manage the project's limited resources effectively, it is essential to

prioritize the requirements.
 This step involves assigning a priority level to each requirement based on its
importance and impact on the system's functionality and success.
 The project team will work closely with the stakeholders to determine the critical and
high-priority requirements that need to be addressed in the initial development phases.

10 | P a g e
  This prioritization process helps in making informed decisions and allocating
resources accordingly.

2.5 Requirement Documentation

 Once the requirements have been analyzed and prioritized, they need to be
documented in a clear and concise manner.
 This documentation serves as a reference for the project team throughout the
development process.
 The requirements document should include detailed descriptions of each requirement,
along with any associated constraints, assumptions, and dependencies.
 Additionally, the document should be structured in a way that facilitates easy
understanding and communication of the requirements to all stakeholders.

2.6 Requirement Validation

 After documenting the requirements, it is crucial to validate them with the

stakeholders to ensure that they accurately capture their needs and expectations.
 This validation process involves reviewing the requirements document with the
stakeholders and seeking their feedback and approval. Any necessary revisions or
modifications can be made based on the feedback received.
 This step helps in avoiding misunderstandings and ensuring that the requirements
align with the stakeholders' vision for the system.

2.7 Requirement Management

 Requirement management is an ongoing process that involves tracking, controlling,

and prioritizing changes to the requirements throughout the development lifecycle.
 As the project progresses, new requirements may emerge, and existing requirements
may need to be modified or removed.
 The project team will establish a systematic process for managing these changes,
ensuring that they are properly evaluated, documented, and communicated to all
relevant stakeholders.

11 | P a g e
 Chapter 3
Requirement Engineering Elicitation
3.1 Introduction

 Requirement engineering elicitation is a crucial phase in the development of a web-

based inventory management system.
 It involves gathering and capturing the specific requirements of the system from the
stakeholders.
 This chapter focuses on the techniques and methods used to elicit requirements
effectively.

3.2 Techniques for Requirement Elicitation

 There are several techniques available for eliciting requirements.

 The choice of technique depends on the characteristics of the stakeholders, the
complexity of the system, and the project constraints.
 The following are some commonly used techniques:

3.2.1 Interviews:
 Conducting one-on-one or group interviews with stakeholders can provide valuable
insights into their needs and expectations.
 Open-ended questions can be used to gather detailed information about the inventory
management processes, challenges, and desired functionalities.

3.2.2 Surveys:
 Surveys can be used to collect information from a large number of stakeholders.
 Well-designed questionnaires can help gather quantitative and qualitative data about
their requirements, preferences, and priorities.

3.2.3 Workshops:
 Organizing workshops with stakeholders from different departments can facilitate
collaboration and generate a collective understanding of the requirements.
 Through group discussions and brainstorming sessions, diverse perspectives can be
captured, and consensus can be reached on critical requirements.

12 | P a g e
3.2.4 Observation:
 Directly observing the existing inventory management processes can provide valuable
insights into the current practices, pain points, and areas for improvement.
 This technique helps in understanding the system's context and identifying specific
requirements based on real-life scenarios.

3.2.5 Prototyping:
 Creating interactive prototypes or mock-ups of the system can be an effective way to
elicit requirements.
 Stakeholders can visualize and interact with the prototype, providing feedback and
suggestions for enhancements.
3.2.6 Document Analysis:
 Analyzing existing documents such as process manuals, inventory reports, and
business rules can help identify implicit requirements and understand the current
system's limitations.
3.2.7 Focus groups:
 Organize focus groups consisting of representatives from various stakeholder groups.
 Facilitate discussions around specific topics or system functionalities to gather diverse
perspectives and requirements.
 Encourage participants to provide feedback, suggestions, and engage in group
discussions.
3.2.8 Domain experts consultation:
 Consult with subject matter experts who have expertise in inventory management
systems or relevant domains.
 They can provide valuable insights, share best practices, and help identify
requirements that may have been overlooked
3.2.9 Benchmarking:
 Research and analyze existing web-based inventory management systems or similar
solutions in the market.
 Identify the features, functionalities, and user experiences that stakeholders find
valuable.
 Use this information to gather requirements and set performance expectations.
3.2.10 Feedback and iteration:
 Continuously seek feedback from stakeholders throughout the requirement elicitation
process.
 Present findings, initial requirements, and prototypes to stakeholders and incorporate
their inputs into the evolving understanding of the system's requirements.
 This iterative approach ensures that the requirements accurately reflect stakeholders'
needs.

13 | P a g e
3.3 Stakeholder Collaboration

 Successful requirement elicitation requires active collaboration and engagement with

the stakeholders.
 It is essential to involve representatives from different departments, including
management, warehouse managers, purchasing, sales, and IT, to ensure that all
perspectives are considered.
 Regular meetings, workshops, and feedback sessions should be organized to gather
requirements, validate findings, and refine the understanding of stakeholders' needs.

3.4 Requirement Prioritization

 During the elicitation process, it is important to prioritize the requirements based on

their importance and impact on the system's success.
 Stakeholders should be involved in this prioritization process to ensure that critical
requirements are addressed in the initial development phases.
 Prioritization can be done using techniques like MoSCoW (Must have, Should have,
Could have, and Won't have), Kano model, or pairwise comparison.

3.5 Requirement Documentation

 The elicited requirements need to be documented in a clear and organized manner to

ensure a common understanding among all stakeholders.
 The requirements document should include detailed descriptions of each requirement,
including functional requirements (e.g., inventory tracking, stock movement
management) and non-functional requirements (e.g., performance, security,
scalability). Additionally, any associated constraints, assumptions, and dependencies
should be documented.

14 | P a g e
 Chapter 4:
Requirement Analysis and Negotiation
4.1 Introduction

 Requirement analysis and negotiation are essential steps in the development of a web-
based inventory management system.
 This chapter focuses on analyzing the gathered requirements and resolving any
conflicts or inconsistencies through negotiation with the stakeholders.
 The goal is to arrive at a set of well-defined and agreed-upon requirements that can be
effectively implemented.

4.2 Requirement Analysis

 Requirement analysis involves a thorough examination and understanding of the

gathered requirements.
 The project team will analyze each requirement to ensure clarity, completeness, and
consistency.
 This analysis aims to identify any conflicts, redundancies, or gaps in the requirements.
Additionally, the team will assess the feasibility and impact of each requirement on
the system's design and implementation.
 Review the gathered requirements to understand their scope, clarity, and feasibility.
 Identify any conflicts or inconsistencies among the requirements.
 For example, if one requirement states that real-time inventory updates are essential,
while another requirement specifies that updates can be batched.
 Identify dependencies between requirements. Determine if any requirements are
dependent on the fulfillment of others.
 Identify missing requirements or gaps that need to be addressed.

4.3 Requirement Prioritization and Trade-offs

 During the requirement analysis phase, it is important to prioritize the requirements

based on their importance and impact on the system.
 This prioritization process helps in making informed decisions when resource
constraints arise.
 The project team will work closely with the stakeholders to understand their priorities
and trade-offs. This may involve negotiating with stakeholders to balance conflicting
requirements and identify compromises that best meet the overall objectives of the
system.
 Collaborate with stakeholders to prioritize requirements based on their importance
and impact on the system's success.

15 | P a g e
  Consider factors such as business value, urgency, feasibility, and dependencies
between requirements.
 Use techniques like MoSCoW (Must have, Should have, Could have, Won't have) or
Kano model to categorize requirements based on their priority and value.
 In situations where conflicting requirements cannot be fully resolved, explore trade-
offs and alternatives.
 Engage stakeholders in discussions to identify the most viable options and evaluate
their implications.
 Consider factors such as cost, time, technical feasibility, and the impact on user
experience.
 Document the agreed-upon trade-offs or alternatives and ensure stakeholder
alignment.

4.4 Requirement Validation and Verification

 Requirement validation ensures that the analyzed requirements accurately reflect the
stakeholders' needs and expectations.
 The project team will collaborate with the stakeholders to review and validate the
requirements.
 Any inconsistencies or gaps identified during this process will be addressed and
resolved through negotiation and clarification.
 Verification activities will also be performed to ensure that the requirements can be
tested and measured for compliance.

4.5 Requirement Documentation and Specification

 Once the requirements have been analyzed, validated, and verified, they need to be
documented and specified in a structured manner.
 The project team will prepare a detailed requirement document that includes clear and
concise descriptions of each requirement, along with any associated constraints,
assumptions, and dependencies.
 This documentation serves as a reference for the development team and ensures a
common understanding among all stakeholders.

4.6 Requirement Negotiation

 Requirement negotiation is a collaborative process between the project team and the
stakeholders. It involves resolving conflicts, addressing differing viewpoints, and
reaching a consensus on the requirements.
 Negotiation may involve trade-offs, compromises, or alternative solutions to meet the
stakeholders' needs while considering project constraints.
 Effective communication and stakeholder engagement are crucial during this phase to
ensure that the negotiated requirements align with the overall project objectives.

16 | P a g e
4.7 Requirement Management and Change Control

 Requirement management is an ongoing process throughout the development

lifecycle.
 As the project progresses, new requirements may emerge, and existing requirements
may need to be modified or removed.
 The project team will establish a change control process to manage these changes
effectively.
 This process includes assessing the impact of changes, documenting change requests,
and obtaining stakeholder approval before implementing any modifications to the
requirements.
 As the project progresses, new requirements may emerge, or existing requirements
may need modification.
 Engage in negotiation with stakeholders to evaluate the impact of changes on the
project timeline, budget, and resources.
 Assess the feasibility and potential risks associated with the proposed changes.
 Collaborate with stakeholders to reach a consensus on whether to accept, reject, or
modify the changes.
 Document the agreed-upon changes and update the requirements accordingly.

4.7 Resolve conflicts and inconsistencies:

 Engage stakeholders in discussions to address conflicts and inconsistencies in the

requirements.
 Identify the underlying reasons for the conflicts and seek ways to reconcile them. This
may involve compromising or finding alternative solutions that satisfy the needs of all
parties involved.
 Document the agreed resolutions and ensure that all stakeholders are aligned.

17 | P a g e
 Chapter 5:

Software Requirements(FR&NFR)
5.1 Introduction

 This chapter outlines the software requirements for the web-based inventory
management system.
 These requirements are categorized into functional requirements (FR) and non-
functional requirements (NFR). Functional requirements specify the system's desired
functionalities,
 while non-functional requirements define the system's quality attributes and
constraints.

5.2 Functional Requirements (FR)

 Functional requirements describe the specific functionalities and features that the
web-based inventory management system should provide.
 These requirements are derived from the needs and expectations of the stakeholders.
 The following are some examples of functional requirements for the system:

1. FR: User Authentication

 The system should provide secure user authentication to ensure authorized access.
 Users should be able to create accounts, log in, and manage their credentials.

2. FR: Inventory Management

 The system should allow users to add, edit, and delete inventory items.
 Users should be able to track the quantity, location, and availability of each item.
 The system should support barcode scanning for efficient item entry.

3. FR: Purchase Order Management

 Users should be able to create and manage purchase orders for inventory
replenishment.
 The system should track purchase orders, supplier information, and delivery status.
 Users should receive notifications for pending or delayed orders.

4. FR: Sales and Order Fulfillment

 The system should support the creation and management of sales orders.
 Users should be able to generate invoices and track order fulfillment status.
 The system should calculate the total cost, including taxes and discounts.

18 | P a g e
5. FR: Reporting and Analytics:

 The system should provide comprehensive reporting and analytics capabilities.

 Users should be able to generate inventory reports, sales reports, and financial
summaries.
 The system should support data visualization to facilitate data analysis.

6. FR: Stock Alerts:

 The system should generate alerts when inventory levels fall below a predefined
threshold, notifying users to reorder or restock items.

7. FR: Inventory Tracking:

 The system should allow users to add, update, and delete inventory items, including
their descriptions, quantities, and locations.

8. FR: Inventory Search:

 Users should be able to search for inventory items based on various criteria, such as
item name, category, or location.

9. FR: Supplier Management:

 Users should be able to manage supplier information, including contact details,

pricing agreements, and performance evaluations.

10. FR: Warehouse Management:

 The system should enable users to track and manage warehouse activities, such as
receiving, picking, packing, and shipping inventory items.

11. FR: Integration with External Systems:

 The system should integrate with external systems, such as accounting software or e-
commerce platforms, to ensure seamless data exchange and process synchronization.

12 FR: User Roles and Permissions:

 The system should support different user roles (e.g., admin, manager, staff) with
varying levels of access and permissions to maintain data security and control.

5.3 Non-Functional Requirements (NFR)

 Non-functional requirements define the quality attributes and constraints of the web-
based inventory management system.
 These requirements ensure that the system meets performance, security, usability, and
other non-functional aspects.
 The following are some examples of non-functional requirements for the system:

19 | P a g e
1. NFR: Performance:

 The system should respond to user interactions within 2 seconds.

 It should support concurrent user access without significant performance
degradation.
 The system should handle a large number of inventory items efficiently.

2. NFR: Security:

 The system should ensure secure data transmission using HTTPS encryption.
 User passwords should be stored securely using industry-standard hashing
algorithms.
 Access to sensitive functionalities and data should be restricted based on user roles.

3. NFR: Usability:

 The system should have an intuitive and user-friendly interface.

 Users should be able to navigate the system easily and perform tasks efficiently.
 The system should provide helpful error messages and contextual guidance.

4. NFR: Scalability:

 The system should be scalable to accommodate a growing number of users and

inventory items.
 It should support future enhancements and integrations with other systems.

5. NFR: Reliability:

 The system should be available and accessible 24/7, with minimal downtime for
maintenance.
 It should have a backup and recovery mechanism to prevent data loss.

6. NFR: Data Backup and Recovery:

 The system should regularly back up inventory data and provide mechanisms for data
recovery in case of unexpected failures or disasters.

7. NFR: Integration:

 The system should have well-defined APIs or integration capabilities to allow

seamless integration with other systems or third-party services.

8. NFR: Accessibility:

 The system should adhere to accessibility standards and guidelines to ensure that
users with disabilities can access and use the system effectively.

20 | P a g e
9. NFR: Performance Monitoring:

 The system should provide monitoring and logging capabilities to track performance
metrics and identify bottlenecks or issues for optimization.

10. NFR: Compliance:

 The system should comply with relevant industry regulations and standards, such as
data privacy regulations or inventory management best practices

Chapter 6:
Software Documentation
6.1 Introduction

 This chapter focuses on the documentation of the web-based inventory management

system.
 Proper documentation is crucial for understanding the system's design, functionality,
and implementation details.
 It provides a comprehensive reference for developers, stakeholders, and future
maintenance and support teams.

6.2 Document Structure

 The software documentation should be organized and structured in a logical manner

to facilitate easy navigation and understanding.
 The following sections are typically included in the software documentation:

6.2.1 Introduction

 Provides an overview of the system, its purpose, and the intended audience of the
documentation.
 Describes the scope and objectives of the web-based inventory management
system.

6.2.2 System Architecture

 Presents the high-level architecture of the system, including the different

components and their interactions.
 Describes the deployment architecture, such as the server infrastructure and
network configuration.

21 | P a g e
6.2.3 Functional Requirements

 Provides a detailed description of each functional requirement identified for the

system.
 Includes use cases, user stories, or activity diagrams to illustrate the system's
behavior and interactions.

6.2.4 Non-Functional Requirements

 Documents the non-functional requirements and their corresponding quality

attributes.
 Includes performance benchmarks, security measures, usability guidelines, and
other relevant details.

6.2.5 Data Model

 Presents the data model or database schema for the inventory management system.
 Includes entity-relationship diagrams, table structures, and data flow diagrams.

6.2.6 User Interface Design

 Includes screenshots or wireframes of the user interface, illustrating the system's

look and feel.
 Describes the user interface components, navigation flow, and usability
considerations.

6.2.7 System Components

 Provides detailed documentation for each system component, such as modules,

libraries, or APIs.
 Includes class diagrams, sequence diagrams, and interface specifications.

6.2.8 Installation and Configuration

 Guides users and system administrators through the installation and configuration
process.
 Includes system requirements, installation steps, and any dependencies or
prerequisites.

6.2.9 Testing and Quality Assurance

 Describes the testing approach, test cases, and test results for the system.
 Includes performance test reports, security audit findings, and any relevant quality
assurance documentation.

22 | P a g e
6.2.10 Maintenance and Support

 Provides guidelines and best practices for system maintenance and support.
 Includes troubleshooting guides, known issues, and contact information for
technical support.

6.2.11 Software Requirements Specification (SRS):

 The SRS document outlines the functional and non-functional requirements of the
system. It describes the system's features, user interactions, constraints, and
performance expectations.
 It serves as a reference for the development team and provides a clear understanding
of what needs to be implemented.

6.2.12 System Design Document:

 This document describes the high-level architecture and design of the web-based
inventory management system.
 It includes system components, modules, data structures, and interfaces. It also
highlights the design patterns, technologies, and frameworks used in the system's
development.

6.2.13 User Manual:

 The user manual provides instructions and guidance for end-users on how to
effectively use the inventory management system.
 It explains the system's features, user interfaces, workflows, and common tasks.
 It may include screenshots, step-by-step instructions, and troubleshooting tips to assist
users in utilizing the system.
6.2.14 API Documentation:
 If the web-based inventory management system exposes an API for integration with
other systems,
 it is important to document the API endpoints, request/response formats,
authentication mechanisms, and usage guidelines.
 This documentation helps developers understand how to interact with the system
programmatically.

6.2.15 Change Log:

 The change log documents the history of changes made to the system, including bug
fixes, enhancements, and new features.
 It provides a chronological record of modifications, making it easier to track system
updates and understand the evolution of the software.

23 | P a g e
6.2.16 System Maintenance and Troubleshooting Guide:
 This document assists system administrators or support personnel in maintaining and
troubleshooting the web-based inventory management system.
 It includes guidelines for routine maintenance tasks, performance optimization, error
handling, and problem resolution.
6.2.17 Data Dictionary:
 The data dictionary provides a detailed description of the data structures, fields, and
relationships used in the system.
 It helps ensure a common understanding of the data model and improves
communication between developers and stakeholders.
6.2.18 Project Documentation:
 Additionally, it is beneficial to maintain project-related documentation, such as
project plans, timelines, meeting minutes, and communication logs.
 These documents provide a historical record of project activities, decisions, and
discussions.

6.3 Documentation Tools

Various tools and formats can be used to create and present the software documentation
effectively. Some commonly used tools include:

 Document editors (e.g., Microsoft Word, Google Docs) for creating textual
documentation.
 Diagramming tools (e.g., Lucidchart, Draw.io) for creating visual representations of
system components and interactions.
 Version control systems (e.g., Git) for managing document revisions and
collaboration.
 Online documentation platforms (e.g., Confluence, Read the Docs) for hosting and
sharing the documentation.

24 | P a g e
 Chapter 7:

Software Validation:
7.1 Introduction:

 Software validation is a critical phase in the development of the web-based inventory

management system.
 It involves evaluating the system to ensure that it meets the specified requirements
and performs as intended.
 This chapter focuses on the validation process, including testing, verification, and user
acceptance.

7.2 Testing Approach:

 Testing is an essential part of software validation. It involves executing the system

under controlled conditions and comparing the actual results with the expected results.
 The testing approach for the web-based inventory management system should
encompass various types of testing, including:
7.2.1 Functional Testing
 Verifies that each functional requirement is implemented correctly and
performs as intended.
 Involves testing individual functionalities, use cases, and user interactions.
7.2.2 Integration Testing
 Tests the interactions and interfaces between different system components.
 Ensures that the components work together seamlessly and exchange data correctly.
7.2.3 Performance Testing
 Evaluates the system's performance under expected and peak load conditions.
 Measures response times, throughput, and resource usage to ensure scalability and
efficiency.
7.2.4 Security Testing
 Checks the system's resistance to unauthorized access, data breaches, and other
security threats.
 Includes vulnerability scanning, penetration testing, and authentication and
authorization testing.
7.2.5 Usability Testing
 Assesses the system's ease of use, user-friendliness, and overall user experience.
 Involves conducting user tests and collecting feedback to identify usability issues.

25 | P a g e
7.3 Verification and Validation

In addition to testing, the validation process includes verification and validation activities to
ensure the system meets the requirements.

7.3.1 Verification
 Verifies that the system is built according to the requirements and design
specifications.
 Involves reviewing documents, code inspections, and walkthroughs to identify any
deviations.
7.3.2 Validation
 Validates the system's behavior and performance against the stakeholders'
expectations.
 Includes user acceptance testing, where users test the system in a real-world
environment.

7.4 User Acceptance Testing (UAT):

 User acceptance testing is a crucial part of software validation.

 It involves testing the system in a real-world environment with representative end-
users.
 The goal is to ensure that the system meets the users' needs and is suitable for their
intended purposes.
 UAT typically includes the following steps:
7.4.1 Test Planning
 Defines the scope, objectives, and test criteria for the user acceptance testing.
 Determines the test scenarios and test cases that will be executed by the end-users.
7.4.2 Test Execution
 End-users execute the predefined test scenarios and test cases.
 They provide feedback, report any issues or defects, and document their overall
experience.
7.4.3 Issue Resolution
 The development team addresses the reported issues and fixes any defects identified
during UAT.
 The system is retested by the end-users to ensure that the fixes have been successful.
7.4.4 UAT Sign-off
 Once the end-users are satisfied with the system's performance, they provide an
official sign-off.
 This sign-off indicates that the system is ready for deployment and use in the
production environment.

26 | P a g e
 Chapter 8:
Requirement Management
8.1 Introduction:

 Requirement management is a crucial aspect of the web-based inventory management

system project.
 It involves the process of capturing, documenting, analyzing, and managing the
requirements throughout the project lifecycle.
 This chapter discusses the importance of requirement management and outlines the
key activities involved.

8.2 Requirement Elicitation:

 Requirement elicitation is the process of gathering and documenting the needs and
expectations of the stakeholders.
 It involves various techniques, such as interviews, surveys, workshops, and
observations, to identify and understand the requirements.
 The key activities in requirement elicitation include:

8.2.1 Stakeholder Identification

 Identifying and involving all relevant stakeholders who have an interest or

influence in the system.
 Understanding their roles, responsibilities, and expectations.

8.2.2 Requirement Gathering

 Conducting interviews, surveys, and workshops to collect information about the

stakeholders' needs.
 Analyzing existing documentation, such as business process documents, to identify
requirements.

8.2.3 Requirement Analysis and Prioritization

 Analyzing the gathered requirements to understand their scope and impact on the
system.
 Prioritizing the requirements based on their importance, feasibility, and business
value.

27 | P a g e
8.3 Requirement Documentation:

 Once the requirements are elicited and analyzed, they need to be properly documented
to ensure a clear understanding among all stakeholders.
 The requirement documentation includes:
8.3.1 Requirement Specification
 Documenting the requirements in a structured and organized manner.
 Using techniques such as use cases, user stories, or functional specifications to
describe the requirements.
8.3.2 Requirement Traceability
 Establishing traceability links between requirements and other artifacts, such as
design documents and test cases.
 Ensuring that each requirement is traceable throughout the project lifecycle.

8.4 Requirement Change Management:

 Requirements are subject to change throughout the project lifecycle.

 Effective requirement change management ensures that changes are properly
assessed, approved, and implemented.
 The key activities in requirement change management include:
8.4.1 Change Identification
 Identifying and documenting proposed changes to the project requirements.
 Analyzing the impact of the changes on the system and project schedule.
8.4.2 Change Evaluation and Prioritization
 Assessing the feasibility, cost, and risks associated with proposed changes.
 Prioritizing the changes based on their impact and business value.
8.4.3 Change Approval and Implementation
 Obtaining approval from the stakeholders for the proposed changes.
 Implementing the approved changes in a controlled manner, ensuring proper
documentation and communication

8.5 Requirement Validation:

 Requirement validation ensures that the documented requirements accurately

represent the stakeholders' needs and expectations.
 The key activities in requirement validation include:
8.5.1 Requirement Review
 Conducting reviews of the requirement specifications with stakeholders and subject
matter experts.
 Identifying any inconsistencies, ambiguities, or gaps in the requirements.
8.5.2 Requirement Verification
 Verifying that the implemented system meets the specified requirements.
 Conducting testing and inspections to ensure that the system functions as intended.

28 | P a g e
8.5.3 Communication and Collaboration:

 Maintain open communication channels with stakeholders throughout the requirement

management process. Seek their input, provide updates, and address any concerns or
questions.
 Collaboration tools, such as project management software or document sharing
platforms, can facilitate effective communication and collaboration.

8.6 Requirement Management Tools:

Various tools can assist in managing requirements effectively. These tools provide features
for requirement capture, documentation, traceability, and change management. Some
commonly used requirement management tools include:

 Microsoft Excel or Google Sheets for simple requirement tracking and

documentation.
 Requirements management tools like JIRA, IBM Rational DOORS, or Jama Connect
for more complex requirements management needs.
 Version control systems like Git for managing changes to requirement documents.

Potential of Web based Inventory Management Systems:

THE END
THANKS!!!!
29 | P a g e