FACULTY OF INFORMATION TECHNOLOGY & MULTIMEDIA COMMUNICATION

JANUARY 2011

CBRE3103

REQUIREMENTS ENGINEERING

MATRICULATION NO IDENTITY CARD NO. TELEPHONE NO. E-MAIL LEARNING CENTRE

: : : : :

860527355618001 860527-35-5618 016-4993296 Tharshini@oum.edu.my Tharshini_nair@yahoo.com MINDEN LEARNING CENTRE

CBRE3103

Question A Requirement Specification for Online Banking System using Volere Template 1. The Purpose of the project 1a. The User Business or Background of the Project Effort CIMB Bank having problems and limitations associated with manual banking procedures complied with the problems associated with the existing application programs even much more in the presence of serious technological advances aimed at improving information system.. The goal of the system we are designing is to create an online banking system for it will be connected to the Bank server database. By using this system, client have the authority to control their finances completely, no longer tied down to managing their money during the hours the bank is open. Furthermore, subject to agreement with the appropriate stakeholders, the system might provide many useful services such as: Users of online banking services can access their account information from anywhere Business people can access their accounts, even when on overseas business trips ability to make bill payments electronically, reduce the flow of human traffic and long queues at banks allowing customers to check balances online, reduce the time wasted in going to banks to stay on queues money is easily transferred from bank to bank, employer to employee, employee to bank, shopper to department store Promote efficient and effective banking for the banks by focusing on those services that still require physical presence at the banking hall.

The reason why the CIMB Bank needs such a system is several and various:

CBRE3103

Would save a huge amount of work to the bank office, with directly consequent economical gain as well as conservation of time; It would provide a more efficient and satisfactory schedule for the client (user); It would provide clear and precise statistical information (such as the users bank statement/history) that would probably be useful for future reference. Reduce the time wasted in going to banks to stay on queues Reduce the flow of human traffic and long queues at banks

1b. Goals of the project The goal of the project is to develop a secured online banking system with the following objectives: A log-in process to guarantee security of the recognition of every single user The creation of a link between the Bank database and Bank employee that comprehend users account in order to login. The display of a detailed list of Account information/Fund Transfer/Bill Payment/Mobile Banking/Prepaid reloads The User will be notify thru mobile for the TARC Number when using bill payments/fund transfer/prepaid reloads and mobile banking as a security thread. Enable the system to allow the user to print and save each transaction. The first advantage will be measured by the customers. The bill payment services is a process that takes a long time and that cannot be undertaken elsewhere than in the selected bank itself. With this system, the user will be able to perform transactions, pay bills and check balances 24 hours a day, 7 days a week. The bank virtually never closes because it is as accessible as user PC or laptop computer. No matter where the user is in the country or in the world, they can visit your online bank and handle money matters. They also can even schedule to pay several payees ahead of time rather than keeping up with paper bills or trying to remember when to visit a payee's web site to make an online payment. With this system user can be comfortable and have peace of mind knowing that they can keep track their self of all the banking issues, but as well it allows for more ease because user never have to worry about rushing out and making it to the bank. 2. The Client, Customer, and Other Stakeholders

CBRE3103

2a. The Client The client, the CIMB Bank, needs this product because the current process is not effective due to customer unable to make payment, fund transfer during public holidays, furthermore customer in an isolated area having impenetrability to come over to the bank. Major problem that are facing are time consumed for the payments/fund transfer and customer service are quite long, makes the customer complicated to handle the current process. It is therefore extremely important that the first impression obtained by the customer reflects the identity of the Bank. Moreover, the part of the bank administration that is concerned with the program wastes a massive amount of time dealing with processes that ought to be computerized. 2a. The Customer The client of this program is also the customer. The clients from the actual point of view would mainly be the user and the bank employee. They are the clients of the product. They need to know details about the account in itself, either through papers or the system. They do not require knowing the technical parts of the system. They are unswervingly involved in the system as one of the three main stakeholders. Their knowledge influences directly the system, for the latter needs to be changed according to the users knowledge. 2a. The Other Stakeholders The different stakeholders for this product are: Bank Operator: She/he is at the same time client and customer of the product. She/he has a complete knowledge of what services the system should provide, does not need to know the technical parts of the system; She/he are directly involved in the system because she make the registration/payment/transaction effective. 4

CBRE3103

The database that the system uses is kept in the Bank database. IT Specialist : We need their approval and advice on the technical part of the project. They can help us figure out for example what parts of the system are doable, or what parts are too much of a trouble for the advantage that we might draw from it. Their knowledge is more focused on the technical part of the system, even though they still need to understand the process to provide a satisfactory service; Their knowledge of the online process is still high, but they need to know how to design the system so that it appropriately serves the user and the processes involved; They are directly involved, in the design, and in the effective concretization of the design into an effective program. The Advisor: They can provide invaluable suggestions on how to guide the user through system. They have no need to know how the system works, but they are the ones who probably know the best interests of the users; Their knowledge of the current process is high, they will not need to know the technical details of the system; They can provide important insights in the design of the system about the processes used by user to build their accounts (questions asked, frequent difficulties, constraints, desires, etc.). 3. Users of the product 3a. The Hands-On Users of the Product The users of the product will be: Customer: the user will use the system to make online payments/fund transfer for the upcoming months. The system will reimburse any lack of data of the users account, statements and even of the system itself (with an help section named as FAQ) Bank Administration: Bank administration will have the accessibility to system and the database connected to it, in order to verify the potential inaccuracy in the data or in the accounts or just to update the database accordingly.

CBRE3103

3b. Priorities Assigned to Users The system is consideration for the customer, there is not a pecking order for the users, in that the Bank administration is as important as the customer. 3c. Maintenance Users and Service Technicians The maintenance users will be the IT Specialist staff, the bank office, and the bank employee. The ITS staff will have to deal with any kind of operating inconsistency in the code. Most likely, even though it supposed to not occur, there will be a difficulty in the process. Therefore the ITS must have the option to have access to the system. The Bank employee must have access to the database. 4. Mandated Constraints Consequently many constraints for the system we are currently try to design. Mainly of these constraints will probably be social and budgetary as contrasting to technical constraints. Although we believe that these constraints will occur, at present we have no direct information of them. 4a. Solution Constraints Only one constraint we are currently aware of is the conformity involving the system and the Bank database. 4b. Implementation Environment of the Current System The environment in which this system is going to take place is the CIMB Bank . 4c. Partner or Collaborative Applications Description: The system must combine with the Bank database. Rationale: Input is required from the database and user information will be stored in the database. Fit criterion: Input/output to database works. 4d. Off-the-Shelf Software Not applicable 4d.1 Reusable Components We are not vigilant of reusable components that might maintain the development of the product

CBRE3103

4e. Anticipated Workplace Environment The system we envisage has a Web based interface and therefore it may be used in any environment. Specific interfaces for: Handheld devices The interface must be flexible so to accommodate different levels of experience with computers

4f. Schedule Constraints We are not aware of any schedule constraints 4g. Budget Constraints We are not aware of any budget constraints 5. Naming Conventions and Definitions 5a. Data Dictionary for Any Included Models Confirmation email: an email that would confirm to the customer that a system action has been taken ITS (Information Technology Service): technical staff for anything that concerns computers and Internet in the University. Lost/forgot password: in case the customer no longer has access to her/his account Customer: people who currently having bank account 6. Relevant Facts and Assumptions 6a. Facts About 100,000 users. About 1000 Bank employee. About 500 users registers per month.

6b. Assumptions We assume that the users have Internet access at any time they want to utilize the product. We assume that the users have some minimal knowledge: 7

CBRE3103

* Of the English language; * the user needs to know how to reach the system within the Bank website; * everything will be notified through the email and mobile, therefore the users must have an email account and mobile User should have E-PIN number which will be regain thru ATM for the online registration system the online registration system should be available 24 hours

7. The Scope of the Work 7a. The Current Situation The current situation does not provide an internet registration process at all. Existing system is the traditional banking, where customers have to go through the long queue, time wasted and still wouldnt have access to efficient and effective banking system. 7b. The Context of the Work The system will have to interact with a Bank environment. Therefore we are interested in keeping under control the contiguous systems such as the database, the Bank website, the mail system, or the automated environment 7c. Work Partitioning Business Event List

Event Name 1. user login

Input and Output User ID, Password (in)

Summary Access for the customer thru the online system

2.Bank Database supplies users data

Users details

(name,

Use data for processing.

MobileNum,DOB,Occupatio n,email,Address...) (in) Account No,TDate,TACNumber(in)

2. Transaction that required for the users (To be completed)

Used to process the transaction

CBRE3103

8. The Scope of the Product 8a. Product Boundary

Verification for TAC Bank Database

User Online Helpline Bank Employee Forget password/user id ITS Proposition of account

Bank Administration

8b. Product Use Case List Proposition of schedules: The system will indicated all the menus such as Bill payment/Fund Transfer/Reload. Customer will then be able to pick the option that her/his believes best suits her/his needs. Online Helpline: will be used to hilite the problem faced by the customer

9. Functional and Data Requirements 9a. Functional Requirements Requirement #: 1 F Description: The system defines and proposes one or more bill payment for customer Rationale: To help customer to pay few times Originator: Bank Database and customer Fit Criterion: The system provides the user accurate acknowledgement of transaction. Customer satisfaction: 2 Customer dissatisfaction: 1 Priority: 2(1 highest) 9

CBRE3103

Conflict: None Requirement #: 2 NF Description: Each transaction needs a security code Rationale: customer need to ensure correct data if given Originator: bank Database Fit Criterion: User test cases of a prototype Customer satisfaction: 2 Customer dissatisfaction: 4 Priority: 3 (1 highest) Conflict: None 10. Look and Feel Requirements 10a. Appearance Requirements The CIMB Bank symbol should be displayed. The system should be outstanding and simple to organize according to the customers level. The design and the color should make users feel contented when using the system instead of flashing ineffectual colors on the screen. The setting should also reflect the significance of the Bank environment. 10b. Style Requirements The overall style should be built up without difficulty in order for users to use it without doubt and capably. Once accessing the system, the users must feel at ease while glance at it and browsing all the way through it. The design should not be too colorful to sustain a certain importance of the web design of the Bank but at the same time it should not be too dull for the eye, so that it can appear satisfying to use.

11. Usability and Humanity Requirements 11a. Ease of Use Requirements The system should be without difficulty comprehensible design sequentially for users to utilize it. It ought to provide the required information when the users obligate potential fault. It should specify the several potential that the user has to use while with the system. The user will be allowed to undo any of the operation calculate or, for irretrievable operation, will always be asked to verify their choice in case 10

CBRE3103

they misinterpret the option or clicked on a button by mistake. The system will have uncomplicated access to help center whenever the user needs any kind of assistance. The system will also provide a FAQ page where it will explain the functionalities provided by the system. 11b. Personalization and Internationalization Requirements The Online system will provide be presented as a part of the website, which is only offered in English. 11c. Learning Requirements It must not require a lon period of time to learn the usage of the system. We want to create a selfexplanatory system that doesnt preferably need any tutorial section.But we are aware of the diverse levels of confidence that the user might have with the media tools. We will therefore provide a FAQ section that will concretely solve any possible problem concerning the use of the system. 11d. Understandability and Politeness Requirements Conversely, all the terms and descriptions may be clarified in the FAQ section. 11e. Accessibility Requirements The system should also consider the people who have sight issues. The screen and the text should be big enough to enable the customer to view. 12. Performance Requirements 12a. Speed and Latency Requirements The system is necessary must have a sensible amount of speed especially while browsing through page. 12b. Reliability and Availability Requirements The system and the external credentials must be updated frequently according to the necessities of the stakeholders. The user database will have to be available to customers all the time. 12c. Robustness or Fault-Tolerance Requirements When the system is disconnected due to over access at the same time, it shouldnt precede the process of the users have done. Once the users log in the same account, It should start again from the first due to security purpose.

11

CBRE3103

12d. Capacity Requirements The system must be capable to control all the information received from the database. 13. Operational and Environmental Requirements 13a. Expected Physical Environment The product can be used in any environment that allows Web access. 13b. Requirements for Interfacing with Adjacent Systems To make the system effectively operate the online system, it must be included with other IT services 14. Maintainability and Support Requirements 14a. Maintenance Requirements The database must be updated at once a month to ensure the functionality for the boundary period of time. Furthermore system should add the amendment suggested by stakeholders. 14b. Supportability Requirements The system should need to be entirely self-supporting since the users would be using it for making transactions. 14c. Adaptability Requirements The Web interface should be well-matched with standards in sequence to be utilizable through the main Web browsers in a large range of environments. 15. Security Requirements 15a. Access Requirements

12

CBRE3103

Every customer must have secure and private access to his/her data. The ITS and the bank database can have access to every part of the system. All these accesses (except the payment/reload/fund transfer transcation) require identification through TARC number which will be provided thru the users mobile. 15b. Integrity Requirements Data integrity should be assured by restrictive access to the database and by appropriate management, and back-up functionalities. A forced system failure is induced to test a backup recovery procedure for file integrity. Inaccurate data are entered to see how the system responds in terms of error detection and protection. Related to file integrity is a test to demonstrate that data and programs are secure from unauthorized access.

15c. Privacy Requirements The users privacy will be granted by the limited access that the log-in process is going to give to the database. Also, the system does not grant direct access to the database itself. Stakeholders who need to access the database will have to access it from a source independent from the Bank Database. 15d. Immunity Requirements The system will build up a protection structure that will ease to the least amount of fraud from systems and/or humans. 16. Cultural and Political Requirements 16a. Cultural Requirements CIMB has a multicultural community. Therefore, the system cannot give for granted nor use cultural knowledge such as iconography or symbols that are not internationally recognized, or some of the clients of the system might have some difficulties when using it. 16a. Political Requirements There are no political involvements in this system design. 17. Open Issues 13

CBRE3103

The system should assist user in becoming acquainted with online Bank administration, so that they know who to refer to for every problem they might have User should not be make payment if they have only limited amount in the account.

18. New Problems 18a. Effects on the Current Environment The problems that might emerge from the creation of the Online system are the following: Will be more complicated to allow exceptions to approved processes and necessities. When a serious technical complexity occurs, the system might cause severe holdup to the entire development. 18b. Effects on the Installed Systems No effects found yet. 18c. Potential User Problems The webpage of the system is understandable, easy and satisfying The only issues they might encounter concerns delayed update of the database or the difficulties for each case. For that issue, the system will provide several information needed to solve any problem. 18d. Limitations in the Anticipated Implementation Environment That May Inhibit the New Product The implementation environment for the system is not identified at the time of writing therefore we cannot state accurately its limitations 18e. Follow-Up Problems We cannot state the possibilities yet until the system is launched. 19. Tasks 19a. Project Planning No implementation plan has been made to date. 20. Migration to the New Product 14

CBRE3103

We suggest that the movement to the online banking system will overlap, at least for the first times that will be used, with the currently available paper-based system. The ITS will have to at least verify the operations that are being computed on the system to detect every unforeseen issue that might come up. 21. Risks The risks that might arise in the implementation of such a system are few; especially if we consider that the system will be constantly monitored in the first years of its effective application, anything that might be wrong will be almost instantly corrected by one of the stakeholders, be it the bank employee or the ITS for Example. On a general level, however the main risks that this system is facing are: The possible overload of the system in the critical days during peak hours.

22. Costs Our concern about the system does not deal with its costs. 23. User Documentation and Training 23a. User Documentation Requirements All user documentations should be supplied online. Diverse documentation should be foreseen for different stakeholders (bank employee, administration, ITS). 23b. Training Requirements No training should be necessary for the users to be able to use the system (online help will be provided). The system should provide training material.

15

CBRE3103

Question B Most commonly well recognized standards are IEEE Standard and Volere Template. IEEEs requirement specification template organizes the requests, functionalities and requirements separately. The structure of the IEEE template sophisticated step-by-step from high-level needs to lowlevel (strict and technical) detailed requirements and every chapter in IEEE template consist diverse views (and levels) of requirements and functionalities. Style of the template is very much severe and technical alike and not so client-friendly reading, but has very comprehensive approach. . It is suitable for modelling product level requirements. It summarizes the content, qualities and organisation of a good requirements specification. The IEEE template approach is tremendous for any size of systems that are developed for large-scale organized clients, who require very firm and taken as a whole complete approach. Generally focus on software quality attributes and provide good characteristics for an excellent software requirements specification document. Volere Template was developed by James and Suzanne Robertson (The Atlantic Systems Guide).This template may be used to specify user requirements as well as developers requirement. Volere template has very straight forwarded, but flexible structure. The Volere template doesnt oblige the requirement engineer to write all parts of the template, instead it gives thoughts on what could be written and provides nice motivational aspects on why such a stage should/could be written. In Volere template the targets (purposes and clients), product/project constraints and naming conventions are defined at the inauguration, which is very similar to the IEEE template, but they are separated to different section (which make them easier to move toward). It consist of requirement Shell that is used during gathering the information from the stackholder, thus we can use this before proceeding to the higher level (before storing the data using an automated tool). In addition the Volere template declares the stakeholders and users with more detailed information. Volere template presents the requirements by separating them to functional and non-functional requirements more clearly (unlike IEEE). The Volere template also provides ways to clearly amaze why its essential to widen this new system (by analyzing the current business processes), which motivates the clients. In addition Volere template has 16

CBRE3103

very client-friendly approach because it provides lots of different aspects which aim for keeping the client on the tracks of the project. Unlike the IEEE template, the Volere template also offers move toward to declare project-specific issues, such as who to deal with open issues, risks and costs. Although the IEEE standard is not ideal, it contains a great deal of good advice on how to write requirements and how to avoid problems. It is too general to be an organisational standard and the general framework that can be modified and adapted to define a standard geared to the needs of a particular organisation. It is heavy template for small and simple projects compared to Volere template.IEEE standard everything can possibly be captured is listed and must be followed as a lock-step procedure, whereby in Volere think of the process as a list of things that have to be done (to some degree of details with our own structural and organisational setup.IEEE standard defines the categories functionality, external interfaces, performance, attributes (portability, security, etc.), and design constraints. Thus project requirements (such as schedule, cost, or development requirements) are explicitly excluded. But in Volere standard there are management advantages like consistent input to estimating, risk management, monitoring, benefit analysis and the basis for reuse.IEEE standard unable to changing the template based on the feedback from real projects however for Volere requirement there is portion for the changes that is used under project issue section. Overall the Volere template offers flexible approach for requirements specification where each major aspects are divided to clearly set apart categories (types in Volere terminology), which can easy the requirement writing. The Volere template has much less technical approach unlike the IEEE template, but any knowledge requirements engineer can fill the technical aspects without needing to have a real template for it.

17

CBRE3103

Comparison between IEEE-830 and Volere template IEEE-830 1. Introduction 1.1 Purpose 1.2 Scope (Name, General System Description, Benefits) 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Overall description 2.1 Product perspective: System interfaces, user interfaces, HW interfaces, SW interfaces, Communications Interfaces Memory constraints 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3. Specific requirements 3.1 External interfaces 3.2 Functions 3.3 Performance requirements 3.4 Logical database requirements 3.5 Design constraints 3.6 Standards compliance 3.7 Software system attributes Reliability Availability Security Maintainability Portability Appendixes Volere Project Drivers 1. The Purpose of the Product 2. Client, Customer and other Stakeholders 3. Users of the Product Project Constraints 4. Mandated Constraints 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions Functional Requirements 7. The Scope of the Work 8. The Scope of the Product 9. Functional and Data Requirements Non-functional Requirements 10. Look and Feel Requirements 11. Usability Requirements 12. Performance Requirements 13. Operational Requirements 14. Maintainability and Portability Requirements 15. Security Requirements 16. Cultural and Political Requirements 17. Legal Requirements Project Issues 18. Open Issues 19. Off-the-Shelf Solutions 20. New Problems 21. Tasks 22. Cutover 23. Risks 24. Costs 25. User Documentation and Training 26. Waiting Room 27. Ideas for Solutions

18

CBRE3103

Question C UML DIAGRAM OF CIMB

ONLINE BANKING FOR CIMB BANK

REGISTER

Customer SIGN IN INVALI D LOGIN< Bank Database <extend> include> Bank Operator CUSTOMER SERVICE HELPLINE <include LOGIN

CONTROL ACCOUNT

ORGANIZE TRANSACTION 19

CBRE3103

Bank Database

Customer

MAIN COURSE OF EACH USE CASE. 1. User Case: User Registration Brief Description: This use case is to allow to register Actor: Customer Pre-condition: None

Basic Flow i. Navigate to the Registration page ii. Fill the information iii.Enter the E-Pin information iv.Enter account name for the new account iv.Enter the submit button

Post Condition: Customer will be inform the registration is successful and email will be sent to his/her email account in order to proceed to sign in.

1.2

Alternate flow:

If the details specified by Customer are invalid. Then an error message will be occurred. 20

CBRE3103

Pre Condition: Customer must enter valid information

Post Condition: None 2 .User Case: SIGN IN Brief Description: This use case is to customer to login to access their account from bank database. A customer may be an invalid customer so the system has to prompt the customer immediately Actor: Customer Pre-condition: Login as a customer Basic Flow i. Enter username and password

Post-condition: On triumph customer can precede the operation 2.1 Alternate flow: If the details specified by Customer are invalid then he/she will be informed that his login is failed

Pre Condition: Customer must have a valid login id and password

Post Condition: The account database is modified after the operation

3.

Customer service Helpline

Brief Description: Customer service helpline is given to the Bank operator .Every customer login into his account through which he/she can communicate with the bank database. Bank employee will provide the services to the customer. 21

CBRE3103

Actor: Bank operator Pre-condition: Login as a Bank operator Basic Flow I.Enter username and password ii. Validate with the customers request iii.Notify to the customer once the request is successful Post-condition: On success customer can precede the operation Alternate flow: None

4. User Case: Control Accounts Brief Description: Bank Database will notify the account information to the customer thru email Actor: Bank Database system Pre-condition: None Basic Flow i.Generate account details ii.Send details to customer inbox Post-condition: Customer details such as account no, access code etc is sent to inbox. Alternate flow: None

4. User Case: Organize Transactions Brief Description: Bank Database will ensure all the transactions that have been done by customer will be updated appropriately Actor: Bank Database system 22

CBRE3103

Pre-condition: None Basic Flow I.Accomplish transaction instructions Ii.Updates customer account Iii.Generate account balances

Post-condition: Customer sees the current state of account on the their home page Alternate flow: None

23

CBRE3103

UML DIAGRAM FOR OPERATING AN ACCOUNT

TRANSFER FUNDS
TAC NUM INVALID TARC

<<extend>>
Bank Database

include>> Customer

include>>

include>> TARC VERIFICATION

CONNECT ACCOUNT TO OPERATE

BILL PAYMENT
TAC NUM INVALID TARC

<<extend>> 24

include>>

include>>

include> TARC VERIFICATION

CBRE3103

Customer

CONNECT ACCOUNT TO OPERATE

Bank Database

PREPAID RELOAD
TAC NUM INVALID TARC

<<extend>>
Bank Database

include>> Customer

include>>

include>> TARC VERIFICATION

CONNECT ACCOUNT TO OPERATE

ESTATEMENT OF ACCOUNT <<include CONNECT ACCOUNT TO OPERATE

Bank Database

25

CBRE3103

Customer

MAIN COURSE OF EACH USE CASE.

1. User Case :TRANSFER FUNDS

Brief Description: This use case it to allow customer to make transfer funds. Actor: Customer Pre-condition: Select on the account on which the fund is to be transferred Basic Flow i.Choose the Transfer Funds form page ii.Fill the fund transfer information iii.Enter Submit button iv.TAC Number will be sent to customer mobile v.Enter TAC Number for transactions verification vi.Click the submit button

1 .1 Alternate flow: If the TARC specified by Customer are invalid then he/she will be informed that his transaction is failed 26

CBRE3103

Pre Condition: Customer must have a valid TARC NUMBER

Post Condition: Error message will be displayed for the failed transaction

2. User Case: BILL PAYMENTS

Brief Description: This use case it to allow customer to make bill payment Actor: Customer Pre-condition: Click on the account on which the payments need to be pay. Basic Flow i.Choose the Bill Payment form page ii.Fill the Bill Payment information iii.Enter Submit button iv.TAC Number will be sent to customer mobile v.Enter TAC Number for transactions verification vi.Click the submit button

2 .1 Alternate flow: If the TARC specified by Customer are invalid then he/she will be informed that his transaction is failed

Pre Condition: Customer must have a valid TARC NUMBER 27

CBRE3103

Post Condition: Error message will be displayed for the failed transaction

3. User Case :PREPAID RELOAD

Brief Description: This use case it to allow customer to make prepaid reload Actor: Customer Pre-condition: Choose on the account on for the reload transaction Basic Flow i.choose the prepaid reload form page ii.Fill the prepaid reload information iii.Enter Submit button iv.TAC Number will be sent to customer mobile v.Enter TAC Number for transactions verification vi.Click the submit button

3 .1 Alternate flow: If the TARC specified by Customer are invalid then he/she will be informed that his transaction is failed

Pre Condition: Customer must have a valid TARC NUMBER

Post Condition: Error message will be displayed for the failed transaction

28

CBRE3103

29

CBRE3103

4. User Case :E-STATEMENT OF ACCOUNT

Brief Description: This use case it to allow customer to make view online Estatement Actor: Customer Pre-condition: Click on the account on which the statement is to be viewed Basic Flow I.observe the E-Statement of Account form page ii.analysis the transactions of the selected account iii.Print the statement

Post Condition: None

QUESTION D

An example if we would want to create a payroll sytem.The Human resource management has indicated a limited budget for this project. It will affect the Functional requirement for the system. We only will be able to provide functional requirement such as monthy salary, overtime, bonus, double pay, employee record, employee id. If the organization has a bigger budget, maybe we can add more function in the system such as calculate holiday, annual leave, leave application, employee profile and etc. An example if we would want to create a system for government to input the financial information. The management have restricted some of the personal information wont be provide to us due to security purpose. We will only able to provide functional

30

CBRE3103

requirement such as army id,date join,army status.If the organizational able to provide more information we will be able include more data in the functional requirement

REFERENCES Robertson, J. & Robertsen, S. (2005), Volere requirements Specification Template, edition 10.1, http://www.systemsguild.com/GuildSite/Robs/Template.html Robertson, S. and Robertson, J. (2006) Mastering the Requirements Process, 2nd edn. Addison-Wesley, Boston Ayo Charles. K and Babajide Daniel O, 2006, Designing a Reliable E-payment System Requirements Engineering ONLINE:https://dspace.ndlr.ie/jspui/bitstream/10633/5516/1/StandardsTemplatesLecture 4.pdf (retrieved on 10 February 2011) ONLINE:http://www.cimbclicks.com/ ONLINE:http://www.iadis.net/dl/final_uploads/200711C106.pdf (retrieved on 15 February 2011) Software Requirements Resources ONLINE:http://www.construx.com/Page.aspx?hid=1626 (retrieved on 15 February 2011)

31

CBRE3103

Ieee 830 1998 (Software Requirements Specifications) ONLINE:http://www.slideshare.net/ahmedhasan/ieee-830-1998-software-requirementsspecifications (retrieved on 15 February 2011) ONLINE:Functional Requirements Specification Research Portals(retrieved on 20 February 2011) ONLINE:1998 - IEEE Recommended Practice for Software Requirements Specifications (retrieved on 20 February 2011) Online Banking system ONLINE:http://www.scribd.com/doc/18028736/Online-Banking-System (retrieved on 20 February 2011) Sample case study ONLINE:http://ac.aup.fr/~croda/SampleStudentsWork/cs348/finalProjectS07/final %20presentation/final/Volere_Specifications_FV.pdf (retrieved on 25 February 2011)

32