Tradeable Energy Quotas

Size: px

Start display at page:

Download "Tradeable Energy Quotas"

Georgia Webb
5 years ago
Views:

2 Page ii Table of Contents 1. Introduction Purpose Document Conventions Intended Audience and Reading Suggestions Product Scope References Overall Description Product Perspective External Interface Requirements User Interfaces System Features Other Nonfunctional Requirements Open Issues Open Issues Major Risks... 6

3 Page 1 1. Introduction 1.1 Purpose This document specifies the requirements for the Tradeable Energy Quotas named TEQs. This provides developers the required information for designing/implementing the system and maintaining it through testing and validation. 1.2 Document Conventions Each requirement has a priority level depending on how essential it is to the end system. This is either essential, important or desirable. Essential requirements are non negotiable key elements of the system. Important indicates a requirement that should be implemented if the system is to be created as initially intended. Desirable indicates a requirement that would be useful to have in the system. 1.3 Intended Audience and Reading Suggestions Developers, project managers and the clients of this project may find this document useful. This document contains requirements, issues and an appendix containing models developed. 1.4 Product Scope The purpose of the project is to develop the central registration system to be used as a part of the Tradeable Energy Quotas scheme. The system will be responsible for the creation and maintenance of carbon credit accounts for all energy users within the UK. The system will deal with carbon credit accounts for both individuals and businesses. An interface to the system will be provided such that third party institutions and organizations will be able to access the relevant functionality and data as necessary. The context diagram in the appendix defines the scope for the Registrar system which is to be developed for the UK government, the central registrar system is shown in yellow. The Government Register and Business Register agents were found as a result of the elicitation meeting, these provide the system with the information needed to ensure that all individuals and businesses have a carbon credit account. Tradeable Energy Quotas (TEQs) is a system of rationing energy consumption or emissions per person. Each individual has a set amount of energy that he can consume on a given year. Then by use of a carbon credit card, or by including this in his existing credit card, every time he buys petrol for his car, or pays an electricity bill, units are deducted from his card. If he consumes more units, then he has to buy the extra units from other people. If he has units left he can sell them to other people. 1 1 Tradeable Energy Quotas (TEQ) client brief

4 Page References [Fleming2007] Energy and the Common Purpose, Descending the Energy Staircase with Tradeable Energy Quotas (TEQs), David Fleming, Second Edition, January 2007, gives further information about the systems context 2. Overall Description 2.1 Product Perspective This system is the registrar part of a larger tradeable energy quota system the government wants to implement. 3. External Interface Requirements 3.1 User Interfaces The project just gets the input from the different transactions. They send the same signal. In other words it has a uniform interface and there is no need for a GUI to be implemented. 4. System Features Here are the functional requirements for the system Functional Requirements Add New Citizen This use case allows new citizen to be registered on the system. Inputs and pre-conditions: Verified employee Outputs and post-conditions: New citizen registered on the system Main flow of events 1. The employee selects the insert citizen option. 2. The employee provides the following information about the new citizen

5 Page 3 First Name and Last Name: are the names of the citizen. Account Number: is their assigned account number. This number must be unique. Initial Deposit: is the amount of carbon credit that the customer is opening their account with. Pin Number (with second password field for confirmation). 3. The employee confirms the operation. 4. The entered data is transmitted to the server. 5. The system verifies the entered data. 6. The system saves the new employee's data. Alternative flow 2. Incomplete data entered. 1. Show a message informing the employee of the missing/incorrect data. 5. The employee is already entered. 1. Inform the employee that the new citizen is already entered. 2. Abandon the entry. Functional Requirements Deposit Carbon Credit This use case allows depositing carbon credit to citizen s account. Inputs and pre-conditions: Verified citizen and deposit amount Outputs and post-conditions: Citizen s account is credited by the deposit amount. Main flow of events 1. The employee selects the deposit option. 2. The employee provides the following information about the citizen First Name and Last Name Account Number Amount of carbon credit deposited to the citizen s account 3. The employee confirms the operation. 4. The entered data is transmitted to the server. 5. The system verifies the entered data. 6. The system saves the citizen s new balance. Alternative flow 2. Incomplete data entered. 1. Show a message informing the employee of the missing/incorrect data.

6 Page 4 Functional Requirements Withdraw Carbon Credit This use case allows withdrawal of carbon credit from citizen s account. Inputs and pre-conditions: Verified citizen and withdrawal amount Outputs and post-conditions: Citizen s account is debited by the withdrawal amount. Main flow of events 1. The employee selects the withdraw option. 2. The employee provides the following information about the citizen First Name and Last Name Account Number Amount of carbon credit debited from citizen s account 3. The employee confirms the operation. 4. The entered data is transmitted to the server. 5. The system verifies the entered data. 6. The system saves the citizen s new balance. Alternative flow 2. Incomplete data entered. 1. Show a message informing the employee of the missing/incorrect data. Functional Requirements Check Balance This use case allows citizens to obtain their balance Inputs and pre-conditions: Verified citizen Outputs and post-conditions: The balance to the citizen Main flow of events 1. The citizen provides the following information Account Number Pin Number 2. The entered data is transmitted to the server. 3. The system verifies the entered data. 4. The system returns the citizen s balance

7 Page 5 Alternative flow 1. Incomplete data entered. 1. Show a message informing the citizen of the missing/incorrect data. Functional Requirements Close Account This use case allows the employee to close a citizen's account. Inputs and pre-conditions: Verified citizen Outputs and post-conditions: Account closed. Main flow of events 1. The employee selects the close option. 2. The employee provides the following information about the citizen First Name and Last Name Account Number Reason for closing 3. The employee confirms the operation. 4. The entered data is transmitted to the server. 5. The system verifies the entered data. 6. The system deactivates the account and marks it as closed. Alternative flow 2. Incomplete data entered. 1. Show a message informing the employee of the missing/incorrect data. 5. Other Nonfunctional Requirements Availability Non-Functional Requirements The system should be available 24 hours a day, 7 days a week. The nature of the system being a critical system, the system must stay on at all times. Therefore usage of distributed servers is required.

8 Page 6 Performance The system must be capable to handle 100 simultaneous users. The response time must not exceed 5 seconds. Security The system should use a security protocol when sending data over the internet. To have access to the complaint registration features, access must be allowed by the access control sub-system. Standards The system must be developed according to the standards established by Energy Policy Committee, responsible for the norms and standardization of systems for the government. 6. Open Issues 6.1 Open Issues It is yet unclear how to gather an accurate list of people in a country for the system to allocate the units. The distribution of the points has not yet been properly categorized. Do people below 18 gets point or limited points? Would also the people in retirement home get more or less points? Would disabled people require more points? 6.2 Major Risks Change of government: As this project may be considered as a long term project the decision taken by the current government to realize this project may be repealed if there is a change of government in near future. Thus follows the risk that the project may be cancelled. Lobbyism: This project results in several new restrictions to companies. As the main aim is to reduce the carbon emissions, investments in alternative technologies must be taken by the companies which will lead to short term price increases. Thus we have to expect a large resistance by companies which will certainly try to influence the political decision. Acceptance among population: The reduction of carbon emission involves a change of life style of all citizens. They have to expect a certain restriction of their freedom of choice and increasing

9 Page 7 prizes for most products as the higher energy costs will surely be passed on to the customer. This may affect the acceptance in the population despite the urgent need to face the climate change. 2 Appendix A: Analysis Models Context Diagram 2 Tradeable Energy Quotas (TEQ) client brief

10 Page 8 Use Case Diagram

11 Page 9 Class Diagram