Advertisement SRS1705379476 (1)

Birth and Death Registration System Standards

Advertisement ModuleAdvertisement Module

eGovernments Foundation

www.egovernments.org

Copyright © 2015 eGovernments Foundation, All Rights Reserved.

Copyright © 2004 eGovernments Foundation All Rights Reserved. Page 1

System Requirement Specifications

Document Version History

Version Date Author Comments

1.0 07/08/2015 Satish Initial Draft

Legal Disclaimer

eGovernments Foundation its members, officers, directors, employees, or agents shall not be liable for any injury, loss, damages, financial or otherwise, arising from, related to, or caused by the use of this document or the specifications herein, as well as associated guidelines and schemas. The use of said specifications shall constitute your express consent to the foregoing exculpation.

Copyright

eGovernments Foundation. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher.

Trademarks

eGovernments Foundation and eGovernments Foundation logo are trademarks or registered trademarks of "eGovernments Foundation," a non-profit organization. All other product names and company logos mentioned herein are the trademarks of their respective owners. In the best effort, all terms mentioned in this document that are known to be trademarks or registered trademarks have been appropriately recognized in the first occurrence of the term.

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 2

System Requirement Specifications

Table of Contents1 INTRODUCTION...........................................................................................................4

1.1 PURPOSE............................................................................................................................... 41.2 SCOPE................................................................................................................................... 41.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS........................................................................41.4 REFERENCES......................................................................................................................... 41.5 OVERVIEW............................................................................................................................. 5

2 OVERALL DESCRIPTION............................................................................6

2.1 PRODUCT PERSPECTIVE..........................................................................................................62.2 PRODUCT FUNCTIONS.............................................................................................................62.3 USER CHARACTERISTICS.........................................................................................................72.4 CONSTRAINTS........................................................................................................................ 72.5 ASSUMPTIONS AND DEPENDENCIES..........................................................................................72.6 APPORTIONING OF REQUIREMENTS..........................................................................................7

3 SPECIFIC REQUIREMENTS.........................................................................8

3.1 EXTERNAL/OTHER MODULE INTERFACE REQUIREMENTS...........................................................8

4 FUNCTIONAL REQUIREMENTS...................................................................9

4.1 CREATE HOARDING................................................................................................................94.2 HOARDING TYPE...................................................................................................................104.3 MASTER FOR HOARDING SIZE...............................................................................................104.4 MODIFY HOARDING...............................................................................................................114.5 CREATE HOARDING AGREEMENT...........................................................................................114.6 TENDER DETAILS AGREEMENT MASTER.................................................................................134.7 Rent Collection for Hoarding...............................................................................................14

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 3

System Requirement Specifications

1 Introduction

1.1 Purpose

The purpose of this document is to give a detailed description of the requirements for the “Advertisement Tax Revenue” module. The document will illustrate the purpose and complete declaration for the module development. It will also explain system constraints, interface and interactions with other external applications and integrated modules. This document is primarily intended to be proposed to a customer for its approval and a reference for developing the first version of the system for the development team.

1.2 Scope

The Advertisement tax module is an integrated module in the ERP which addresses the problem associated with manual maintenance of information related to tax and renewal fees collection. The application computerizes the Advertisement taxes process by maintaining the master data, agreement details and Fees/Tax collection information. It generates the demand automatically every year and sends the data to collection section for collecting the fees.

1.3 Definitions, acronyms, and abbreviations

Term DefinitionULB Urban Local BodyDCB Demand and Collection BalanceAdministrative Boundaries

The city is broken down into hierarchical boundaries like Zone and Ward for administrative convenience.

Location/Revenue Boundaries

The City consists of various Area, Location and Streets which result in the Postal address of the property. They are also hierarchical and the citizen uses them in his day to day life.

TPBO Town planning Building Overseer

1.4 References

[1] IEEE Software Engineering Standards Committee, “IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications”, October 20, 1998. [2] Feldt R,”re_lecture5b_100914”, unpublished. 3 [3] Davis M A, “Just Enough Requirements Management: Where Software Development Meets Marketing”, New York, Dorset House Publishing, 2005. [4] Karlsson J, “A Cost-Value Approach for Prioritizing Requirements”, Norges Teknisk-Naturvitenskapelige Uni. 1997

1.5 Overview

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 4

System Requirement Specifications

The remainder of this document includes two chapters and appendixes. The second one provides an overview of the system functionality and system interaction with other systems. This chapter also introduces different types of stakeholders and their interaction with the system. Further, the chapter also mentions the system constraints and assumptions about the product.

The third chapter provides the requirements specification in detailed terms and a description of the different system interfaces. Different specification techniques are used in order to specify the requirements more precisely for different audiences.

The Requirement traceability in the end of the document includes all the discussion point raised in the committee meeting and conformation of the same.

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 5

System Requirement Specifications

2 Overall Description

This section will give an overview of the whole system. The system will be explained in its context to show how the system interacts with other systems and introduce the basic functionality of it. It will also describe what type of stakeholders that will use the system and what functionality is available for each type. At last, the constraints and assumptions for the system will be presented.

2.1 Product perspective

The Advertisement Tax/Rent application is an integrated module and will consist of functionalities to cater to the requirements of maintaining the Advertisement entity master, raising the demand and collecting the tax. The application computerizes the Advertisement taxes process by maintaining the master data, agreement details and Fees/Tax collection information. It generates the demand automatically every year and sends the data to collection section for collecting the fees.

2.2 Product functions

Advertisement tax is collected from the Advertiser/ Agency for the display of Advertisements within the ULB limits. Advertisements are of different types like hoardings, wall paintings, balloons, slides etc. The Revenue section of the ULB administers the Advertisement taxes and the major processes related to the advertisement tax and collecting of license fees and Taxes from the Agencies.

An agency or advertisers registers with an ULB by paying the necessary fees and makes an agreement with the ULB for advertising. The Rent/Fees details are captured as part of the agreement. Simultaneously the Demand is generated and collected. Going forward, the demand is automatically generated at the start of the financial year and collection is made accordingly. The official gets the detailed report of all the renewal pending and Fees due from agencies. This helps the management plan their collections effectively.

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 6

System Requirement Specifications

2.3 User characteristics

There are various types of users interact with the application within ULB and outside ULB. The possible types of user are portrayed in the below picture.

2.4 Constraints

The application is constrained by the explorer used to access the system. The version changes may affect the screen level functioning. The Internet connection is also a constraint for the application. Since the application fetches data from the database over the Internet, it is crucial that there is an Internet connection for the application to function. The application access will be constrained by the capacity of the database. Since the database is accessed by various stake holders at different levels, it may be forced to queue incoming requests and therefor increase the time it takes to fetch data.

The Agreement and tendering process will be outside the scope of Advertisement module. The collection has to be made in full in case of agency wise collection. i.e the part payment will not be allowed.

2.5 Assumptions and dependencies

It is assumed that the collection is made from the system for the demand raised and financial voucher is generated for both demand accrual entry and collection.

The tendering details are maintained for MIS information and for such agreements, there will be only the demand and there is no collections made.

2.6 Apportioning of requirements

In the case that the project is delayed, there are some requirements that could be transferred to the next version of the application. Those requirements and changes suggested are to be developed in the next release, see requirements traceability section. This section will be updated based on the discussion made in the committee meeting.

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 7

System Requirement Specifications

3 Specific requirements

This section contains all of the functional and quality requirements of the system. It gives a detailed description of the system and all its features.

3.1 External/Other module interface Requirements

This section provides a detailed description of all inputs into and outputs from the system. It also gives an idea of the modules integrated. The prototypes of various screens are detailed in the functional requirement section.

3.1.1 Integration with other modules

Employee Information System: Users of Advertisement System shall be the Agency and employees of the ULB. They will be managed by the Employee Information System.

eGov Infrastructure: The Administrative Boundaries (Zone, Ward) and user roles creations will be managed by the eGov Infrastructure.

eGov Collection: The demand generated for Fees and Tax from Advertisement module will be fetched through collections module for creating the Receipts.

Financial Accounting: The changes in Demand and license fee will be reflected in the accrual entries in Financial Accounting System.

Property Tax: The hoarding master is linked to property tax to fetch detail about the property and in future could be used to analyse the data of actual commercial tax to be paid based on the data.

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 8

System Requirement Specifications

4 Functional Requirements

4.1 Create Hoarding

Create Hoarding or the advertisement structure is the master entry screen for the entity. Once the master data is entered, the collection and demand there on can be generated.

The hoarding details are distinctively identified by a unique number which is of the following format HO/<Zone Num>/<Ward Num>/<Running Sequence>

4.1.1 Data Elements

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 9

System Requirement Specifications

Assetcode Textbox NA Read Only. Land asset codeZone Dropdown NA Read Only. Auto-populated based on asset

code selectionWard Dropdown NA Read Only. Auto-populated based on asset

code selectionArea Dropdown NA Read Only. Auto-populated based on asset

code selectionLocality Dropdown NA Read Only. Auto-populated based on asset

code selectionStreet name Dropdown NA Read Only. Auto-populated based on asset

code selectionHoarding DetailsOld Hoarding No. Textbox N Old hoarding numberHoarding Type Dropdown Y Hoarding type displayed from masterHoarding Size Dropdown Y Hoarding size displayed from masterAttach Document N Attach document (if any)Remarks Textbox N Comments (if any)

4.2 Hoarding TypeHoarding Type is the screen where user creates the hoarding types based on his requirements. It’s a master screen in which hoarding types are defined that is used for creating the hoarding details.

4.2.1 Data Elements

Field Field Type Required CommentsId Textbox Y Unique Id of hoarding typeHoarding Type Textbox Y Unique Name of the hoarding typeDescription Textbox N Remarks (if any)

4.3 Master for Hoarding SizeIn the hoarding size, user is allowed to enter size of the hoarding. This is a master screen, which consists of length and breadth of hoarding.

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 10

System Requirement Specifications

4.3.1 Data Elements

Field Field Type Required CommentsId Textbox Y Unique Id of hoarding typeHoarding Type Dropdown Y Hoarding type from masterLength Textbox Y Hoarding lengthBreadth Textbox Y Hoarding breathWidth Textbox N Width length of hoarding

4.4 Modify HoardingThis screen will be used to modify the existing hoarding details available in the system. The screen will consist of all the existing available information about the hoarding. User will be allowed to modify the hoarding details, if agreement is not available against the hoarding. In this screen user is allowed to modify all the existing details displayed as entered at the time of create hoarding.

4.5 Create Hoarding AgreementA Hoarding Agreement is created based on the allotment. Here the allotment is done either by First Finders policy or by Tender Process. The hoarding agreement is signed between ULB and the allottee based on allotment. The agreement is signed between the ULB and Allottee for a fixed period of 3 years. After the expiry of the leased period, the hoarding license is retendered as per the tendering process.

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 11

System Requirement Specifications

4.5.1 Data Elements

Field Field Type Required CommentsHoarding Id Textbox NA Read Only. Hoarding numberAsset Code Textbox NA Read Only. Land asset codeHoarding Address Textbox NA Read Only. Displayed based on the

hoarding number selected

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 12

System Requirement Specifications

Field Field Type RequiredComments

Hoarding Type Dropdown NA Read Only. Hoarding type displayed based on hoarding number selection

Length Textbox NA Read Only. Length of the hoardingBreadth Textbox NA Read Only. Breadth of the hoardingWidth Textbox NA Read Only. Width of the hoardingAllotment DetailsAllottee Name Textbox Y Name of the allotteeAllottee Address Textbox Y Address of the allotteeNature of Allotment Dropdown Y The dropdown consists of

a. Tender Processb. First Finders Policy

Contact No. Textbox N Contact number of the allotteeAgreement DetailsNominee Name Textbox N Name of the nomineeNominee Name Textbox N Address of the nomineeAgreement No. Textbox Y Agreement numberAgreement Date Textbox Y Agreement dateApproval Authority Textbox Y Approval authority nameOrder No. Textbox Y Order numberOrder Date Textbox Y Order dateDate of Commencement Textbox Y Date of commencement of agreementDate of Expiry Textbox Y Date of expiry of agreementDeposit Amount (Rs.) Textbox Y Deposit amount collected at the time of

AllotmentRent Amount (Rs.) Textbox Y Monthly rent amount of HoardingExtra Charges (Rs.) Textbox N Extra charges collected for allotmentDiscount Amount (Rs.) Textbox N Discount amount (if any)Total Amount (Rs.) Textbox NA Read Only. Total Rent AmountDocument Attachment N Attach document copy (if any)Remarks Textbox N Comments (if any)

If the ‘Nature of Allotment’ is ‘Tender Process’, then include these details along with the above mentioned agreement details.

Field Field Type Required Comments

Agreement DetailsTender Auction No. Textbox Y Auction number of tenderTender No. Textbox Y Tender number of hoardingTender Date Textbox Y Tender Date

4.6 Tender Details Agreement Master

The tender details pertaining to tax collection outsourcing is recorded in this master. The agency who is given the tender can be handling the limits either at the city level or at any other boundary level.

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 13

System Requirement Specifications

Advertisement Tax Tender Details

Agency

Boundary Type Boundary

Effective Year Years Of Validity

Number Of Ads Amount

Field Field Type Required CommentsAgency Text Field Y The Name of the agency to be captured in

this fieldBoundary Type Drop Down Y The Boundary type pertaining to the

agency situated should be selected in this field.

Boundary Drop Down Y The boundary type that is applicable to the agency to be selected.

Effective year Drop Down Y The year should be selected from the drop down.

Years of Validity Text Field Y Years of validity should be captured in this field.

Number of ads Text Field Y Number of ads in number should be entered here in this field.

Amount Text Field Y The amount in rupees should be entered here in this field.

4.7 Rent Collection for Hoarding

Rent is collected for all the hoardings which is been leased out by the ULB to the allottee. The rent is collected on period basis based on the agreement signed as per the allotment done.

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 14

Ward

2015

Submit Reset Cancel

System Requirement Specifications

4.7.1 Data Elements

Field Field Type Required CommentsBill Number Textbox NA Unique No. displayed from billing systemAdditional Information Textbox NA Read Only - Module nameConsumer Code Textbox NA Read Only – Hoarding numberPayee Name and Description

Textbox NA Allottee name

Payment Details – User is allowed to enter multiple rows to enter cheque detailsTotal amount to be received

Textbox NA Read Only - Total Rent amount to be paid

Total amount received Textbox NA Read Only - Rent amount paid against the total due amount

Mode of Payment Radio Button Y Payment mode options are a. Chequeb. Demand Draft

Cheque / DD Checkbox Y Payment instrument detail – cheque or demand draft

DD / Cheque Number Textbox Y Cheque or demand draft instrument no.DD/Cheque Date Textbox Y Cheque or DD instrument dateBank Name Textbox Y Bank name of the instrument issuedBranch name Textbox N Branch name of the instrument issuedAmount Textbox Y Total amount paid against the demand duePaid By Textbox Y Payee name of the rent amountCounter and Collection DetailsCounter Operator Textbox NA Read Only. Counter operator name who

receives the payment Service Textbox NA Read Only. Name of the service against

which the payment is collected (means module name)

Copyright © 2015 eGovernments Foundation All Rights Reserved. Page 15