ieee software requirements specification template · 2018-06-07 · 14, december 2017. software...

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.2 Stimulus/ response sequences .................................................................................... 16

4.3.3 Functional requirements ........................................................................................... 16

4.4 Subscribe for token......................................................................................................... 17



4.4.3 Functional requirements ........................................................................................ 17

4.5 View analysis.................................................................................................................. 17



4.5.3 Functional requirements ....................................................................................... 17

4.6 Keypad ........................................................................................................................... 18


4.6.2 Stimulus/ response sequences ................................................................................ 18


4.7 LCD display ................................................................................................................... 18

4.7.1 Description and Priority ....................................................................................... 18



4.8 Flow sensor .................................................................................................................... 18

4.8.1 Description and Priority ....................................................................................... 18



4.9 Solenoid valve ................................................................................................................ 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.3 Functional requirements.......................................................................................... 20

4.11 GSM module .................................................................................................................. 20

4.11.1 Description and Priority. ......................................................................................... 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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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


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.


4.4 Subscribe for token


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.


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.


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


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.


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.


FR-1: The system shall enable the customer to view their consumption and payment details.


4.6 Keypad


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.


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.


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


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


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.


FR-1: The system shall enable the customer to view the units of water obtained on the LCD

screen.

4.8 Flow sensor


This feature measures the rate at which water flows.



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.


FR-1: The system shall enable to keep track of the rate of water flowing through the water

pipes.

4.9 Solenoid valve


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.


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.


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


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.



It controls the entire operation of the system because it contains the operating system of the

system


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


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.


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


FR-1: It shall provide communication between the two systems


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.


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.


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.


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.


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

ieee software requirements specification template · 2018-06-07 · 14, december 2017. software...

Documents