SRS Document Prepered by Group 3 Student

Assosa University
College of Computing and Informatics

Department of Computer Science
<Insert Name of the Project>

A Software Project Documentation Submitted to the
Department of Computer Science of Assosa University in Partial Fulfillment of
Requirements for the Degree of Bachelor of Science in Computer Science
Prepared by:
Name of Student 1
Name of Student 2
Name of Student 3
…….
Advisors’ Name:
Main Advisor ……………
Co-Advisor ……………
<Submission Date>
Software Requirements Specification
for
Web based property management system for ASU
Version 1.0 approved
Prepared by <author1, author2, author3, …. >
<organization>
<date created>
i
Software Requirements Specification for Web based property management system for ASU
Acknowledgement
First of all, we want to thank the God who permits us to do and enable us to preparing this
SRS to our system. Next a special gratitude we give to our advisor Mr. Adissu (MSc) for his
contribution in stimulating suggestions and encouragement, helped us to coordinate
especially in writing this SRS. And we would like to express our deepest appreciation to all
those who provided us the possibility to complete this SRS that they helped us by providing
basic information’s about the idea of the system. Finally, we would like to express more to
all who provide information to support, encouragement, comments and gives useful
information in any time when we want to ask information they give happy face and necessary
information.
|Page
Table content
Table of Contents
Acknowledgement........................................................................................................ii
Table content........................................................................................................................
List of figure..........................................................................................................................
LIST OF TABLES...................................................................................................................
1 INTRODUCTION.........................................................................................................
1.1 Document Purpose...........................................................................................2
1.2 Product Scope..................................................................................................ii
1.3 Intended Audience and Document Overview...................................................ii
1.4 Definitions, Acronyms and Abbreviations........................................................iv
1.5 References.......................................................................................................v
2 Overall Description...................................................................................................
2.1 Product Perspective........................................................................................vi
2.2 Product Functions..........................................................................................vii
2.3 User Classes and Characteristics....................................................................ix
2.4 Operating Environment....................................................................................x
2.5 Design and Implementation Constraints..........................................................x
2.6 User Documentation.......................................................................................xi
2.7 Assumptions and Dependencies.....................................................................xi
3 Specific Requirements............................................................................................
3.1 External Interface Requirements....................................................................xii
3.1.1 User Interfaces...............................................................................................
3.1.2 Hardware Interfaces.......................................................................................
3.1.3 Software Interfaces........................................................................................
3.1.4 Communication Interfaces............................................................................
3.2 Functional Requirements...............................................................................xiii
3.3 System Use Case Modeling...........................................................................xiv
3.3.1 Actors and Use Cases....................................................................................
3.3.2 Use Case Diagram.......................................................................................xviii
3.3.3 System Use Case Documentation..................................................................
4 Non-Functional Requirements............................................................................xxvi
4.1 Performance Requirements.........................................................................xxvi
4.2 Safety and Security Requirements.............................................................xxvii
4.3 Software Quality Attributes.........................................................................xxvii
4.3.1 Reliability....................................................................................................xxvii
4.3.2 Robustness...................................................................................................xxvii
4.3.3 Availability..................................................................................................xxvii
4.3.4 Maintainability............................................................................................xxvii
|Page
4.3.5 Portability...................................................................................................xxvii
List of figure
Figure 1 Overall Architecture of the PIMS.............................................................................................9

Figure 1: use case diagram for web based purchasing information management system..................21
|Page
LIST OF TABLES
Table 1. Terms and their definition.......................................................................................................8

Table 2. Abbreviations and Acronyms...................................................................................................9
Figure 1 Overall Architecture of the PIMS...........................................................................................11
Figure 1: use case diagram for web based purchasing information management system..................23
Table 2: use case description for request purchasing need................................................................24
Table 3: use case description for post directorate notice...................................................................25
Table 4: use case description for approve or reject purchasing request.............................................26
Table 5: use case description for study market and announce price..................................................26
Table 6: use case description for login................................................................................................27
Table 7: use case description for modify market detail......................................................................27
Table 8: use case description for register winners..............................................................................28
Table 9: use case description for create account................................................................................28
Table 10: use case description for logout............................................................................................29
Table 11: use case description for view model19...............................................................................29
Table 12: use case description post details of winner.........................................................................30
Table 13: use case description register quality of supplied item.........................................................30
|Page
1 INTRODUCTION
The Purchasing Information Management System (PIMS) for Assosa University SRS is
designed to document and describe the agreement between the stakeholders, users, and
developers regarding the specification of the software product requested. Its primary purpose
is to provide a clear and descriptive “statement of user requirements” that can be used as a
reference in further development of the software system. This document is broken into a
number of sections used to logically separate the software requirements into easily referenced
parts. This SRS aims to describe the Functionality, External Interfaces, Attributes, and
Design Constraints imposed on the implementation of the purchasing information
management system described throughout the rest of the document. Throughout the
description of the purchasing information management system, the language and terminology
used are unambiguous and consistent throughout the document.
1.1 Document Purpose

The software requirements specified in this document pertain to the purchasing property
management system for Assosa University. This SRS outlines the scope of the product,
which covers the software requirements for managing the purchasing and property
management processes within the university. The system is designed to streamline and
automate various aspects of purchasing and property management, including inventory
control, vendor management, procurement processes, asset tracking, and financial
management related to these activities.
The purpose of this document is to provide a comprehensive overview of the software

requirements for the purchasing property management system at Assosa University. It details
the functional and non-functional requirements, user interfaces, system interfaces, and other
relevant specifications necessary for the development and implementation of the system.
|Page
Additionally, it serves as a guide for stakeholders involved in the project, including

developers, designers, testers, and end-users, to understand the scope and expectations from
the system.
1.2 Product Scope

The software product being specified is a Purchasing Information Management System
(PIMS) designed specifically for Assosa University. The purpose of this software is to
streamline and automate the university's purchasing processes, including requisition,
approval workflow, vendor management, purchase order generation, and tracking of
purchases. PIMS aims to improve efficiency, reduce manual paperwork, and provide
transparency in the university's procurement activities.
PIMS will allow various user classes, including university staff, department heads, and
procurement officers, to interact with the system based on their roles and responsibilities.
The software will enable staff to submit purchase requests, department heads to approve or
reject requests, and procurement officers to manage vendor information, generate purchase
orders, and track purchases. The primary goal of PIMS is to enhance the university's
purchasing process, leading to cost savings, improved vendor management, and streamlined
procurement operations. The software will not handle financial transactions or accounting
aspects, as those are typically managed by the university's financial systems.
1.3 Intended Audience and Document Overview

The Purchasing Information Management System (PIMS) for Assosa University is intended
for multiple types of readers, including:
Developers: This document provides detailed information about the technical

requirements, system architecture, and coding standards for the PIMS.
|Page
Project Managers: Project managers can find valuable information about project
scope, timelines, milestones, resource allocation, and overall project management.
This helps with effective planning and coordination throughout the development
lifecycle of the PIMS.
University Staff: Those who will use the system to submit purchase requests, track
purchases, and interact with the procurement process.
Department Heads: Responsible for approving or rejecting purchase requests and
overseeing departmental procurement activities.
Procurement Officers: In charge of managing vendor information, generating
purchase orders, and tracking purchases.
Testers: Testers can find information related to test cases, scenarios, and expected
system behavior. This helps in the development of a robust testing strategy to ensure
the reliability and functionality of the PIMS.
Documentation Writers: Individuals responsible for creating user manuals and
technical documentation can find relevant information to support the documentation
process. This ensures clarity and accuracy in conveying instructions to end-users
Document Overview:
This document discusses the following topics briefly.
. The document is organized into different sections,
 First section:-focusing on the introduction of the SRS and outlining the project's
objectives.
 The second section:-addresses the overall description of the PIMS, including a
product overview that describes the context and origin of the intended software, along
with a simple diagram showing the interaction of system components. Additionally,
the functionality of the system is briefly stated in this section.
 Thread Section: - covers functional and external interface requirements of the PIMS.
It includes detailed descriptions of interface requirements, hardware requirements,
and software requirements. The use case model, which encapsulates the entire system
with its stakeholders, is also presented at the end of this section.
|Page
 Fourth Section: - focuses on the non-functional requirements of the PIMS,

particularly emphasizing performance, security, and safety requirements. Software
quality attributes of the system are also discussed as an additional part of this section.
 Finally:-in the last section of this SRS, other requirements specific to the Purchasing
Information Management System for Assosa University will be addressed.
1.4 Definitions, Acronyms and Abbreviations
Terms Definition
Actor It is a model element that interacts with a system [1].
Bootstrap A front-end user interface template library.
Constraints The possible limitations, which is imposed from the side of clients.
Functional requirement It is a description of the service that the software must offer [2].
Non-functional requirement Define system attributes such as security, reliability, performance,

maintainability, scalability, and usability [3].
Requirement It is a description of the service that the software must offer.
Stakeholders Any direct or indirect user of the system.
Use case model It is a model of how different types of users interact with the system
to solve a problem [4].
Table 1. Terms and their definition
Abbreviations and Acronyms Meaning
ASU Assosa University
CSS Cascading Style Sheets

HTML Hypertext Markup Language
|Page
HTTPS Hypertext transfer protocol secure

MySQL My Structured Query Language
PHP Hypertext Preprocessor
SRS Software Requirements Specification
UML
Unified Modeling Language
PPMS
Purchasing Property
FR Functional requirement
OOSAD object oriented system analysis and design
UI user interface
UC use case
Table 2. Abbreviations and Acronyms
1.5 References
 http://ampps.com/wamp
 https://www.procurementexpress.com/index.php/web-based-purchase-order-system/
 https://www.slideshare.net/shahavish/types-of-purchasing-system
 http://www.jigsaw.com.au/solutions/webpo.aspx
 https://issgroup.com/purchase-requisition-management-system/
Books
 James Rumbaugh, Ivan Jacobson, Grady Booch; The Unified Modeling Language
Reference Manual
 Andy Harris: PHP6/Mysql programming for the absolute beginners.
 Designing websites using PHP, 2004
 Easy way to develop websites through PHP (3rd Edition)
 Whitten, L.Jeffrey.Bentley, D.Lonne.Barlow, M.Victor. Systems Analysis and
Design Methods.2nd .ed.New Jersey: prentice hall (1989).
|Page
2 Overall Description
2.1 Product Perspective

The Purchasing Information Management System (PPMS) for Assosa University is a self-
contained product designed to streamline and centralize the university's procurement
processes. It is not a replacement for existing systems but rather a new addition to the
university's technological infrastructure. PPMS is intended to integrate with other
administrative systems within the university, such as finance and inventory management, to
ensure seamless data flow and process synchronization. While it is a standalone system, it
will have interfaces with external vendors and suppliers for data exchange and procurement
activities. The system is designed to be scalable, adaptable, and interoperable with potential
future systems or upgrades within the university's IT ecosystem.
Figure 1 Overall Architecture of the PIMS
|Page
2.2 Product Functions

 Department head,officescollege Administrator School dean, Technical room
 Request purchasing needs
 Check the purchased items
 receive the item based on their request and materials specification
 register the withdrawing form (model20)
 Purchasing directorate
 Manage staff/workers
 Group purchasing requests based on item type
 Plan for purchasing activities
 Post purchasing related notices
 Approval committee
 Approve/reject the request that comes from technical room and college
administrator.
 Evaluate the winner
 Evaluate the plan
 Purchasing team
 Open the tender
 Register the winner
 Takes an agreement with the supplier
 View market detail that comes from market study team
 Post bid notice
 Post bid result
 Market study team
 Study(register) the market means that the price of the items
 announce market detail to purchasing team
 modify market detail
 Purchasing workers
|Page
 Purchase the identified items

 They Involve in direct purchasing
 Address the purchased materials inventory department
 Report to purchasing team if the material is not found in the market
 Suppliers
 Fill the price and detail of the item that he/she supplies
 Supply the materials if they are selected as a winner
 Taking agreement with purchasing team
 Apply for the tender or register to be among competitors
 View the result of the tender that he/she was participate
 Property administration team
 Registering the purchased items that they receive from the supplier
 Store purchased items
 Distribute the purchased items to departments and colleges
 Quality assurer
 Assure quality of the supplied item
 View the items that the supplier supplies
 Finance officer
 View model 19 that the supplier is received from inventory department
 View tender result
 College administrator
 View purchasing requests that comes from each departments
 Send those requests to purchasing directorate
2.3 User Classes and Characteristics

Administrative Staff: Characteristics these users will have a high frequency of use,
accessing a broad array of product functions for initiating, approving, and tracking purchase
requests.
|Page
Knowledge and Skills They should possess a deep understanding of university procurement
policies, financial norms, and departmental purchase needs.
Procurement Team: Characteristics these users will heavily rely on the system for purchase
requisitioning, negotiation details, and ensuring compliance with procurement rules.
Knowledge and Skills They require expertise in vendor management, contractual

negotiations, and a thorough understanding of procurement regulations.
Finance Officers: Characteristics these users will focus on reviewing financial implications,
monitoring budget constraints, and authorizing final purchasing decisions.
Knowledge and Skills They need a comprehensive grasp of financial processes, budget
management, and compliance standards.
System Administrators: Characteristics these users will oversee system maintenance, user
access levels, and system security protocols.
Knowledge and Skills They require technical expertise in system administration, data
security, and user role management.
Purchase Directorate: Characteristics The purchase directorate team drives strategic

procurement decisions, oversees large-scale contracts, and ensures adherence to
organizational procurement policies.
Knowledge and Skills Members of this user class possess in-depth knowledge of
procurement regulations, contract management, and the ability to analyze complex
purchasing needs.
Procurement Team Members: Characteristics The procurement team members are

responsible for executing and implementing the directives and strategies set forth by the
purchase directorate. They handle day-to-day procurement activities and are involved in
vendor negotiations and contract management.
Knowledge and Skills This user class demands expertise in vendor relationship management,
negotiation techniques, and specialized knowledge of specific procurement categories.
|Page
2.4 Operating Environment

The system is engineered to operate on both computer and mobile platforms, catering to
users who prefer desktops or mobile devices for procurement activities. This ensures
flexibility and ease of access, allowing users to manage purchasing information efficiently
regardless of their preferred device.
Users can access the system through different internet browsers, including Chrome, Mozilla
Firefox, UC browser, and other major browsers. This diversity in browser compatibility
guarantees that a broad range of users can seamlessly utilize the web-based interface,
facilitating efficient procurement management across various browser environments.
2.5 Design and Implementation Constraints

Basic Computer Skills: Users of the system are required to possess basic computer
skills. This constraint necessitates intuitive user interfaces, clear navigation, and user-
friendly design to accommodate users with varying levels of computer literacy.
Mobile Device Access: Since a mobile application will be utilized, the constraint of
access to technology comes into play. This implies that users should have access to
mobile devices with compatible specifications and Android version requirements to
utilize the mobile application effectively.
Device Compatibility: Considering the constraint of device capacity, the system's
mobile application will require compatibility with Android devices using API 23 or
above. This means users with Android devices running on versions below API 23
may face limitations in utilizing the system's mobile application.
2.6 User Documentation

 User Manual: The user manual will present a detailed product overview,
encompassing the system's functionality, features, and usage specifics. It will further
delve into the entire configuration process, detailing the necessary software and
hardware requirements. In addition, it will contain comprehensive technical
|Page
information and contact details to facilitate users' understanding and successful usage
of the system.
 Technical Documentation: The system's user manual will offer advanced technical
details, explaining the functional attributes and the application of the visualization
software. This will ensure that users, administrators, and technical staff have access to
comprehensive documentation for a thorough understanding of the system’s features
and capabilities.
 Ongoing Support and Source Code Documentation: The development team will be
readily available to provide support, assistance, and guidance in case of any queries
or issues during the system's usage. Moreover, the source code will be extensively
documented, enhancing comprehension and facilitating potential future development
by external parties. This commitment to well-documented source code ensures the
system remains understandable and maintainable for any future enhancements or
modifications.
 By leveraging meticulous documentation and comprehensive support measures, the
purchasing information management system will prioritize user comprehension,
operational efficacy, and seamless ongoing support, aligning with Assosa University's
objective of effective procurement management.
2.7 Assumptions and Dependencies

Internet Accessibility: We assume that all users will have access to the internet with
reliable speed to effectively access and utilize the system. This assumption is critical as the
system's operations rely on seamless internet connectivity for efficient usage and data
synchronization.
User Proficiency: Another assumption is that all users possess basic computer and mobile
usage skills, in addition to a general understanding of how to operate the system. This
general knowledge is pivotal in ensuring smooth adoption and usage of the system among all
user classes.
|Page
These assumptions and dependencies form the foundation for ensuring a seamless and
effective implementation of the purchasing information management system at Assosa
University, emphasizing the importance of reliable internet access and the users' proficiency
in utilizing computer and mobile devices for system operations
3 Specific Requirements
This section describes the interface requirements hardware and software requirements, user
interfaces and detailed description about the logical and database requirements and design
constraints.
3.1 External Interface Requirements

3.1.1 User Interfaces
The applications of the project team are developing web-based system and mobile app. It is
not difficult to use it. The project team also uses minimum number of components on the
interfaces so it makes easy usage. They are only expected to know basic computer skill and
since the application is working over the internet, the users should know at least how to use
the internet and to navigate the browsers. It also provides user friendly graphical user
interface.
 Login Page: this page is the first page of the system. It is used to login the user to the
system by requesting the user to insert username and password. It contains a text field
for username, password field for the password, with a login button.
 Home Page: this page will be different throughout the user type. This page is loaded
as soon as the user logins successfully.
3.1.2 Hardware Interfaces

Client side for web based
 Processor : Intel(R) Core(TM) i3-6100 CPU @ 3.50 GHz and above

 RAM : 4GB
Client side for android based
|Page
 Processor : Qualcomm® Quad-core ARM® Cortex®-A53 1.2GHz and above

 RAM : 2GB and above
Server side
 Processor : Intel(R) Core(TM) i3-6100 CPU @ 3.50 GHz

 RAM :8 GB
Additional disk space for storing data size and additional memory may be required.
3.1.3 Software Interfaces

Client side
 Any operating system

 Any updated web browser
Server side
 any operating system

 apache Server and MYSQL
3.1.4 Communication Interfaces

Client on Internet will be using HTTPS protocols as a communication interface to facilitate
communications between the client and server.
3.2 Functional Requirements

Functional requirement is a function or feature that must be included in an information
system to satisfy the system need and be acceptable to the user. Functional requirements
describe what the system should do. In short it is an action of the system. Functional
requirements that must be included in our system are:
|Page
FR1: The system shall Record and store the all purchase information in short time
FR2: The system shall Retrieving the information of materials for the customer easily.
FR3: The system shall internal customer registration
FR4: The system shall Record and group purchasing details of materials
FR5: The system shall Issuing member username and password
FR6: The system shall update member/database
FR7: The system shall generate different reports
FR8: The system shall hold back up of records
FR9: The system shall Give feedback for each and every actions of the user
3.3 System Use Case Modeling

3.3.1 Actors and Use Cases
In this section, the requirement is documented as use case, which is a list of actions or event
steps typically defining the interactions between a roles known as an actor in UML and a
system to achieve a goal. The actor can be a human or other external system. Use case
identification is essential for simplifying the system and better understand it in simple terms
as a result it will assists in the implementation of the system.
Actors
Actors represent system users. They help to delimit the system and give a clear picture of
what the system should do. It is important to note that an actor interacts with, but has no
control over the use cases.
|Page
Administrator
• Register users
• Take backup
• Block account
• Reactivate account
• Create account
Purchasing directorate
• Post notice to announce departments and colleges to submit their purchasing needs
• Manage workers such as market study teams and others
• Plan for different purchasing activities
• View different purchasing requests that are submitted by librarian and colleges
• View model 19 form detail of a winner that has been given by inventory department
that ensures the winner as he/she has supplied the items
Purchasing team
• Register winners detail

• Post notice online to announce different suppliers to apply for a tender
• Post the tender result online
• View market detail that is sent from market study team
• View winners
Purchasing Approval committee
• Approve/reject different purchasing requests by considering different measurements

such as budget amount and validity of the submitted purchasing requests
• Evaluate winners
• View tender result
Market study team
• register market detail

• Announce the market detail to purchasing team as well as for purchasing directorate
|Page
• Modify market detail in three months
Inventory department
• Report items that are stored in the inventory to purchasing directorate as well as for
approval committee with item types including items quantity
• Receive model 20 form detail that is submitted by departments and colleges when
they want to withdraw an item from store
• Registers the detail of model22 to check that the department and colleges are
withdraw an item from a store
Finance officer
• View model 19 and a letter that comes from winner that has given by inventory
department and purchasing directorate respectively
• View purchased product or items detail
College administrator
• Send those purchasing requests to purchasing directorate

• View notice
• View purchasing requests that comes from schools
Department head
• Request their purchasing need to college administrator

• register model20 to withdraw the purchased items from the inventory department
• View directorate notices
• View offices purchasing request
Purchasing workers
• Involve in direct purchasing means that when the organization wants to buy products
that does not need a tender and when the items are too important
• register the purchased product detail
Quality assurer
|Page
• Register the quality of different products that are supplied by the winner including
their originality
• If those products are not valid based on the specification the products are returned to
the winner otherwise they entered in to the inventory department
Supplier
• Fill their own detail such as trade license, tin number, vat registration number
• Modify their own detail until the biding notice final submission date is not reach
• View tender/bid result
• View tender notice
Technical room
• Request library purchasing needs to purchasing directorate

• View purchasing directorate notices
• Register model 20 to withdraw an item that they request when purchasing is finished
Offices
• Request their purchasing needs to their department head

• Register model 20 to withdraw the purchased item
School dean
• Request their purchasing needs to their college administrator

• View departments purchasing requests
• Register model 20 to withdraw the purchased item
3.3.2 Use Case Diagram

The Use Case Model describes the proposed functionality of the new system. A Use Case
represents a discrete unit of interaction between a user (human or machine) and the system. A
|Page
Use Case is a single unit of meaningful work; for example login to system, register with
system and create order are all Use Cases. Each Use Case has a description which describes
the functionality that was built in the proposed system.
Figure 1: use case diagram for web based purchasing information management
system
|Page
3.3.3 System Use Case Documentation
Use case: Request purchase

Use case ID: Uc1
Description To ask or request purchasing needs to be purchased to satisfy

their needs
Actors: Department head , college administrator , school dean , offices

, technical room
Pre-conditions: A person must interact with the login page.
Basic course of action: 1. The system asks the actor for their user name and password.
2. The actor enters their user name and password.
3. The user name and password are correct.
4. The system authenticates the user.
Alternative course of action If the actor enters incorrect username and password the system
displays an error message
Post conditions: If the material is present in inventory department within needed

amount the system should give a message which says it is
present in inventory department otherwise the system says the
request is successfully it is send to purchasing directorate.
Table 1: use case description for request purchasing need

Use case: Post directorate notices
Use case ID: Uc39
Description To post notice online to ask to submit their purchasing need at
|Page
the end of each year for the next year purchasing activities
Actors: Purchasing directorate
Pre-conditions: Purchasing directorate should interact within the login page

Basic course of action: 1. The system asks the actor for their user name and password.
2. The actor enters their user name and password.
3. The user name and password are correct.
4. The system authenticates the user.
Alternative course of action If the username and password is incorrect the system display
incorrect username and password message.
Post conditions: The purchasing directorate should post the notice to other staff
members
Table 2: use case description for post directorate notice
Use case: Approve/reject purchase request
Use case ID: Uc3
Description Toapprove different purchasing requests
Actors: Approval committee
Pre-conditions: The approval committee must interact with the login page
Basic course of action: 1.login with user name and password
2.if username and password is correct the system must display
the user page
3.if username and password is incorrect back to step 1
Alternative course of action If username and password is incorrect the system stays on the
login page
Post conditions: 1. Calculate total budget and decide whether it is enough to
buy or not and if the budget is sufficient they approve the
request otherwise they reject it.
2. Check whether the item is present in the inventory
department or not with a needed amount and quality. If
|Page
the item is present they reject the request unless they

approve it.
Table 3: use case description for approve or reject purchasing request

Use case: Register market detail
Use case ID: Uc4
Description To register and announce market detailof item that has to be
purchased
Actors: Market study team
Pre-conditions: Market study team must interact to the login page

Basic course of action: 1.login with user name and password
2.if username and password is correct the system must display
you login successfully
3.if username and password is incorrect back to step 1
Post conditions: Announce the price of each item to the purchasing team
Table 4: use case description for study market and announce price
Use case name login
Id Uc5
Description A user must interact with the login page
Actor Department head, college administrator, purchasing directorate,

approval commite,market study team, purchasing team,
purchasing worker,administrator,finance officer, quality
assurer, property administration team.
Precondition All actor must have an account
Post condition The user is logged in the system and provided with privileges
for actions according to their roles.
Basic course of action actor action System response
|Page
1. User opens the web 3. Login form displayed

page. 6. Validate data entry
2. Select Login link. 7. User’s homepage
4. Enter username and displayed.
password. 8. Use case end.
5. User clicks on Login
button.
Alternative course of action If the user enters incorrect username and password the
system should display please enter correct username and
password
Table 5: use case description for login
Use case name Modify market detail
Id Uc9
Description To update the market detail in 3 months
Actor Market study team
Precondition The market study team must login with his/her self-account(username
and password)
Basic course of Actor action system response

action 1.market study team interact to login 2.the system displays the login
page page
3.market study team enters username 4.if username and password is
and password correct the system loads to
user page
5.else back to step 2
Alternative course of If the user enters incorrect username and password the system should
action display please enter correct username and password
Post condition Market study team announces or posts the market detail of each and
every item
Table 6: use case description for modify market detail
Use case name register winners
Id Uc7
Description To register the winner among several suppliers
|Page
Actor Purchasing team
Precondition The purchasing team must login with his/her self-account(username and
password) to register the winners detail
Basic course of Actor action1.purchasing team interact system response

action to login page 2.the system displays the login
3.supplier enters username and page
password 4.if username and password is
5.the team selects the supplier who correct the system displays
presents the item with best price that the fill price table
means not much expensive price of the
item
Alternative course of If the user enters incorrect username and password the system should
action display please enter correct username and password
Post condition The purchasing team registers the details of the winner
Table 7: use case description for register winners

Use case name Create account
Id Uc8
Description To create an account for users
Actor administrator
Precondition The administrator must login to create an account for users
Basic course of 1. Click on login button

action 2. Click create account button
3. Fill the required information
4. Click create account button
5. End of use case
Alternative course of If there is no any request, page displays there is no any posted requests
action
Post condition The approval committee views each purchasing requests and decide
whether it is going to be purchased or not by considering the overall
budget and clarity of the request.
Table 8: use case description for create account
Use case: Logout
Use case ID: UC9
Description To exit from the system
|Page
Actors: Department head, college administrator, purchasing directorate,

approval commite,market study team, purchasing team,
purchasing worker,administrator,finance officer, quality assurer,
property administration team.
Pre-conditions: Click on logout button
Basic course of action: 1. Actors click on logout icon
2. The system makes the user out of the system
Post conditions: The users become out of the system
Table 9: use case description for logout
Use case name View model19
Id Uc10
Description To view the price of the item that the supplier supplied
Actor Finance officer , purchasing directorate , purchasing team, property

administration team , quality assurer
Precondition The finance officer must login to the system to view approved price of
an item
action 2. Click view approved price of items
3. Access the information and pay that amount of money to the
supplier
4. End of use case
Alternative course of If there is no any approved price of that item, page displays there is no
action approved price of the item
Post condition Finance officer views price of each item.
Table 10: use case description for view model19

Use case name Post details of winner
Id Uc11
Description To announce the winner online for the competitors and for the finance
officer
Actor Purchasing team
Precondition The purchasing team must login to the system to post winner details
|Page
action 2. Click on post winners detail

3. Access the page and write the details of the winner and post it
online
4. End of use case
Post condition Purchasing team announces the supplier that is selected as a winner
Table 11: use case description post details of winner

Use case name register quality of supplied item
Id Uc12
Description To check whether it is the right material or not based on the specification
of that material or item
Actor Quality assurer
Precondition The quality assurer must login to the system to check the validity of the
material that the supplier presents.
action 2. Click view purchased items
3. Access the information and decide whether it is valid or not
4. End of use case
Alternative course of If there is no any purchased or supplied item the system displays there is
action no any purchased item until now.
Post condition Quality assurer views the validity, originality and quality of each item.
Table 12: use case description register quality of supplied item
4 Non-Functional Requirements
4.1 Performance Requirements

The performance of the system will be high the maximum time used to load the login page
and the time used to authenticate users when logging is less than two seconds. Also multi
user can access the system at the same time which shouldn’t affect the performance. The
system should be easily accessed whenever there is internet access.
|Page
4.2 Safety and Security Requirements

There are several user levels in PIMS for Assosa University, Access to the various
subsystems will be protected by a user log in screen that requires username and password.
This gives different views and accessible functions of user levels through the system.
Maintaining backups ensure the system database security. System can be restored in any case
of emergency.
4.3 Software Quality Attributes

4.3.1 Reliability
The system must perform accurately towards member request. For example, when the
workers save the edited profile detail, after they review their detail, the details must be
change according to the latest details that they have updated. Besides that, in the registration
form, it has validity check to check the input to prevent wrong data type.
4.3.2 Robustness
Our system is strength full to handle system functions accurately.
4.3.3 Availability
Our system will be accessible 24/7, anywhere and via PC, mobiles devices and tablets with an
internet connection
4.3.4 Maintainability
Whenever our system is needed to be changed or if it is needed to add some other extra
functionality, the current developed system is going to be kept as it is and correct defects
with making changes.
4.3.5 Portability
This web-based application is viewable and fit with any standard web browsers, various
operating systems such as Windows, Linux, and on devices like personal computers, mobile
phones and tablets.
|Page

SRS Document Prepered by Group 3 Student

Uploaded by

Copyright:

Available Formats

You might also like

SRS Document Prepered by Group 3 Student

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRS Document Prepered by Group 3 Student

Uploaded by

Copyright:

Available Formats

Assosa University

College of Computing and Informatics

<Insert Name of the Project>

Web based property management system for ASU

Version 1.0 approved

Prepared by <author1, author2, author3, …. >

Figure 1 Overall Architecture of the PIMS.............................................................................................9

Table 1. Terms and their definition.......................................................................................................8

1.1 Document Purpose

The purpose of this document is to provide a comprehensive overview of the software

Additionally, it serves as a guide for stakeholders involved in the project, including

1.2 Product Scope

1.3 Intended Audience and Document Overview

Developers: This document provides detailed information about the technical

This document discusses the following topics briefly.

. The document is organized into different sections,

 Fourth Section: - focuses on the non-functional requirements of the PIMS,

1.4 Definitions, Acronyms and Abbreviations

Actor It is a model element that interacts with a system [1].

Bootstrap A front-end user interface template library.

Non-functional requirement Define system attributes such as security, reliability, performance,

Requirement It is a description of the service that the software must offer.

Stakeholders Any direct or indirect user of the system.

Table 1. Terms and their definition

Abbreviations and Acronyms Meaning

ASU Assosa University

CSS Cascading Style Sheets

HTTPS Hypertext transfer protocol secure

PHP Hypertext Preprocessor

SRS Software Requirements Specification

OOSAD object oriented system analysis and design

Table 2. Abbreviations and Acronyms

2.1 Product Perspective

Figure 1 Overall Architecture of the PIMS

2.2 Product Functions

 Purchase the identified items

2.3 User Classes and Characteristics

Knowledge and Skills They require expertise in vendor management, contractual

Purchase Directorate: Characteristics The purchase directorate team drives strategic

Procurement Team Members: Characteristics The procurement team members are

2.4 Operating Environment

2.5 Design and Implementation Constraints

2.6 User Documentation

2.7 Assumptions and Dependencies

3.1 External Interface Requirements

3.1.2 Hardware Interfaces

 Processor : Intel(R) Core(TM) i3-6100 CPU @ 3.50 GHz and above

Client side for android based

 Processor : Qualcomm® Quad-core ARM® Cortex®-A53 1.2GHz and above

 Processor : Intel(R) Core(TM) i3-6100 CPU @ 3.50 GHz

3.1.3 Software Interfaces

 Any operating system

 any operating system

3.1.4 Communication Interfaces

3.2 Functional Requirements

FR3: The system shall internal customer registration

FR5: The system shall Issuing member username and password

FR6: The system shall update member/database