Get documents about "overall
Document Sample
CS 473a Software Requirements Engineering
Project 2: Part B
Analysis and Validation
Author Information:
Author Name Email Address Group No.
Thomas Tang ttang@uwo.ca 6
Yujie Yin yyin24@uwo.ca 6
Instructor: Prof. Nazim H. Madhavji
December 8, 2004
1
Table of Contents
Objective Setting……………………………………….…….…….. Pg. 1
Task One - Requirement Examination and Analysis
Mobile Banking ………………………………………….…….. Pg. 2
Interac Banking ………………………………………………… Pg. 6
Telephone Banking - Scale Back…………………….………… Pg. 9
Task Two - Analysis of Issues and Assumptions
(No Document for this section - all results are shown on RE Tool)
Task Three - Decision Map
Relations among Requirements, Issues and Assumptions……… Pg. 11
Task Four - Risk Analysis Report….……………………………. Pg. 17
Remark:
All four tasks are done based on CS473 project1 and project2 part A of
group 10.
2
Objective Setting
New Zealand Bank has now completed the second version of its requirements document
by group 10. We are going to examine and validate project 2 part A and project 1.
The previous requirements have been analysed and issues and assumptions were elicited
along with the second version. Management has decided that one more analysis and
review phase should take place to insure that the requirements they go forward with are
complete and correct. Tasks will be carried out:
Examination of the requirements and models
Trying to find any requirements that need to be changed
Examine and analyse the unresolved issues and assumptions which have been
elicited.
Construct a ‘decision map’ which will show which requirements, issues and
assumptions are related to one another
A report outlining the biggest risks for this system
3
Task One
Requirement Examination and Analysis
Mobile Banking
Version 1.1
In this version, we add some new requirement to keep the subsystem's functionality
consistent with the other system. The modified or new requirements are addressed with a
‘*’ before the label.
Label: R5.1
Title: Mobile - check account balance,
Description: Customer should be able to check their current balance for an indicated
account.
Rationale: The most basic and necessary feature a banking system should have.
*Label: R5.2
Title: Mobile- edits personal information,
Description: Customer should be able to edit personal information (phone number,
address, e-mail address)
Rationale: Allow the customers to update personal information more easily anytime,
anywhere.
*Label: R5.3
Title: Mobile - schedule bill payment,
Description: Customer should be able to schedule post-dated bill payments.
Rationale: Allow the customers to pay their bills on a specified date
Label: R5.4
Title: Mobile - pay bills,
Description: Customer should be able to pay various bills so long as the bill is less than
or equal to the indicated limit for the indicated account
Rationale: Already a feature in other subsystems.
Label: R5.5
Title: Mobile - view transaction history,
Description: Customer should be able to view transaction history from the last 2 weeks.
Rationale: common banking operation
Label: R5.6
Title: Mobile - transfer funds between accounts,
Description: Customer should be able to transfer funds between multiple accounts
Rationale: common banking operation
4
Label: R5.7
Title: Mobile - updates for cellular application,
Description: There should be updates available for the cellular application. The updates
would be available, say once a month. The updates may contain product improvements,
new functions, etc.
Rationale: This is to allow the service to be expandable, to allow new functions to be
added later
Label: R5.8
Title: Mobile - mobile application should be made available for most mobile devices,
Description: The downloadable application should be available for mobile devices of
major mobile companies: Nokia, Motorola, Sony, Ericsson, Samsung, Palm OS, and
Windows Mobile - for all phones/systems supporting GPRS.
Rationale: To enable almost all users who have such a device to be able to use the
service. Also by supporting most devices, it will be competitive advantage for the
company.
Label: R5.9
Title: Mobile - all communication should be encrypted,
Description: All requests from mobile device and all responses from server will be
encrypted.
Rationale: To prevent data misuse (hacking), and to give assurance to customer that the
service is secure, so that more of them use the service.
Label: R5.10
Title: Mobile - application should enable security algorithms to be modifiable/updatable,
Description: The mobile application should be coded so that security algorithms could be
updated in the future.
Rationale: This is to provide support for more efficient encryption algorithms that may
become available.
Label: R5.11
Title: Mobile - the data encryptions should not make the system too slow,
Description: The encryption algorithms should not be too computationally intensive, so
they do not consume too much processing power of the handheld device.
Rationale: To make the system fast and responsive.
Label: R5.12
Title: Mobile - response time for a transaction request should be at most 5 seconds,
Description: Response time for a request should be at most 5 seconds; that is the time
from a request made from the mobile application till a response is received from the
server.
Rationale: This is so to keep the mobile banking service useable; reasonably fast for the
user, but slow enough to account for wireless communication constraints (e.g. delays).
5
Label: R5.13
Title: Mobile - the application should show some visual feedback when a transaction is
processing,
Description: There should be some sort of feedback shown on the mobile device screen
that shows that a transaction is processing; it could be an animating icon, flashing text,
etc.
Rationale: To give feedback to the user that device is processing, rather than stalled (or
crashed). This is important since, a transaction can take up to 5 seconds.
Label: R5.14
Title: Mobile - the system should be able to handle 400 mobile requests per second,
Description: The system should be able to accept and process at least 400 transaction
requests per second from mobile devices.
Rationale: To allow multiple mobile users at a time using the service simultaneously.
Label: R5.16
Title: Mobile - compatibility,
Description: The Mobile Banking System should be compatible with other systems
already implemented in the company
Rationale: Necessary, as all the subsystems share the same database.
Label: R5.17
Title: Mobile - safe disconnect,
Description: User's account should be safely closed on any kind of disconnect.
Rationale: Not implementing this would be a big security hole.
Label: R5.18
Title: Mobile - language of implementation,
Description: The mobile phone application will be developed in Java and will run on
J2ME.
Rationale: Best for maximum compatibility.
Label: R5.19
Title: Mobile - user authentication,
Description: Customer should be provided access to Mobile Banking services based on
valid bank account number and PIN. Customer should have the choice to put a constraint
on the access to be only from a given handset. By default Mobile Banking is disabled,
and must be explicitly enabled by customer to allow for its use.
Rationale: Secure and gives user the freedom to adjust the level of security
*Label: R5.20
Title: Mobile- request stop payment,
Description: Customer should be able to request stop payments.
Rationale: In order to let customers to cancel any posted-dated payment.
*Label: R5.21
6
Title: Mobile- error handling,
Description: Must be able to handle invalid input at any point.
Rationale: make sure errors are handled correctly and cause no problem to the entire
system and customers.
7
Interac banking
Version 1.1
In this version, we modify and correct some requirements. The modified or new
requirements are addressed with a ‘*’ before the label.
*Label: R6.1
Title: Interac - there should be a dedicated Interac server that handles only interac
devices' requests,
Description: There should be a dedicated server that only accepts, handles and processes
requests that come from Interac devices. The dedicated server interfaces with the banking
database.
Rationale: A dedicated server will make the system faster, will allow many simultaneous
transactions, and will be easy to maintain.
*Label: R6.2
Title: Interac - the interac device should communicate with the interac server via modem
and phone line,
Description: The interac device should have a modem. The device connects to the interac
server by dialling a connection through a normal phone line connection or high speed
cable for large corporation.
Rationale: It makes the system cheaper, since no dedicated communication medium
needs to be developed - use is made of an existing infrastructure.
*Label: R6.3
Title: Interac - interac device will need 5 pieces of information: card no, pin, amount,
account type and vendor-id,
Description: The interac device will need 5 pieces of information: card no, pin, amount,
account type and vendor-id, to send a transaction request to the interac server. The card
number and pin identify the bank account number, the amount identifies the amount of
money to deduct, account type tells if a account is cheque or savings account, and
vendor-id identifies the shop/store that is making the transaction.
Rationale: This is sufficient information to process a transaction completely.
*Label: R6.4
Title: Interac - the server should be able to send various responses for different conditions
that may occur,
Description: The interac server can send 4 responses to the customers: 'Insufficient
Funds', 'Invalid PIN', ‘Transaction Approved', and ‘Service not available'. The server will
send theses responses when it has received a transaction request. The interac device must
be able to understand and process these responses.
Rationale: These 4 responses are sufficient to identify and cover the various scenarios
that may occur.
Label: R6.5
8
Title: Interac - the interac device should time-out after 10 seconds if there is no server
response,
Description: Interac device should timeout after 10 seconds if it receives no response
from the server within those ten seconds, and should display 'Timeout' and abort the
transaction.
Rationale: It is a simple solution that makes server side problems easy to handle, say
when the server disconnects.
Label: R6.6
Title: Interac - the response time should be at most 5 seconds,
Description: The time taken, from when a transaction request is made on a interac device,
to the time when the server response is received, should be at most 5 seconds.
Rationale:5 seconds is sufficient time to allow a transaction to process properly, yet it
does not make the system appear too slow to the user.
Label: R6.7
Title: Interac - the server should be able to handle 1000 transaction per second,
Description: The interac server should be able to handle 1000 interac transactions per
second simultaneously. For those transactions that it cannot handle, it should send out the
responses message 'Service not available'.
Rationale: To allow as many customers to use the system as possible - takes into account
busy time-periods.
Label: R6.8
Title: Interac - the communication mechanism between interac device and server should
be TCP/IP based,
Description: The communication mechanism between interac device and server should be
based on TCP/IP protocol.
Rationale: To use existing tools and infrastructure to allow for quick development of
service.
*Label: R6.9
Title: Interac - communications between device and server should be encrypted,
Description: All communications between device and server should be encrypted using
RSA, 128 - bits: this includes transaction requests made from an Interac device as well as
responses from server.
Rationale: To provide security to Interac services.
Label: R.6.12
Title: Interac - if capacity reached, process transactions through web server,
Description: If the Interac server is down or has reached its operational capacity,
transactions should get processed by the web server.
Rationale: Greatly increases the chances of a request getting processed at peak use times,
and takes advantage of already existing technology.
Label: R6.13
9
Title: Interac - card theft protection,
Description: If an Invalid PIN is entered 3 consecutive times in a day, access to the
account should be blocked for the rest of the day.
Rationale: Offers customer some protection in case of bank card theft, while not being
too much of a hassle.
Label: R6.14
Title: Interac - delivery date,
Description: The interface for the Interac system is to be complete, integrated with the
rest of the system and usable by May 19, 2005.
Rationale: The interac technology will be introduced to New Zealand within the next 6
months. The company wants to get its interac system running as soon as possible, but
will need about a month to get it integrated.
Label: R6.16
Title: Interac - compatibility,
Description: The interface for the Interac system should be compatible with other systems
already implemented in the company
Rationale: Necessary for the overall system to work as a whole.
10
Telephone Banking - Scale Back
Version 1.1
In the version, we clarify some ambiguity in some requirements
*Label: R7.1
Title: Telephone (Expansion) - voice recognition.
Description: Install a voice recognition system to the existing telephone banking system
so that telephone banking could be done automatically.
Rationale: Pushing button takes too long to perform a single operation that need to follow
the pre-set operation path/routine. By having no operators (real human) in the system
enable the reduction of the operation cost.
*Label: R7.2
Title: Telephone (Expansion) - voice recognition in English,
Description: Voice recognition System will be in English.
Rationale: English is assumed to be the default language.
*Label: R7.3
Title: Telephone (Expansion) - option of human operator,
Description: There should be an option of talking to a human operator at regular working
hours during a dial-tone interaction/transaction; maybe a special key (number) is reserved
for this feature.
Rationale: This is to provide the user the option to use human operator service. Say if the
user lost track of steps, or got confused, or just doesn't want to use the automated system
for whatever reason.
Label: R7.4
Title: Telephone (Expansion) - roll-back mechanism,
Description: There should be roll-back mechanism so that if a call is disconnected while a
transaction request is being processed, the transaction request is cancelled and any tasks
executed as part of the transaction are rolled back - to completely cancel the transaction.
Rationale: To account for situations when calls are disconnected. Also to keep users
account in a consistent state.
Label: R7.5
Title: Telephone (Expansion) - logout summary of transactions,
Description: When user requests logout, system should summarize the transactions made
and tell them to user, and then hang-up.
Rationale: To confirm to the user that what activities and transactions took place.
*Label: R7.6
Title: Telephone (Expansion) - repeating of most recent transaction activities,
Description: There should be an option available to the user to repeat the most recent
transaction activities recorded by the voice recognition system.
11
Rationale: To improve usability of system.
Label: R7.7
Title: Telephone (Expansion) - transactions must be completed within 10 seconds,
Description: Any transaction must be completed within 10 seconds, during which the
system will tell the user 'Transaction processing' repeatedly.
Rationale: To keep the system relatively fast and responsive, and to give feedback while
processing.
Label: R7.8
Title: Telephone (Expansion) - each transaction must be logged,
Description: A log will be maintained for each transaction made on the dial-tone system.
The log must contain all inputs by users, as well as all messages issued by system.
Rationale: To keep track of activities for various purposes: for proof of transaction, for
statistical information, etc.
Label: R7.9
Title: Telephone (Expansion) - system should handle 500 connections at a time,
Description: The system should be able to handle 500 connections (simultaneous) at a
time (per second).
Rationale:
Label: R7.10
Title: Telephone (Expansion) - maintenance on system will be done on a monthly basis,
Description: System will be maintained monthly, usually at the end of a month. The
maintenance must not take longer than a few hours.
Rationale: To keep the system in a reliable state.
Label: R7.11
Title: Telephone (Expansion) - user manual for automated telephone banking,
Description: A manual must be developed for new users that have not used the system
before. A hardcopy will be made at the banks' branch locations, whereas a softcopy will
be made available on the web.
Rationale: To make it easier for new customers to use the system.
12
Task Three
Decision Maps
Part One
This part is done through the RE Tools.
Part Two
Issues
I.1 Cellular application space/memory requirements: if the application is a
downloadable app, then it would require some memory space of the users’
cellular device. The memory space should be kept as small as possible
I.2 Voice recognition language - providing service for more than 1 language
may be too costly
I.3 System will not be usable by people with hearing difficulties.
I.4 Some users (older users in particular) will not be comfortable using the
automated telephone system.
Assumptions
A.1 Most cell phones currently support J2ME.
A.2 Bills to be paid, are payable at financial institutions. (This is a requirement,
not an assumption.)
A.3 The web server will be capable of processing Interac requests.
A.4 The web server has much greater capacity for processing transactions
than the Interac server, therefore it is less likely to get bogged down.
A.5 The system logs failed authentication attempts. (This is a requirement, not
an assumption.)
A.6 Assuming developers fully follow the methodology that is a big part of
Fuse box.
A.7 Assumption is made that there is no backup web server for the web
banking service.
Note: The above issues and assumptions are reference from Task One and RE
tools for Requirement descriptions.
13
Table 3.1 Issues/Assumptions Relationship
Assumptions
A.1 A.2 A.3 A.4 A.5 A.6 A.7
Issues
I.1 N N/A N N N/A N N
I.2 N N/A N N N/A N N
I.3 N N/A N N N/A N N
I.4 N N/A N N N/A N N
Y = Has Relationship
N = No Relationship
N/A = Not Applicable
Table 3.2 Issues/Issues Relationship
Issues
I.1 I.2 I.3 I.4
Issues
I.1 N N N N
I.2 N N Y Y
I.3 N Y N N
I.4 N Y N N
Y = Has Relationship
N = No Relationship
Table 3.3 Assumptions/Assumptions Relationship
Assumptions
A.1 A.2 A.3 A.4 A.5 A.6 A.7
Assumptions
A.1 N N/A N N N/A N N
A.2 N/A N/A N/A N/A N/A N/A N/A
A.3 N N/A N Y N/A N Y
A.4 N N/A Y N N/A N Y
A.5 N/A N/A N/A N/A N/A N/A N/A
A.6 N N/A N N N/A N N
A.7 N N/A Y Y N/A N N
Y = Has Relationship
N = No Relationship
N/A = Not Applicable
14
Table 3.4 Requirements/Issues and Requirements/Assumptions
Relationship
Requirements Related Issue Set Related Assumption Set Remark
Overall System
Ors 1.1 (A.3 , A.7)
Ors 1.2 (A.7)
Ors 1.3 (I.2, I.4) (A.3, A.4)
Ors 1.4 (I.2, I.4) (A.7)
Ors 1.5 (I.2, I.4) (A.3, A.4, A.7)
Ors 1.6 (I.2, I.3,I.4)
Ors 1.7 (I.2, I.3,I.4) (A.1)
Ors 1.8
Ors 1.9 (I.2)
Ors 1.10
Ors 1.11 (A.1, A.3)
Ors 1.12 (A.1, A.3)
Ors 1.13
Ors 1.14 (I.1, I.2) (A.1)
Ors 1.15 (I.1) (A.1)
Ors 1.16 (A.1)
Ors 1.17 (A.4)
Ors 1.18 (A.4)
Ors 1.19 (A.3, A.4, A.7)
Ors 1.20 (A.3)
Ors 1.21 (I.2)
Ors 1.22
Ors 1.23 (I.1) (A.1)
ATM
Ors 2.1
Ors 2.2
Ors 2.3
Ors 2.4
Ors 2.5
Ors 2.6
Ors 2.7
Ors 2.8
Ors 2.9
Ors 2.10
Ors 2.11
Ors 2.12
15
Ors 2.13
Ors 2.14
Ors 2.15
Ors 2.16
Ors 2.17
Ors 2.18
Ors 2.19
Ors 2.20
Ors 2.21
Ors 2.22
Ors 2.23
Internet Banking
Ors 3.1
Ors 3.2
Ors 3.3 (A.3, A.4)
Ors 3.4 (A.4)
Ors 3.5 (A.4)
Ors 3.6 (A.3, A.4)
Ors 3.7 (A.3, A.4)
Ors 3.8 (A.4)
Ors 3.9 (A.3, A.4)
Ors 3.10 (A.4)
Ors 3.11 (A.4)
Ors 3.12 (A.4)
Ors 3.13 (A.3, A.4)
Ors 3.14 (A.7)
Ors 3.15
Ors 3.16
Ors 3.17 (A.3, A.4)
Ors 3.18 (A.3, A.6)
Ors 3.19 (A.6)
Ors 3.20 (A.3, A.4)
Ors 3.21 (A.4)
R 8.1 (A.6) Web Banking in
Group 10
R 8.2 Same as above
R 8.3 (A.4) Same as above
R 8.4 (A.4) Same as above
Automated Telephone Banking
Ors 4.1 (I.2, I.3, I.4)
Ors 4.2 (I.2)
16
Ors 4.3
Ors 4.4 (I.2, I.4)
Ors 4.5
Ors 4.6 (I.2)
Ors 4.7 (I.2)
Ors 4.8 (I.2)
Ors 4.9 (I.2)
Ors 4.10 (I.2)
Ors 4.11 (I.2)
Ors 4.12 (I.2)
Ors 4.13 (I.2)
Ors 4.14 (I.2)
Ors 4.15 (I.2)
Ors 4.16
R7.1 (I.2, I.3, I.4)
R7.2 (I.2)
R7.3 (I.2, I.4)
R7.4
R7.5 (I.2)
R7.6 (I.2)
R7.7
R7.8
R7.9
R7.10
R7.11 (I.4)
Mobile Banking
R5.1 (I.1) (A.1)
R5.2 (I.1) (A.1)
R5.3 (A.1)
R5.4 (I.1) (A.1)
R5.5 (I.1) (A.1)
R5.6 (I.1) (A.1)
R5.7 (I.1) (A.1)
R5.8 (I.1) (A.1)
R5.9 (I.1) (A.1)
R5.10 (I.1) (A.1)
R5.11 (I.1) (A.1)
R5.12
R5.13 (I.1) (A.1)
R5.14
R5.15
R5.16 (A.1)
R5.17 (A.1)
17
R5.18 (A.1)
R5.19 (A.1)
R5.20 (A.1)
R5.21 (A.1)
Interac Banking
R6.1
R6.2
R6.3
R6.4
R6.5
R6.6
R6.7
R6.8
R6.9
R6.10
R6.11
R6.12
R6.13
R6.14
R6.15
R6.16
R6.17
R6.18
R6.19
R6.20
R6.21
Remark: Empty cell means no issues or assumption related with this requirement.
18
Task Four
Risk Analysis Report
Based on the system designed by group 10, we found some design and requirements are
embedded in a risky situation that would definitely bring negative effect to the future
expansion and regular operation of the banking system.
In issue 1, as mentioned, cellular application space/memory should be kept as small as
possible. If such issue is not solved, the bank will face a risky situation of having a
mobile banking system with limited functionalities. In fact, the bank is sitting in the
passive position under such situation that it has to follow the technological change in
mobile phone industry. If the mobile phone has more memory, together with a high
network transmission rate, the size of the application should not be an issue. This
somehow set restriction on to the banking wireless system which has to overcome the
situation of limiting the space of the application but offering the most important
functionalities at the same time. However, most of the mobile phone in the existing
market can support a lot of extra features besides of dialing in and out. Features like
downloading ring tones, setting up wallpaper, SMS (Short Message Service), etc. This
has to be complement with the connectivity using GPRS and other wireless technology.
Therefore, the banking wireless system must follow the technological change as a
guideline.
19
1, 2
Typically, cell-phone manufacturers now use 8 to 16 Mb of low-power SRAM for data
backup; 32 to 128 Mb of Pseudo-SRAM (PSRAM) for the working area of the system;
and 64 to 128 Mb of NOR Flash for bootable code storage on basic phone programs.
They also employ 128 to 256 Mb or more additional memory - often NAND Flash - for
application software and the storage of huge data, such as pictures and music. Although
we see the memory-capacity requirements are increasing at a high speed, it is driven by
the increasing diversity of other applications. Such applications include e-mail, Internet
browsing, Java applications, camera/movie capability, and music playback. The need for
memory to support games, Internet browsing, e-mail, and camera functionality has grown
at a much faster rate than was originally anticipated. Therefore, it is still a challenge for
the bank to solve the memory size problem.
Another risk we see is embedding in assumption 4 and 7. In assumption 4, as stated the
web server has much greater capacity for processing transactions than the Interac server,
therefore it is less likely to get bogged down. However, in assumption 7 we find a
decision of having no backup web server for the web banking service in order to avoid
the cost of keeping a back up server,
No matter under what situation, a banking system must always obey the ACID rules:
Atomic, Consistency, Isolation and Durability. Increasing the speed and capacity of web
server is not a difficult issue. However, increasing the workload of the web server is
equivalence to increasing the risk of the system failure. Without any backup system
creates an illusion of solving the problem of cost reduction, that only applies in short
20
term. Cutting of the backup system from the overall system design doesn’t solve the
problem at all. In fact, it may even bring serious damage and unbearable lost to the whole
bank system in long term. Losing the trust from customers, having a bad reputation, data
lost, taking a long time to recover the system, these are all issues a bank should never let
happen. In fact, a bank cannot afford to let the system crash even once without any
backup or immediate recovery. Therefore, every banking system, or subsystem, should
have a backup in order to maintain the security always in the highest level.
Reference
[1] http://www.wsdmag.com/Articles/Index.cfm?ArticleID=7916&pg=1
[2] http://www.wsdmag.com/Files/32/7916/Figure_02.gif
[3] CS473 project1 and project2 part A of group 10.
21
