Upload
others
View
11
Download
0
Embed Size (px)
Citation preview
Software Requirements
Specification
For
THE PREPAID WATER BILLING SYSTEM
Version 1.0 approved
Prepared by
KARKERA KENNETH 14/U/7130/EVE
ALYEBO CHANTAL 14/U/4925/EVE
ACIO PEACE 14/U/4266/EVE
NYOMBI NICHOLAS 14/U/13679/EVE
14, December 2017
Software Requirements Specification for PWBS Page ii
Table of Contents Table of Contents ............................................................................................................................ ii
Revision History ............................................................................................................................. v
1. Introduction ............................................................................................................................. 1
1.1 Purpose ............................................................................................................................. 1
1.2 Document Conventions .................................................................................................... 1
1.3 Intended Audience and Reading Suggestions .................................................................. 2
1.4 Product Scope ................................................................................................................... 3
1.5 References ........................................................................................................................ 5
2. Overall Description ................................................................................................................. 6
2.1 Product Perspective .......................................................................................................... 6
2.2 Product Functions ............................................................................................................. 8
2.3 User Classes and Characteristics ...................................................................................... 9
2.3.1 Customer: .................................................................................................................. 9
2.3.2 DBA: ........................................................................................................................... 9
2.3.3 Developers: ............................................................................................................... 9
2.4 Operating Environment .................................................................................................... 9
2.5 Design and Implementation Constraints ........................................................................ 10
2.6 User Documentation ....................................................................................................... 10
2.6.1 On-line Help ............................................................................................................ 10
2.6.2 User manuals ........................................................................................................... 10
2.7 Assumptions and Dependencies ......................................................................................11
3. External Interface Requirements ........................................................................................... 12
3.1 User Interfaces................................................................................................................ 12
3.1.1 User view-create account ........................................................................................... 12
3.1.2 User view-login ......................................................................................................... 12
3.1.3 User Dashboard ......................................................................................................... 13
3.2 Hardware Interfaces ....................................................................................................... 13
3.2.1 Keypad ..................................................................................................................... 13
3.2.2 LCD screen .............................................................................................................. 13
3.3 Software Interfaces ......................................................................................................... 13
3.4 Communications Interfaces ............................................................................................ 14
4. System Features .................................................................................................................... 15
4.1 Create Account ............................................................................................................... 15
Software Requirements Specification for PWBS Page iii
4.1.1 Description and Priority .......................................................................................... 15
4.1.2 Stimulus/Response Sequences ................................................................................ 15
4.1.3 Functional Requirements ........................................................................................ 15
4.2 Login/ Logout ................................................................................................................. 16
4.2.1 Description and Priority. ...................................................................................... 16
4.2.2 Stimulus/ response sequences ................................................................................. 16
4.2.3 Functional requirements ........................................................................................... 16
4.3 Generate token................................................................................................................ 16
4.3.1 Description and Priority. ...................................................................................... 16
4.3.2 Stimulus/ response sequences .................................................................................... 16
4.3.3 Functional requirements ........................................................................................... 16
4.4 Subscribe for token......................................................................................................... 17
4.4.1 Description and Priority. ...................................................................................... 17
4.4.2 Stimulus/ response sequences ................................................................................. 17
4.4.3 Functional requirements ........................................................................................ 17
4.5 View analysis.................................................................................................................. 17
4.5.1 Description and Priority. ...................................................................................... 17
4.5.2 Stimulus/ response sequences ................................................................................. 17
4.5.3 Functional requirements ....................................................................................... 17
4.6 Keypad ........................................................................................................................... 18
4.6.1 Description and Priority. ...................................................................................... 18
4.6.2 Stimulus/ response sequences ................................................................................ 18
4.6.3 Functional requirements ....................................................................................... 18
4.7 LCD display ................................................................................................................... 18
4.7.1 Description and Priority ....................................................................................... 18
4.7.2 Stimulus/ response sequences ................................................................................ 18
4.7.3 Functional requirements ....................................................................................... 18
4.8 Flow sensor .................................................................................................................... 18
4.8.1 Description and Priority ....................................................................................... 18
4.8.2 Stimulus/ response sequences ................................................................................ 19
4.8.3 Functional requirements ....................................................................................... 19
4.9 Solenoid valve ................................................................................................................ 19
4.9.1 Description and Priority. ...................................................................................... 19
4.9.2 Stimulus/ response sequences ............................................................................... 19
Software Requirements Specification for PWBS Page iv
4.9.3 Functional requirements ...................................................................................... 19
4.10 Microcontroller ........................................................................................................... 19
4.10.1 Description and Priority. ......................................................................................... 19
4.10.2 Stimulus/ response sequences ................................................................................. 20
4.10.3 Functional requirements.......................................................................................... 20
4.11 GSM module .................................................................................................................. 20
4.11.1 Description and Priority. ......................................................................................... 20
4.11.2 Stimulus/ response sequences ................................................................................. 20
4.11.3 Functional requirements.......................................................................................... 20
5. Other Nonfunctional Requirements ...................................................................................... 23
5.1 Performance Requirements ............................................................................................ 23
5.2 Safety Requirements ...................................................................................................... 23
5.3 Security Requirements ................................................................................................... 23
5.4 Software Quality Attributes ............................................................................................ 24
5.5 Business Rules................................................................................................................ 24
6. Other Requirements .............................................................................................................. 25
Software Requirements Specification for PWBS Page v
Revision History
Name Date Reason For Changes Version
Software Requirements Specification PWBS Page 1
1. Introduction
This Software Requirements Specification (SRS) document describes the requirements of a
Prepaid Water Billing System (PWBS). The SRS begins with an introductory section describing its
overall purpose, scope. The following section will describe the software product in detail, including
functions, constraints, and user characteristics. Then, a detailed list of requirements will be provided,
after which those requirements will be modeled using use case diagrams, sequence diagrams and
system state diagrams.
1.1 Purpose
The purpose of this Software Requirements Specification (SRS) document is to provide a complete
description of both the purpose and functionality of the embedded system that is to be developed.
This document includes the details of the system’s requirements, user interface, subsystem
interactions, and design considerations.
The main intended audience for this SRS is the customer for whom the system is to be implemented.
However, this document may also be helpful to others, such as developers or water engineers, who
might be trying to understand the interactions of the system with other water meter components. The
tone of the document is fairly technical, but the goal is to depict the system at a high enough level
such that it can be understood by domain experts as well as developers.
1.2 Document Conventions
The format of this SRS is simple. Bold face text and indentation is used on general topics or main
section titles and other specific points of explanation with text size of 14 and 12 respectively. The
remainder of the document will be written with standard font, times new roman italicized text is used
to label explanatory comments and recognize diagrams.
Software Requirements Specification PWBS Page 2
1.3 Intended Audience and Reading Suggestions
This document is to be read by the development team, the project managers, marketing staff, testers
and documentation writers. Our stakeholders, company manufacturing associated hardware, company
providing embedded operating system components, and distributors who markets the finished product,
may review the document to learn about the project and to understand the requirements. The SRS has
been organized approximately in order of increasing specificity. The developers and project managers
need to become intimately familiar with the SRS:
Section 1: Introduction, provides a brief introduction to this document, the purpose,
document conventions, intended audience, reading suggestions, product scope, and
references.
Section 2: Overall Description, provides brief general descriptions of the product and its
functions, user classes and characteristics, operating environments, design and
implementation constraints, assumptions and dependencies.
Section 3: External Interface Requirements, provides the detailed information regarding
user interfaces, hardware interfaces, software interfaces and communication interfaces.
Section 4: System Features, provides the detailed description of various features of the
system.
Section 5: Other Nonfunctional requirements, provides information regarding
performance requirements, safety requirements, security requirements, software quality
attributes and business rules.
Section 6: Other Requirements Provides other requirements that are not included in the
above sections.
Others involved need to review the document as such:
Overall Description – Marketing staff have to become accustomed to the various product features in
order to effectively advertise the product.
System features – Testers need an understanding of the system features to develop meaningful test
cases and give useful feedback to the developers.
External Interface Requirements – The hardware developers need to know the requirements of the
device they need to build. The marketing staff also needs to understand the external interface
requirements to sell the product by describing the user-friendly features of the PWBS.
Software Requirements Specification PWBS Page 3
Nonfunctional and Functional Requirements – The hardware developers.
1.4 Product Scope
The scope of the product can be divided into two perspectives:
Area scope:
This shall look at the physical area where the system shall be applied. We plan to start with areas
around Kampala and spread to other areas of the country if the system works efficiently.
Functional scope:
This shall look at the specific purpose for which the product is being designed. In this case the
product is being designed for domestic use where users have got access to tap water.
A comprehensive literature survey has been carried out at the beginning for the Conceptual
understanding of the present water meter system and hence there is a need to come up with a system
that shall do the following:
To reduce wastage of fresh water.
Compel every customer to pay for the exact amount of water used or wasted.
Make every customer a self-interested guardian of the water supply.
Prevent water shortage during dry seasons.
From the study it has been concluded that a Pre-Paid water billing system is required from customer’s
and provider’s point of view.
Customer’s View:
No Monthly bills.
All you have to pay is the first pre-payment.
Easy monitoring.
Customer can easily monitor their use and spend as much as they can afford.
No unfair billing since you only pay for what you use.
Provider’s View:
To eliminate bill debt problems.
Improved Cash flow.
No Credit and Arrears Collection costs.
All customers are paying.
Software Requirements Specification PWBS Page 4
No Monthly Bills.
No need to send monthly usage bill.
The research work has been carried out with the following objectives:
To develop a system that keeps an eye on usage of water consumption.
To design a sensing system that will generate electronic count equivalent to amount of
water.
To design a control mechanism that allows water usage only when there is amount of units’
balance.
To develop a remote display device for a consumer to see water usage at their location.
Finally, to make the system as a Pre-paid water meter billing system.
Software Requirements Specification PWBS Page 5
1.5 References
[1] k. E. a. R. F. Chris Heymans, "The limits and possibilities of prepaid water in Urban Africa," The
world bank, Uganda, August 2014.
[2] M. S. C. U. R. Syed Suhail Daimi1, "Design and Development of GSM based Prepaid Water
Meter," International Journal of Advanced Research in Electrical,Electronics and Instrumentation
Engineering, vol. Vol. 5, no. Issue 3, p. 6, March 2016.
[3] d. i. group, "Payment systems in Uganda and their impact on the urban poor," Interface
consulting, kampala, February 2012.
[4] N. W. a. S. C. management, "The 100-Days Programme to Improve NWSC Services," NWSC,
Kampala, 1999.
[5] M. MULLER, "IMPLEMENTING PREPAYMENT WATER METERING SYSTEMS,"
Department of Water Affairs and Forestry, PRETORIA, OCTOBER 1997.
Software Requirements Specification PWBS Page 6
2. Overall Description
2.1 Product Perspective
The product being developed is for a new system which is going to be used for prepayment of water
bills. This product works with other software products like an embedded operating system, databases
that store user’s information, this implies that the scope of this project encompasses both the server
and the client-side functionalities. Therefore, both aspects are covered in detail within this document.
Below is the block diagram of how the system is going to flow and its components’ descriptions:
Conceptual model
Flow Sensor:
In this pre-paid water billing system, we shall use a turbine based flow sensor that gives pulses directly
proportional to the flow of volume through it. It shall measure flow rate by using the natural kinetic
energy of the flow as it passes through the angled blades of the turbine rotor. This causes the turbine
to spin and as the blades pass by a close prepositioned magnetic (or other technology) “pick up” coil.
The resulting interruption of the coils magnetic field by each blade results in a pulse being produced.
The flow sensor gives 300 pulses per cubic litres of the liquid.
Software Requirements Specification PWBS Page 7
Solenoid Valve:
A solenoid valve is an electromechanically operated valve. The valve is controlled by an electric
current through a solenoid: in the case of a two-port valve the flow is switched on or off;
Solenoids offer fast and safe switching, high reliability, long service life, good medium compatibility
of the materials used, low control power and compact design.
A solenoid valve has two main parts: the solenoid and the valve. The solenoid converts electrical
energy into mechanical energy which, in turn, opens or closes the valve mechanically. A solenoid
valve employs magnets and electrical current to effect operations at expense of very little electrical
power. When electrical current is applied to coil, based on polarity of magnet and direction of current
flow valve is latched or delatched. When current polarity is reversed, valve latches if in delatched
position and vice versa.
Atmega328P Microcontroller:
The ATmega328P provides the following features: 32Kbytes of In-System Programmable Flash with
Read-While-Write capabilities, 1Kbytes EEPROM, 2 Kbyte SRAM, 23 general purpose I/O lines, 32
x 8 general purpose working registers, a JTAG interface for Boundary-scan, On-chip Debugging
support and programming, a complete On-chip
LCD controller with internal step-up voltage, three flexible Timer/Counters with compare modes,
internal and external interrupts, a serial programmable USART, Universal Serial Interface with Start
Condition Detector, an 8-channel, 10-bit ADC, a programmable Watchdog Timer with internal
Oscillator, an SPI serial port, and five software selectable power saving modes. The Idle mode stops
the CPU while allowing the SRAM; Timer/Counters, SPI port, and interrupt system to continue
functioning. The Power-down mode saves the register contents but freezes the Oscillator, disabling
all other chip functions until the next interrupt or hardware reset. In power-save mode, the
asynchronous timer & the LCD controller continues to run, allowing the user to maintain a timer base
and operate the LCD display while the rest of the device is sleeping.
Software Requirements Specification PWBS Page 8
GSM (Global System for Mobile Communications):
GSM is a standard set developed by the European Telecommunications Standards Institute (ETSI) to
describe technologies for second generation (2G) digital cellular networks. SMS is a text messaging
service component of mobile communication systems, using standardized communications protocols
that allow the exchange of short text messages between fixed line or mobile phone devices. SMS as
used on modern handsets originated from radio telegraphy in radio memo pagers using standardized
phone protocols and later defined as part of the Global System for Mobile Communications (GSM)
series of standards in 1985 as a means of sending messages of up to 160 characters to and from GSM
mobile handsets. SMS messages are mobile-to-mobile text messages though the standard supports
other types of broadcast messaging as well.
Database:
This shall be used to keep users details such as their information, token numbers and other information
as shall be determined during development.
2.2 Product Functions
User registration will appear once (the first time the web application is run) and gets a
random number where payments are made and where the token numbers will be submitted
to.
The web application shall allow the user to register with the systems database.
Appear after any significant event is about to occur for example if the number of units on
the water meter are about to be depleted, then these notifications come, or even when the
customer subscribes for the water, he/she receives a notification of payment and how much
units are available for consumption.
Administrator can broadcast messages to customers regarding their respective accounts.
The system shall reduce wastage of fresh water.
The system shall compel every customer to pay for the exact amount of water used or
wasted.
The system shall make every customer a self-interested guardian of the water supply.
Software Requirements Specification PWBS Page 9
The system shall prevent water shortage during dry seasons.
With this system still, a customer shall be in position to consume only what he/she has
paid for. The prepayment meter will be counting downwards until when all that the
customer has paid for has been used up. This means that a customer will be debt free by
the company at any time because you pay for what you consume earlier on.
2.3 User Classes and Characteristics
2.3.1 Customer:
Remote customers most frequently use the embedded system for accessing the water for consumption
and also the web application for subscription and maybe follow up on their accounts. The customers
are not expected to have a high educational and proficiency level or technical expertise.
2.3.2 DBA:
The DBA is expected to have a field appropriate college degree and experience of at least 2 years as
a DBA and an additional 5 years in the IT field. He/ She has the privilege to update information in
the database and technical expertise in database management. The DBA does not directly interact
with the PWBS.
2.3.3 Developers:
The developers are expected to have a field appropriate college degree and experience in
programming with languages such as python, PHP, HTML, CSS and C. These will be in position to
maintain the system as well as scale the system to the needed level of functionality.
2.4 Operating Environment
The system shall operate with the following software components and applications:
The embedded system being developed shall have entirely our new structure, it shall work according
to pre-specified instructions and it shall be developed using C programming language.
The server side will be designed using languages that include Java, HTML, PHP, JavaScript, and
MySQL, therefore anyone with access to internet can be able to subscribe for the water using his/her
preferred browser.
Then the user will be able to view most of the details on the LCD screen of the embedded system.
Software Requirements Specification PWBS Page 10
2.5 Design and Implementation Constraints
The Internet connection shall be a constraint for the web system. Since the application fetches
data from the database over the Internet, it is crucial that there is an Internet connection for
the system to function.
There shall also be use of a GSM which shall be the only means of communication between
these two systems (web system and embedded system). Without this GSM, the two systems
seize to communicate. Hence a constraint.
The programming language shall be C or C++ for the embedded system then programming
language shall be MySQL for the database part and then other languages such as PHP,
JavaScript and CSS for the web system.
The customer must have an account with us in order to access the services and the prepayment
embedded water system must be installed at his/her home to be able to use it.
The systems must keep logs of events and data that can be reviewed in the case of failure.
The system must be installed specifically where there is access to tapped water.
There must be a database hosted somewhere where information is picked and cross checked
for purposes of security and access of token numbers.
2.6 User Documentation
2.6.1 On-line Help
There will be a help button on the system which will enable users to post all their concerns.
This will be coupled with a number of other questions that we may redeem relevant and we
hope the user must have prior to the usage of the system
There shall be contact information posted in our “about” page. The user shall be able to contact
the developers regarding any issues they encounter.
2.6.2 User manuals
User manuals illustrating how the embedded system as well as the web system that is going
to be used will be used. This will include how subscription and usage will be done.
Software Requirements Specification PWBS Page 11
2.7 Assumptions and Dependencies
Dependencies
The embedded system that we shall build shall depend on the power supply for its performance.
The two systems shall depend on the GSM module to provide communication between them.
Access of water shall depend on whether the user has paid for what he/she wishes to consume.
Assumptions
The on-line system shall be used with the assumption that it is well understood by the users
and that it provides easy means for the users to pay and acquire the token numbers as soon as
they pay for what they opt to use.
The whole system setup shall be used with the assumption that the GSM module that provides
communication between the two systems works efficiently and effectively.
It should be assumed that the users shall not tamper or misuse the system in any way that
disorients its proper functionality.
It shall also be assumed that the embedded system shall be powered at all times or for a very
long period of time like 6 months and above.
Software Requirements Specification PWBS Page 12
3. External Interface Requirements
3.1 User Interfaces
The interface shall meet the following requirements to conform to the users‟ needs:
It will be simple and easy to understand.
Controls which allow the user to interact with the web application will be clear and imply
their functionality within the application.
3.1.1 User view-create account
This interface shall enable a user to input his/her details to create an account and be registered with
the system. These details shall be used by the system during the login sessions
3.1.2 User view-login
This is the interface that shall allow a user to access his/her dashboard. It can also allow a user
to create an account if they do not have one, and also verifies if a user has an account with the
system.
Software Requirements Specification PWBS Page 13
3.1.3 User Dashboard
After accessing the system, this is the interface that shall be displayed to a user. This interface
shall enable a customer subscribe for a token depending on how much he/she wishes to
consume, he/she shall also be able to view the tokens used and statements of account
3.2 Hardware Interfaces
This embedded system shall have two hardware interfaces which include:
3.2.1 Keypad
This interface shall be used to input token numbers as they are received from the web system.
3.2.2 LCD screen
This interface shall enable the user to view units of water he/she is left with, token numbers currently
in use as they input them, and rate at which water flows.
3.3 Software Interfaces
Throughout the development of this project we shall use proteus and AVR studio to write, assemble,
execute, and debug programs. Proteus is a virtual prototyping design framework. It is a
microcontroller’s design tool that combines in a seamless environment: proteus provides a true virtual
microcontrollers design lab, in which the hardware and the software are co-simulated.
Software Requirements Specification PWBS Page 14
The web application/system shall be designed using languages like Java, PHP, JavaScript, HTML and
the source code shall be written using any editor that we shall prefer.
3.4 Communications Interfaces
Communication between the two systems shall be done using the GSM module, which uses
SMS. This shall provide communication whereby it shall be in position to send messages
between the embedded system and the web system at the user’s side. These simple messages
shall include token numbers, reminders of account balances among others.
HTTP/HTTPS protocols shall also enable users to view only content that is being provided by
the web system.
Software Requirements Specification PWBS Page 15
4. System Features
The system shall be composed of a web based and an embedded system. The web based system shall
consist of the following features:
Create account
Log in/log out
Token generation
Subscribe for token
Analysis
The embedded system contains the following features:
LCD display
Keypad
Flow sensor
Solenoid valve
Microcontroller
GSM module
4.1 Create Account
4.1.1 Description and Priority
This feature enables the creation of the account that shall be used by the customer to interact
with the system. Once a user has created an account, he is able to access the system. This
feature is of high priority.
4.1.2 Stimulus/Response Sequences
When a user creates an account he receives a notification on whether the account has been
successfully created or not.
4.1.3 Functional Requirements
FR-1: The system should enable a user to create an account.
Software Requirements Specification PWBS Page 16
4.2 Login/ Logout
4.2.1 Description and Priority.
This feature ensures that only registered and valid users access the system. This is of high
priority because it ensures both safety and security.
4.2.2 Stimulus/ response sequences
The users with incorrect details will not be able to access the system.
4.2.3 Functional requirements
FR-1: The system shall enable registered users to login.
FR-2: The system shall deny access of users who do not have accounts created with it.
4.3 Generate token
4.3.1 Description and Priority.
This feature shall enable the system to come up with tokens that the customers shall have
subscribed for. This is also of high priority because they are these tokens that users use to get
their desirable units of water.
4.3.2 Stimulus/ response sequences
When a customer subscribes for a token, the system should be able to generate a token for that
respective customer for the units of water subscribed for
4.3.3 Functional requirements
FR-1: The system shall generate a token that a given customer has subscribed for.
FR-2: The system shall verify that the token generated is random and that it corresponds to the
amount of water subscribed for.
Software Requirements Specification PWBS Page 17
4.4 Subscribe for token
4.4.1 Description and Priority.
This shall enable the customer to subscribe and make payment for a token corresponding to a
given amount of water. It is of high priority because a customer can only obtain a token after
subscribing and paying for it.
4.4.2 Stimulus/ response sequences
When a customer wants to obtain given litres of water, he first has to subscribe and pay for a
token that corresponds to the litres of water. After this subscription, the token is sent to the
customer who is able to view the token.
4.4.3 Functional requirements
FR-1: The system shall enable the customer to subscribe for a given token corresponding to
the litres of water they want.
FR-2: The system shall enable the customer to pay for the token they subscribe for.
4.5 View analysis
4.5.1 Description and Priority.
The system shall enable the customer to view their consumption rate, token numbers they have
used, how they have used them, and the units of water they are remaining with. This is of
medium priority because a customer may decide not to follow up these details.
The system shall also enable the administrators to view the different customers and how they
consume their units of water, their tokens and also provide customer support.
4.5.2 Stimulus/ response sequences
Registered customers who have previously subscribed for tokens should be able to view the
analysis. These customers should be able to view their consumption and payments details.
4.5.3 Functional requirements
FR-1: The system shall enable the customer to view their consumption and payment details.
Software Requirements Specification PWBS Page 18
4.6 Keypad
4.6.1 Description and Priority.
This feature shall be consisting of a simple numeric keypad for entering the token numbers that
stand for the amount of water to be consumed. This feature is of high priority since it is
necessary for the entry of a token number that thereafter provides given amounts of water.
4.6.2 Stimulus/ response sequences
The token number is entered by the customer into the keypad and the corresponding units of
litres of water obtained is displayed on the LCD screen.
4.6.3 Functional requirements
FR-1: The system shall enable the customer enter his token number into the keypad.
FR-2: The system shall enable the customer to view the units of water on the LCD screen.
4.7 LCD display
4.7.1 Description and Priority
LCD screen that will display numbers as you enter them and the number of litres a customer
obtains once a valid token has been successfully entered. This feature is of high priority
4.7.2 Stimulus/ response sequences
The token number is entered by the customer into the keypad and the corresponding units of
litres of water obtained is displayed on the LCD screen.
4.7.3 Functional requirements
FR-1: The system shall enable the customer to view the units of water obtained on the LCD
screen.
4.8 Flow sensor
4.8.1 Description and Priority
This feature measures the rate at which water flows.
Software Requirements Specification PWBS Page 19
4.8.2 Stimulus/ response sequences
When the water flows through the pipe, the flow sensor measures the rate at which it flows in
order to keep track of the amount of water being consumed.
4.8.3 Functional requirements
FR-1: The system shall enable to keep track of the rate of water flowing through the water
pipes.
4.9 Solenoid valve
4.9.1 Description and Priority.
This feature works in a way that once the litres of water that a given customer paid for are
finished, the valve closes and then opens once the customer pays and obtains another valid
token and corresponding litres of water for that token.
4.9.2 Stimulus/ response sequences
Once the units of water are finished, the solenoid valve responds by closing and when the
customer pays and obtains other units, it responds by opening.
4.9.3 Functional requirements
FR-1: The system shall enable the water flow to stop or continue depending on whether a
customer has got units of water or not.
4.10 Microcontroller
4.10.1 Description and Priority.
This shall be the brain of the embedded system; it shall control system inputs as well as the
outputs. The microcontroller shall provide the communication between the LCD screen, the
power source, the valve and the sensor. In other words, this controls the entire embedded
system. It is of the utmost importance because it is what the entire embedded system shall
depend on to control the activities of the prepaid water billing system.
Software Requirements Specification PWBS Page 20
4.10.2 Stimulus/ response sequences
It controls the entire operation of the system because it contains the operating system of the
system
4.10.3 Functional requirements
FR-1: It shall allow water to be issued with respect to requested units
FR-2: It shall control the on and/or off of the valve when the tap is open
FR-3: It shall also enable the LCD to display the preferred measurements of the embedded
system for example; units subscribed for, units left, and units that have been used.
4.11 GSM module
4.11.1 Description and Priority.
GSM provides SMS which is a text messaging service component of mobile communication
systems, using standardized communications protocols that allow the exchange of short text
messages between fixed line or mobile phone devices. SMS as used on modern handsets
originated from radio telegraphy in radio memo pagers using standardized phone protocols and
later defined as part of the Global System for Mobile Communications (GSM) series of
standards in 1985 as a means of sending messages of up to 160 characters to and from GSM
mobile handsets. SMS messages are mobile-to-mobile text messages through the standard
supports other types of broadcast messaging as well.
4.11.2 Stimulus/ response sequences
There shall be communication between the web system and the embedded system through this
module because the tokens shall be sent respectively through this module to the two systems
4.11.3 Functional requirements
FR-1: It shall provide communication between the two systems
Software Requirements Specification PWBS Page 21
Use case diagram for the system
Figure 1: The prepaid water billing system use case diagram.
Name of use case: Create Account
Actor: Customer
Description: Describes the process of creating an account by a customer.
Successful
completion:
1. User accesses the system create account interface.
2. User enters his first name, telephone contact, and password then confirms it.
3. The user then clicks on the create account button and then receives a message that the
account has been created.
Alternative: 1. User accesses the system create account interface.
2. User enters his first name, telephone contact, and password then confirms it.
3. The system responds with an error message that ‘your passwords do not match.’
Precondition: User has accessed the system website to create an account.
Post condition: User has been able to create an account and can now use these details to log into the system.
Assumptions: None.
Software Requirements Specification PWBS Page 22
Name of use case: Login
Actor: Customer
Description: Describes the process of a customer logging into the system.
Successful
completion:
1. User accesses the login interface.
2. The user enters his telephone number, password and then clicks on the sign in button.
3. If the details are correct, user receives a login success message and views the dash board.
Alternative: 1. User accesses the login interface.
2. The user enters his telephone number, password and then clicks on the sign in button.
3. If the details are incorrect, the user receives a login error message.
Precondition: User has created an account and is registered with the system, if not does so.
Post condition: User has been able to log into the system and now accesses the system dashboard.
Assumptions: None.
Name of use case: Buy token
Actor: Customer
Description: Describes the process of a customer purchasing a token using the system.
Successful
completion:
1. User subscribes for a token by entering the number of litres of water he/she wishes
to obtain.
2. User then makes a payment for the stated litres of water.
3. The user then receives a confirmation of payment plus the token number
corresponding to a given number of water units.
Alternative: 1. User subscribes for a token by entering the number of litres of water he/she wishes
to obtain.
2. User then makes a payment for the stated litres of water.
3. The user receives a message informing him or her that the amount entered is less for
the stated litres of water.
Precondition: User has successfully logged into the system.
Post condition: User has paid and obtained a token number corresponding to certain units of water.
Assumptions: None.
Software Requirements Specification PWBS Page 23
5. Other Nonfunctional Requirements
5.1 Performance Requirements
Checking the fact that the system must perform as what every user expects. So in every action-
response of the system, there are no immediate delays. In case of obtaining token numbers, of popping
error messages and saving the settings or sessions there is delay much below 2 seconds.
Multiple users
The web system shall support the use of multiple users at same time.
Response Time:
The response time should not be more than 1 minute if user have a proper internet connection.
Fault Tolerance:
The fault tolerance of the system should be very good. If the system loses the connection to
the Internet or the system gets some strange input, the user should be informed.
5.2 Safety Requirements
Consistency: checking the fact that all sensors and solenoid valves must function accordingly
and work hand in hand, so there should be appropriate control of water flow.
User needs to sign in with their account to prove their identity (customer) before using the
system
5.3 Security Requirements
This program involves the use of unique random tokens so as to get the units in cubic meters
so as to get the water that he or she paid for.
A token number cannot be entered or punched in more than once into the system as this results
into an error message.
A user must be registered into the system so as to login into the system.
Software Requirements Specification PWBS Page 24
5.4 Software Quality Attributes
Availability: Checking that the system always has something to function and always pop up
error messages in case of component failure. In that case the error messages appear when
something goes wrong so to prevail availability problems.
Usability: Checking that the system is easy to handle and navigates in the most expected way
with no delays. In that case the system program reacts accordingly and transverses quickly
between its states.
Functionality: Checking that the system functions according.
Reliability: There is an assumption that the system shall be available 24/7 given that the
network is on.
Maintainability: Maintaining the system would not be complicated due to the fact that the
documentation would be available and the costs too.
Testability: Test environments should be built for the system to allow testing of the system’s
different functions.
5.5 Business Rules
In order for a customer to gain access into the system, he or she should have logged in and be
registered.
For a customer to have water flow, that customer should have paid for water units in cubic
meters and punched in the valid token into the system.
For the solenoid valve to close, the sensor should detect that the units on the meter read 0.0.
For the customer to obtain the token number, the customer must have paid for water units not
less than an amount of 3000shs.
Software Requirements Specification PWBS Page 25
6. Other Requirements
These shall be determined as development proceeds
Appendix A: Glossary
Abbreviations Abbreviation Meaning
SRS Software Requirement Specifications
HTML Hyper Text Markup language
FR Functional Requirement
PWBS
Prepaid water Billing system
PHP Prehyper processor language
API Application programming Interface
CSS Cascading style sheet
LCD Liquid Crystal Display
GSM Global System for communication
SMS Short message service