Assosa University

College of Computing and Informatics

Department of Computer Science

Inventory Management System

A Software Project Documentation Submitted to the

Department of Computer Science of Assosa University in Partial Fulfillment of
Requirements for the Course of Software Engineering

Prepared by:
Dawit Weldesenbet
Eyasu
Feven aman
Natnael sisay
Osman mohammed
Samuel ebisa
Yohanis

Advisors’ Name:
Main Advisor ……………
Co-Advisor ……………

<Submission Date>

ii
 Software Design Description
for

Inventory Management
System

Version 1.0 approved

Prepared by Dawit Weldesenbet, Eyasu, Feven aman, Natnael sisay, Osman mohammed,
Samuel ebisa, Yohanis

Assosa University

<date created>

i
 Acknowledgement
<Acknowledge organizations or people who cooperate and help you in providing information
during the preparation of this SDD document.>
 Contents
ACKNOWLEDGEMENT................................................................................................ II
1 INTRODUCTION....................................................................................................1
1.1 PURPOSE.....................................................................................................1
1.2 DESIGN GOALS............................................................................................1
1.3 SCOPE.........................................................................................................1
1.4 OVERVIEW...................................................................................................1
1.5 REFERENCES...............................................................................................1
1.6 DEFINITIONS, ACRONYMS AND ABBREVIATIONS..............................................1
2 SYSTEM OVERVIEW............................................................................................2

3 SYSTEM ARCHITECTURE...................................................................................3
3.1 PROPOSED SYSTEM ARCHITECTURE.............................................................3
3.2 DESIGN RATIONALE......................................................................................3
4 DATA DESIGN.......................................................................................................4
4.1 ENTITY RELATIONSHIP DIAGRAM...................................................................4
4.2 DATA DICTIONARY........................................................................................4
4.3 PERSISTENCE MODELING..............................................................................4
5 COMPONENT DESIGN.........................................................................................5
5.1 LOGICAL MODELING......................................................................................5
5.2 INTERACTION MODELING...............................................................................5
5.2.1 Activity Diagram........................................................................................5
5.2.2 Sequence Diagram.....................................................................................5
5.2.3 Collaboration Diagram.............................................................................5
5.3 STATE DYNAMIC MODELING..........................................................................5
5.4 DEPENDENCY MODELING..............................................................................5
5.4.1 Subsystem Decomposition.........................................................................5
5.4.2 Component Diagram.................................................................................5
5.4.3 Deployment Diagram.................................................................................5
6 HUMAN INTERFACE DESIGN..............................................................................6
6.1 OVERVIEW OF USER INTERFACE...................................................................6
6.2 SCREEN IMAGES...........................................................................................6
6.3 Screen Objects and Actions.......................................................................6

Revisions
Version Primary Author(s) Description of Version Date Completed
IMS Version Natnael Sisay Inventory management System for Assosa university 00/00/00
1.0

ii
 Software Design Description for inventory management system

1 Introduction
1.1 Purpose
The Software Design Document (SDD) for the inventory management system at a university is a
comprehensive document that outlines the architecture and system design of the software. The
purpose of this document is to provide a detailed description of how the inventory management
system will function, including its features, components, and interactions. It serves as a roadmap for
developers, designers, and stakeholders to understand the technical aspects of the software and guide
the implementation process.

The intended audience for this SDD includes software developers, system architects, project
managers, and university administrators who are involved in the development and implementation of
the inventory management system. This document will help them gain insights into the design
decisions, technical requirements, and functionality of the software, ensuring that all stakeholders are
aligned on the project's goals and objectives. Additionally, the SDD will serve as a reference guide
for future maintenance and updates to the inventory management system.

1.2 Design Goals

Performance criteria such as response time, throughput, and memory management are crucial for
ensuring efficient and effective system operation. Dependability criteria, including robustness,
reliability, availability, fault tolerance, and security, are essential to guarantee the system's stability
and protection of sensitive data. End user criteria such as usability and utility focus on providing a
user-friendly interface and valuable features for students and staff. Maintenance criteria like
extensibility, modifiability, portability, and adaptability are vital for ensuring the system can evolve
and scale with changing needs. By prioritizing these design goals, the inventory management system
will meet the university's requirements effectively and efficiently

1.3 Scope
The university's inventory management system aims to streamline tracking and management of
academic resources, equipment, and supplies across departments and campuses. With real-time
inventory tracking, automated notifications, reporting tools, and user access control, the system will
enhance efficiency, accuracy, and decision-making. By optimizing resource allocation, reducing
manual errors, and providing data-driven insights, the system will improve operational efficiency,
cost savings, and compliance with audit requirements.

1.4 Overview
The remaining sections of the Software Design Document (SDD) for the inventory
management system in the university are organized as follows:

Section 2: System Overview

1
 Software Design Description for inventory management system

This section provides a detailed description of the major subsystems being modeled in the
design. It outlines the overall structure of the system, including its components and how they
interact with each other.

Section 3: Software Architecture

In this section, the software architecture of the inventory management system is presented.
It includes information on the high-level design decisions, such as the choice of
technologies, frameworks, and patterns used in the system.

Section 4: Logical Database Requirements

This section outlines the design of the logical database requirements for the inventory
management system. It includes details on the database schema, tables, relationships, and
data storage considerations.

Section 5: Subsystem Modeling with UML

In this section, a detailed level of subsystem modeling using Unified Modeling Language
(UML) is provided. It includes class diagrams, sequence diagrams, and other UML diagrams
to illustrate the interactions and relationships between different components of the system.

Section 6: Design of Human Interface

The final section focuses on the design of the human interface from the user's perspective. It
includes details on the user interface design, navigation flow, user interactions, and usability
considerations to ensure an intuitive and user-friendly experience for users interacting with
the inventory management system.

References
<List all referenced documents (complete list of all documents) including sources used in
preparation of the SDD and specify sources from which the references can be obtained.
Apply IEEE Referencing Style throughout the SDD document.>

1.5 Definitions, Acronyms and Abbreviations

<Provide the definitions of all terms, acronyms, and abbreviations required to properly
interpret the SDD sorted in alphabetical order.>

2 System Overview
 The web-based inventory management system in Assosa university is designed to
streamline and automate the process of managing inventory items across various

2
 Software Design Description for inventory management system

departments and locations within the university. The system aims to provide real-time
visibility into inventory levels, track item movements, generate reports, and facilitate
efficient inventory management practices. It will be accessible through a web
browser, allowing authorized users to access the system from any location with
internet connectivity.

 Major Components/Modules as Subsystems:

a. User Management Subsystem: Responsible for managing user accounts, roles, and
permissions within the system.
b. Inventory Tracking Subsystem: Tracks inventory items, their quantities, locations, and
movements.
c. Reporting Subsystem: Generates various reports related to inventory levels, transactions,
and trends.
d. Notification Subsystem: Sends alerts and notifications to users regarding low stock levels,
pending orders, or other relevant information.
e. Dashboard Subsystem: Provides a visual representation of key inventory metrics and
performance indicators.

 Type of System:
The system being designed is a web-based inventory management system, accessible through
a web browser on desktops, laptops, tablets, and mobile devices. It leverages web
technologies such as HTML, CSS, JavaScript, and server-side scripting languages like PHP
or Python to deliver a responsive and user-friendly interface.

 Parts of the System:

a. Client Machines: Users access the system through web browsers on their client machines,
which can be desktops, laptops, tablets, or smartphones.
b. Server Machine: The system is hosted on a central server that stores data, processes
requests, and serves web pages to clients.
c. Database System: An external database system (e.g., MySQL, PostgreSQL) is used to store
and manage inventory data securely.

3
 Software Design Description for inventory management system

d. External Systems/Components: Integration with barcode scanners, RFID systems, and

other external hardware/software components may be required for efficient inventory
tracking and management.

By considering these components and subsystems in the design of the web-based inventory
management system for the university, we aim to create a robust and scalable solution that
meets the inventory management needs of the institution effectively.

3 System Architecture
The architecture should be robust, scalable, and secure to ensure efficient inventory management and
data integrity. In this section, we will delve into the details of the system architecture, focusing on the
use of solid-state drives (SSDs) to enhance performance and reliability. By leveraging SSDs, the
system can achieve faster data access speeds, improved responsiveness, and increased durability
compared to traditional hard disk drives (HDDs). Additionally, we will explore how the architecture
incorporates various components such as servers, databases, application layers, and integration points
to create a cohesive and effective inventory management solution. This section aims to provide a
comprehensive understanding of the system architecture and how it supports the functionality and
performance requirements of the web-based inventory management system in a university setting.

3.1 Proposed System Architecture

it is essential to partition the system into high-level subsystems that each have specific roles and
responsibilities. By decomposing the system in this way, we can achieve a more organized and
efficient design that promotes scalability and maintainability.

1. User Interface Subsystem: Responsible for handling user interactions and presenting the inventory
management system's interface to users, Includes modules for user authentication, navigation, and
data entry.

2. Inventory Management Subsystem: Manages the core functionality of the system related to
inventory tracking, updates, and reporting, Includes modules for inventory item management, stock
level monitoring, and order processing.

3. Database Subsystem: Handles data storage and retrieval for the system, Includes modules for
database connections, queries, and data manipulation.

4. Reporting Subsystem: Generates reports based on inventory data and user inputs, Includes modules
for report generation, formatting, and delivery.

5. Integration Subsystem: Facilitates integration with external systems or services, such as supplier
databases or financial systems, Includes modules for data exchange, API connections, and data
synchronization.

Collaboration between Subsystems: The User Interface Subsystem interacts with the Inventory
Management Subsystem to display relevant information to users and receive input, The Inventory
Management Subsystem communicates with the Database Subsystem to store and retrieve inventory
data, The Reporting Subsystem accesses inventory data from the Database Subsystem to generate

4
 Software Design Description for inventory management system

reports for users., The Integration Subsystem connects with external systems or services to exchange
data and ensure seamless integration.

Diagram Description: The diagram illustrates the high-level subsystems (User Interface, Inventory
Management, Database, Reporting, Integration) and their interconnections, Arrows indicate the flow
of data and interactions between subsystems, Each subsystem is labeled with its respective roles and
responsibilities.

Describe the diagram if required (supplement with text as needed). Provide descriptions of
the design components if models are complex. You can select appropriate System
Architecture for your project. Refer to the book “OOSD, System Design (Chapter 4),
Bahrami Ali.>

3.2 Design Rationale

- Scalability: Modular design allows for easy scalability by adding new features without affecting the
entire system.
- Maintainability: Isolates changes within specific subsystems, making troubleshooting and
maintenance easier.
- Separation of Concerns: Enhances clarity and reduces complexity by separating different
functionalities.
- Flexibility: Allows for customization and extension with independent subsystem development.

Critical Issues and Trade-offs Considered:

- Complexity: Requires proper communication and coordination between subsystems to avoid issues.
- Overhead: May introduce communication overhead, requiring optimization for efficient operation.
- Development Time: Requires more upfront planning and design but simplifies maintenance in the
long run.

Other Architectures Considered:

- Monolithic Architecture: Tightly integrated components could lead to scalability and maintainability
issues.
- Microservices Architecture: Offers flexibility and scalability but may be overly complex for the
university's needs.

Justification for Choosing the Modular Program Structure:

- Balance of scalability, maintainability, separation of concerns, and flexibility considerations.

- Benefits of modularity, code organization, and adaptability align well with university's needs.
- Addressing critical issues such as complexity and overhead during implementation ensures a robust
system.

4 Data Design
It involves defining the logical database requirements, creating entity relationship diagrams (ERDs),
data dictionaries, and establishing a persistent data management strategy.

5
 Software Design Description for inventory management system

In terms of logical database requirements, the entity relationship diagram (ERD) provides a visual
representation of the relationships between different entities or tables in the database. It outlines how
data entities are connected and the cardinality of these relationships. A data dictionary complements
the ERD by defining the attributes, data types, constraints, and descriptions of each entity in the
database.

Persistent data management involves establishing the relationships among tables to ensure data
integrity and consistency. This includes defining primary and foreign keys, establishing referential
integrity constraints, and implementing normalization techniques to minimize redundancy and
improve data integrity.

The persistent data stored by the system typically includes information about inventory items,
suppliers, purchase orders, transactions, users, and other relevant data entities. The data management
infrastructure required for this system may involve selecting a suitable database management system
(DBMS) such as MySQL, PostgreSQL, or MongoDB based on the system's requirements and
scalability needs. The encapsulation of the database involves defining access controls, security
measures, backup and recovery procedures, and optimization techniques to ensure data reliability and
performance.

In summary, a well-designed data structure is essential for the successful implementation of a web-
based inventory management system in a university. By carefully considering logical database
requirements, creating ERDs and data dictionaries, and implementing robust persistent data
management strategies, the system can effectively store, retrieve, and manage data to support
inventory operations efficiently.

Entity Relationship Diagram

6
 Software Design Description for inventory management system

4.1 Data Dictionary

1. Asset:

- Type: Entity

- Description: Represents any item or resource that the university owns or manages.

2. Asset ID:

- Type: Attribute

- Description: Unique identifier for each asset.

3. Asset Name:

- Type: Attribute

- Description: Name or title of the asset.

4. Barcode/QR Code:

- Type: Attribute

- Description: Unique identifier in the form of a barcode or QR code assigned to each asset for easy
tracking.

5. Category:

- Type: Entity

- Description: Represents the category or type of asset.

6. Category ID:

- Type: Attribute

- Description: Unique identifier for each category.

7. Category Name:

- Type: Attribute

- Description: Name of the category.

8. Comments:

- Type: Attribute

- Description: Additional notes or comments related to the transaction.

9. Condition:

- Type: Attribute

7
 Software Design Description for inventory management system

- Description: Represents the condition or state of an asset (e.g., new, used, damaged).

10. Cost:

- Type: Attribute

- Description: Total cost associated with purchasing the assets in the purchase order.

11. Expected Delivery Date:

- Type: Attribute

- Description: Estimated date when the assets from the purchase order are expected to be delivered.

12. Invoice Number:

- Type: Attribute

- Description: Unique identifier for the invoice associated with the purchase order.

13. Location:

- Type: Entity

- Description: Represents a physical location where assets are stored or utilized.

14. Location ID:

- Type: Attribute

- Description: Unique identifier for each location.

15. Location Name:

- Type: Attribute

- Description: Name or description of the location.

16. Maintenance Record:

- Type: Entity

- Description: Represents records of maintenance activities performed on assets.

17. Maintenance Record ID:

- Type: Attribute

- Description: Unique identifier for each maintenance record.

18. Maintenance Date:

- Type: Attribute

- Description: Date when the maintenance activity was performed.

8
 Software Design Description for inventory management system

19. Maintenance Type:

- Type: Attribute

- Description: Type or description of the maintenance activity (e.g., inspection, repair).

20. Maintenance Description:

- Type: Attribute

- Description: Details or notes regarding the maintenance activity.

21. Order Date:

- Type: Attribute

- Description: Date when the purchase order was placed.

22. Purchase Order:

- Type: Entity

- Description: Represents an order placed with a supplier to purchase assets.

23. Purchase Order ID:

- Type: Attribute

- Description: Unique identifier for each purchase order.

24. Quantity:

- Type: Attribute

- Description: Represents the number of units of a particular asset.

25. Quantity Changed:

- Type: Attribute

- Description: Specifies the change in quantity of an asset due to the transaction.

26. Received Date:

- Type: Attribute

- Description: Actual date when the assets from the purchase order were received.

27. Role:

- Type: Attribute

- Description: Specifies the role or permission level of the user within the system.

28. Supplier:

9
 Software Design Description for inventory management system

- Type: Entity

- Description: Represents the external entities or companies from which the university procures
assets.

29. Supplier ID:

- Type: Attribute

- Description: Unique identifier for each supplier.

30. Supplier Name:

- Type: Attribute

- Description: Name of the supplier.

31. Transaction:

- Type: Entity

- Description: Represents a record of a transaction involving assets.

32. Transaction ID:

- Type: Attribute

- Description: Unique identifier for each transaction.

33. Transaction Date:

- Type: Attribute

- Description: Date and time when the transaction occurred.

34. Transaction Type:

- Type: Attribute

- Description: Indicates the type of transaction (e.g., addition, removal, transfer).

35. User:

- Type: Entity

- Description: Represents individuals who are associated with the inventory system.

36. User ID:

- Type: Attribute

- Description: Unique identifier for each user.

37. Username:

- Type: Attribute

10
 Software Design Description for inventory management system

- Description: Name used by the user to log in.

4.2 Persistence Modeling

11
 Software Design Description for inventory management system

5 Component Design

5.1 Logical Modeling

5.2 Interaction Modeling

5.2.1 Activity Diagram

 <Draw the Activity Diagrams.>

12
 Software Design Description for inventory management system

5.2.2 Sequence Diagram

 <Draw the Sequence Diagrams.>

5.2.3 Collaboration Diagram

 <Draw the Collaboration Diagrams.>

5.3 State Dynamic Modeling

 <Draw the State Chart Diagrams.>

5.4 Dependency Modeling

5.4.1 Subsystem Decomposition

 <Draw the Subsystem Decomposition (Package Diagram) for the entire System.>

5.4.2 Component Diagram

 <Draw the Component Diagram for the entire System.>

5.4.3 Deployment Diagram

 <Draw the Deployment Diagram (Hardware/Software Mapping) for the entire System.>

6 Human Interface Design

6.1 Overview of User Interface
<Describe the functionality of the system from the user’s perspective. Explain how the user
will be able to use your system to complete all the expected features and the feedback
information that will be displayed for the user.>

6.2 Screen Images

<Display screenshots showing the interface from the user’s perspective. These can be hand
drawn (Screen Mock-ups) or you can use an automated drawing tool. Just make them as
accurate as possible. Graph paper works well. This section can be unified with section 6.3>

6.3 Screen Objects and Actions

<A discussion of screen objects and actions associated with those objects i.e., where does
the user needs to "Click", and what sequence in which Use Case, will come to action.>

13