Data

http://www.esi-intl.com/searchresult?
searchStr=elicitation
%20requirements
A thorough discovery of business requirements is almost never readily

available at an analysts fingertipsrarely can requirements be quickly
looked up as one would gather information for a term paper or study for a
test. Much of business or technical requirements is not documented
anywhereit resides in the minds of stakeholders, in feedback that has
yet to be obtained from end users, and from a study of flowcharts and
surveys that have yet to be created. And so requirements must be
elicited, or drawn out, and the methodology in doing so must be logical
and meticulous. The importance of elicitation cannot be overstated, for it
is the linchpin to any requirements project. As one scholarly article notes:
Mistakes made in elicitation have been shown many times to be major
causes of systems failure or abandonment and this has a very large cost
either in the complete loss or the expense of fixing mistakes. Adequate
study and preparation for elicitation can go a long way to preventing
these types of errors. The purpose of requirements elicitation, therefore, is
to thoroughly identify the business needs, risks, and assumptions
associated with any given project.
Prepare for Elicitation
The first step in requirements elicitation is gleaning a comprehensive and

accurate understanding of the projects business need. During the elicitation
process, an analysts strong understanding of the business need will help her
guard against scope creep and gold plating, as well as select the proper
stakeholders and elicitation techniques.
An analysts next step in eliciting requirements is ensuring that an adequate

amount and mix of stakeholders are secured for the projects duration. For, as
BABOK 2.0 (Business Analysis Body of Knowledge, the definitive guide to all
things related to business analysis) notes, a good analyst must actively engage
stakeholders in defining requirements. According to BABOK, a projects
stakeholders may include customers/end users, suppliers, the project manager,
quality analysis, regulators, project sponsors, operational support, domain
subject matter experts, and implementation subject matter experts. An analyst
must recruit the participation of appropriate stakeholders based on the unique
business needs of her project. After an analyst has identified and recruited her
stakeholders, and chosen the method(s) by which she will elicit requirements
(outlined below), it is advisable for her to schedule the time for conducting those
methods with stakeholders as far in advance as possible to ensure adequate

participation on their parts.
Elicitation Techniques
After securing the proper stakeholders, an analyst must determine the best
techniques for eliciting requirements. Commonly used requirements elicitation
methods (as identified by BABOK) include:
Brainstorming The purpose of gathering your stakeholders for brainstorming

is to produce numerous new ideas, and to derive from them themes for further
analysis [from BABOK]. An analyst should try to secure a representative from
each participating stakeholder group in the brainstorming session. If an analyst
serves as facilitator of a brainstorming session, she must ensure that while
participants feel free to propose new ideas and solutions, they remain focused on
the business need at hand and do not engage in scope creep, gold plating, or
become distracted with other business issues. All ideas must be recorded so that
they are not lost. According to BABOK, the brainstorming method is particularly
useful if your project has no clear winning choice for a solution, or if existing
proposed solutions are deemed inadequate. The brainstorming process and the
resulting follow-up analysis will help ensure that the best possible solution is
reached for any business objective.
Document analysis Document analysis involves gathering and reviewing all

existing documentation that is pertinent to your business objective or that may
hold data related to a relevant solution. According to BABOK, such
documentation may include, business plans, market studies, contracts, requests
for proposal, statements of work, memos, existing guidelines, procedures,
training guides, competing product literature, published comparative product
reviews, problem reports, customer suggestion logs, and existing system
specifications, among others. In other words, virtually anything that is written
related to the project may be useful. This type of elicitation is especially useful
when the goal is to update an existing system or when the understanding of an
existing system will enhance a new system. However, document analysis alone is
rarely enough to thoroughly extract all of the requirements for any given project.
Focus Group Focus groups consist of a mix of pre-qualified stakeholders who

gather to offer input on the business need at hand and its potential solutions.
Focus groups are particularly helpful when key stakeholders are not particularly
imaginative or forthcoming; a few more vocal stakeholders may help them think
through and articulate solutions. Focus groups are also a good way for timepressed analysts to get a lot of information at once. They may be conducted in
person or virtually. (Key project sponsors or business owners should still be
interviewed individually for thorough discovery.)
Interface Analysis An interface analysis carefully analyzes and deconstructs

the way that a user interacts with an application, or the way one application
interacts with another. According to BABOK, a thorough interface analysis will
describe the purpose of each interface involved and elicit high-level details about
it, including outlining its content. This type of elicitation is essential for software
solutions, which almost always involve applications interacting with one another
and/or users interacting with applications. But, according to BABOK, interface
analysis can also be useful for non-software solutions (such as defining
deliverables by third parties).
Interviews One-on-one interviews are among the most popular types of

requirements elicitation, and for good reason: they give an analyst the
opportunity to discuss in-depth a stakeholders thoughts and get his or her
perspective on the business need and the feasibility of potential solutions.
Research has found that interviews . . . are the most effective way of eliciting
requirements. Whether an analyst chooses to have a structured (with
predefined questions) or unstructured interview (with free-flowing, back-andforth conversation), she must fully understand the business need in order to
conduct a successful interview. It is a good practice for an analyst to share her
interview notes with the interviewee afterward to ensure there were no
misunderstandings and to jog the interviewees thoughts for any further insights.
Observation (job shadowing) Observation is quite helpful when considering

a project that will change or enhance current processes. According to BABOK,
two basic types of observation are available to an analyst: (1) passive
observation, where the analyst merely watches someone working but does not
interrupt or engage the worker in any way, and (2) active observation, where an
analyst asks questions throughout the process to be sure she understands and
even attempts portions of the work. The nature of an analysts project will dictate
the level of detail an observation should encompass. As with interviews, it is a
good practice for an analyst to provide notes from her observations and/or a
verbal description of her understanding of the work for the worker to review in
order to be sure that there were no misunderstandings of the process.
Prototyping (storyboarding, navigation flow, paper prototyping, screen

flows) Prototyping is especially valuable for stakeholders such as business
owners and end users who may not understand all of the technical aspects of
requirements, but will better relate to a visual representation of the end product.
To quote BABOK, Stakeholders often find prototyping to be a concrete means of
identifying, describing and validating their interface needs. The prototyping
process is normally iterative, improving as more input and evaluation are
gleaned from stakeholders. Prototyping may be an interactive screen (normally
consisting of hypertext only with no real data behind it), a mock-up (such as a
PowerPoint), a navigation flow (such as a Visio diagram), or a storyboard. Simple,
throwaway prototypes (such as pencil sketches) may be done in the initial stages
of discovery, and more detailed, interactive prototypes may be done once
business requirements have been identified. At the latter, more detailed

prototype stage,prototype features must fulfill previously identified business
needs as outlined in the requirements.
Requirements workshops A requirements workshop involves gathering a

previously identified stakeholders in a structured setting for a defined amount of
time in order to elicit, refine, and/or edit requirements. To be successful,
requirements workshops must include a recorder (or scribe) to record
participants input, and a facilitator to direct the discussion. Because
participants may also brainstorm together and listen to each others input, they
can provide immediate feedback and refinements to identified business needs,
which can ensure a fast, effective elicitation of requirements.
Survey/questionnaire While they preclude the opportunity for in-person, ad

hoc conversations, surveys are useful for quickly gathering data from a large
group of participants. Because free online survey software is readily available,
surveys are an inexpensive way to gather objective input from customers or
potential end users. As with selecting stakeholders, a successful survey or
questionnaire must have well-chosen participants. As one researcher notes,
questionnaires can be useful when the population is large enough, and the
issues addressed are clear enough to all concerned. Surveys can be structured
to offer a series of finite choices for feedback, or they can offer open-ended
input, depending on the needs of the project at hand. Open-ended surveys are
useful for a broader discovery of business needs; however, the larger the number
of participants in open-ended surveys, the more prohibitive they are to analyze.
Survey wording must be unambiguous and precise. It is good practice for an
analyst to politely request that survey participants respond by a reasonable
deadline and that they keep any proprietary business information contained
within the survey confidential.
Conduct Elicitation
An analysts projects business needs and the stakeholder mix will determine
which of the above elicitation method(s) are best. Elicitation does not normally
occur solely prior to requirements however; it occurs throughout a project
during discovery, modeling, and even testing. Whenever elicitation takes place
during a projects life cycle, the same principles apply to make it successfulthe
correct mix of stakeholders, a thorough understanding of the business need,
properly selected elicitation techniques, and meticulous attention to detail.
Confirm Elicitation Results
Once the elicitation methods have been employed, an analyst must document
the elicitation quickly, while it is still fresh in her mind, and share the results with
appropriate stakeholders to confirm their agreement with the findings. This stage
is essential to ensure that the analyst has accurately grasped, and stakeholders
have accurately communicated, the projects needs.
Elicitation serves as the underlying research to requirements creation phase.

Once an analyst has sufficient material, she can begin crafting requirements
INTERVIEWS
Interviews, either with an individual or with a group of people, offer the opportunity for
rich, detailed communication.
PREPARE
Define interview goal: Determine exactly why you are holding the interview
and what you want to achieve in it.
Select participants: Decide who needs to be involved in the interview in

order to achieve that goal.
Determine logistics: When and where will the interview be held, and how will
the interviewees be invited?
Design the interview: Decide on the format that is most appropriate for the
interviewees and the goal. Should it be structured with a detailed agenda and formal
set of questions, or unstructured with a looser agenda, depending more on ad hoc
interaction? Should the questions be open-ended requiring sentences or paragraphs
to answer, or closed-ended requiring short, even one-word answers?
CONDUCT THE INTERVIEW
Take time at the beginning to ensure that the interviewee(s) knows the purpose of
the interview, who you are, and what your role is. Wrap up the interview with
questions like "Is there anything else you would like to add?" and a hearty "Thank
you!"
FOLLOW UP
Like any other meeting, interview minutes should be published. This allows the
interviewees to see what you learned in the interview and validate that what you
heard is what they intended to say.
WORKSHOPS
A workshop is a structured method for interacting with a group of people. Workshops
can generate much information quickly if well facilitated and if participants are active.
PREPARE FOR WORKSHOP
Define purpose: Determine exactly why you are holding the workshop and
what you want to achieve in it.
Select participants: Decide who needs to participate in the workshop in

order to achieve that purpose. Make sure to consider the personality types involved
and ensure that you'll get participation from the entire group, not just a few dominant
people.
Determine logistics: When and where will the workshop be held, and how
will the participants be invited?
Conduct preliminary interviews: Some workshop methods include

collecting some information from the participants before the workshop to provide a
starting point. Such methods provide specific guidance about what preliminary
information should be collected.
CONDUCT THE WORKSHOP
Be sure to accurately capture all of the information that the workshop produces.
Depending on the size of the group, you may want to assign a record-keeper so you
can focus on facilitation
FOLLOW UP
Some types of workshops result in the assignment of action items to the facilitator or
participants, in which case, they must be managed to closure. The workshop results
should be published so the participants and other interested parties can see what
you learned in the workshop.
FOCUS GROUPS
A focus group is an interactive session with a carefully selected group of people
designed to capitalize on the synergy of a group.
PREPARE FOR THE FOCUS GROUP
Select participants: Decide who needs to participate in the focus group in

order to achieve its purpose.
Define roles, topics, and logistics: Define who (among the people running
the focus group) must do what, and the specific topics that the participants will
discuss. Also define the basic logistics such as when and where the focus group will
be held, and how the participants will be invited.
RUN THE FOCUS GROUP
Carefully facilitate the group to ensure free and open interaction among the
participants. Participants must feel free to interact openly or the focus group could
fail.
FOLLOW UP
The focus group report records what was learned, including both agreements and
disagreements among the participants.
BRAINSTORMING
Brainstorming is a method of quickly generating many creative ideas from a group of
people.
PREPARE FOR BRAINSTORMING
Define topics and time limits: Define precisely what will be the focus of the
brainstorming session, and how long it will be allowed to go on.
Select participants: Decide who needs to participate in the brainstorming

session in order to achieve its purpose.
Determine evaluation criteria: Decide how the ideas that come out of the
brainstorming session will be judged afterward. Be sure that the evaluation does not
go on during the brainstorming session.
CONDUCT BRAINSTORMING
Encourage a free flow of ideas. This requires careful facilitation to ensure that
participants feel comfortable with adding any idea to the list, and that no criticism or
even discussion of the ideas goes on during the brainstorming session.
FOLLOW UP
Apply the evaluation criteria to the ideas that were generated to reduce the list to only
those ideas that are reasonable or viable.
OBSERVATION
Observation is watching people as they go about their jobs. Observation can be an
effective way to gain a realistic and detailed understanding of how work is done in the
production environment; however, it is time consuming and may disrupt work.
PREPARE FOR OBSERVATION
Define goals and individuals to be observed: Decide what you are trying to
accomplish in the observation and who you should observe in order to achieve those
goals
Decide on mode: Observation may be done in either of two ways:

Passive/invisible: Observing in a way that does not disturb the
workers. "Invisible" refers to the fact that the workers are not even aware that
observation is taking place.
Active/visible: Interacting with those who are being observed. For
example, asking questions and having them describe what they are doing and why.
OBSERVE
If people believe that they are being evaluated, they are likely to do the work "by the
book," instead of the way they normally do it. So those who are being observed must
be assured that the observation is not for the purpose of judging them. As the
observation goes on, keep detailed records of what is observed and questions that
must be answered later.
FOLLOW UP
After obtaining answers to any remaining questions, publish the results of the
observation.
SURVEYS/QUESTIONNAIRES
Surveys allow you to collect information from many people in a relatively short
period. A survey can be an effective way to collect quantitative information; however,
writing the questions requires great skill and care to avoid ambiguity that could
compromise the utility of the results.
PREPARE FOR THE SURVEY
Define purpose, target people, and logistics: Decide what you are trying to
learn from the survey, who you should target in order to achieve those goals, and
how the survey should be distributed (for example, paper, e-mail, internet,
telephone).
Choose survey type:

Open-ended questions vs. closed-ended questions: Open-ended
surveys are more difficult to analyze, yet closed-ended surveys limit the responders'
options.
Anonymous vs. signed vs. optional: People may be more

forthcoming if they do not have to provide their names, but anonymity does not allow
for any follow-up questioning.
With vs. without pre-survey or post-survey interviews: Pre-survey

and post-survey interviews increase the valuable data that you can get from the
survey, but add significant effort.
Define target response level and follow-up activities: Getting many people
to respond to a survey is difficult. If you are expecting more than a small minority of
the target people to respond, it will require follow-up work beyond merely distributing
the survey.
Write questions: This step is more challenging than it sounds. Writing

questions that cannot be misinterpreted (resulting in misleading results) requires
great skill and concentrated effort.
Test the survey: Because it is so difficult to write questions well, it is

advisable to test the survey to see if people misinterpret any of the questions, and to
see if it provides the information that is sought.
DISTRIBUTE THE SURVEY
Get the survey into the target people's hands, and encourage them to respond. If
follow-up activities are planned to increase the response rates, do them.
FOLLOW UP
After the response period has ended, analyze the data, and summarize and report it
to the appropriate people.
Online Banking Survey

Your e-mail address:
1. Do you prefer Online banking?:

Well Informed/Much:
Enough/Little:
Nothing at all:
2. What type of account(s) do you have with Indiaone?:

SB Account:
Current Account:
NRI:
3. How important would Online Banking be in your daily banking activities?:

Significant:
Infrequent:
Not at all:
4. Which online service you think is more user friendly:

Internet Banking:
Telephone Banking:
ATM Services:
5. Do you think that Internet Banking is convenient?:

Yes:
No:
Not Sure:
6. What type of Banking would you do over the Internet?:

Personal Banking:
Business Transactions:
Both:
7. Of our Internet Banking features which would you use most? Make as many
selections as you wish.:
Inter Account Funds Transfer:
Bill Payments from Savings/DDA:
Savings/DDA/Term Deposits/Loans:
Stop and Hold Inquiries on Savings/DDA:
8. Are you aware of our Telephone Banking Services?:

Yes:
Yes, but not sure how to use the service:
No:
9. How often have you used our Telephone Banking service?:

All the time:
Regularly:
Balance on
Infrequently:
Not at all:
10. Do you know of our online 24hr ATM Services?:

Yes:
Yes, but not sure how to use the service:
No:
Not at
all:
11. How often do you log on to our website?:

All the Time:
Regularly:
Infrequently:
Not at all:
12. Have you had difficulty logging onto the bank's website?:
All the time:
Regularly:
Infrequently:
Not at all:
13. Is the information on the website updated often enough?:

Yes:
No:
14. If you answered NO, what improvements would you suggest

we make?:
15. Are the services being offered adequate?:

Yes:
No:
16. What other improvements would you like us to make?:

time
OK
Online Banking Questions:
1. Do you know about Online banking?

A) Yes.
B) No.
C) No response.
2. Have you ever used Online Banking?

A) Yes.
B) No.
C) No response.
3. Have you purchased anything through online?

A) Yes.
B) No.
C) No response.
4. Do you thing Internet Banking works very fast?
A) Yes.
B) No.
C) No response.
5. How frequently do you visit your branch per month?
Never
1 to 4 times
5 to 8 times
9 to 12 times
More than 12 times
6. How often do you use an ATM for activities other than withdrawal?
Never
1 to 4 times
5 to 8 times
9 to 12 times
More than 12 times
7. What is the
main reason you typically visit your bank?

Make a Deposit.
Investment advice
Balance Inquiry
Cash Withdrawal
Other
8. What features, while opening an account do you expect from bank?

Quick Services
Variety of Products.
Less formalities of Documents.
Proper Information.
9. What kind of account do you have in Indiaone bank?
Savings Account
Current Account
Fixed Deposits
NRI Account.
10.Who influenced to open bank account in Indiaone bank?

Bank Employees
Articles / Advertisements
Prospectus
Friend / Relative
11.Do you prefer paying utility bills over online?
Yes
NO
12.Your remark
on product of Indiaone Bank?

Excellent
Good
Average
Poor
13.Do you thing the number of counters available is sufficient?

Yes
No
14.Would you like to activate your online banking if it is launched?
Yes
No
15.What are the other features you would like to have in online banking?
1.
INTRODUCTION & OBJECTIVES

The main objective of the proposed solution is to be automated the various
functions and activities of the bank through Internet. The solution will facilitate to
the bank employees and the account holders with the different modules. This
solution is very much necessary for the private sector banks and the corporate
sector. The banking industry will take a new shape and explore like never before.
Using the solution the bankers and account holders can generate various kinds of
reports.
BUSINESS REQUIREMENTS:
Searching Capabilities:
For the account holders convenience and on hand information, this solution
provides certain searching and checking features for his account. The account
holder can any time and any number of time can log on and search for various
details as the accounts balance, details of transactions, interest amounts, debits /
credits, etc. The account holder will have his unique id and password for logging
on to the accounts information.
User friendly:
The solution provides very simple and modified features, which are very easy to
view and operate various features. The said project is designed and organized in
very simplified manner to suit the current requirements of the account holders of
various models such as Saving Bank Account, Current Account and Recurring
Deposit Account.
Transaction Management:
The transaction made through either net or manually in bank need to have a
consistency with respect to the account details and other related information like
transaction details across various databases.
Value Added Service
The solution provides good number of value added services in comparison to the
normal banking services. Account holder can view his accounts and give the
instructions of making payment to various government organizations for various
services. An account holder can issue the instructions to transfer certain amount
to any particular account number of the same / different bank. Individual can log
on to the site and open new bank account in his name online by following the
simplified registration form instructions
Security
The Net Banking system deals with a lot of proprietary information for its users,
which are confidential. It is therefore imperative to provide a means though which
information can be kept confidential. This is also ensures that the data that is put
into the system maintains its integrity because malicious or unauthorized
individual will not have access to alter them. The security is at two different
levels, one at account holder and other at administrative level at the banks
office.
2.i. IDENTIFICATION OF NEED

The Net Banking is a web-based application some of its features are pointed out
here:
The proposed system can be accessed from any part of the world, as opposed to
stand alone or manual system, and provides information at any time, anywhere
round the clock to the customers.
Even though it is a web-based application it will keep the details of its clients
private and no body is allowed to tinker with the details.
The customer needs to register, by which he is given user name and password
through which he can login and do the transactions whatever he wants to do. It
provides easy to use and user friendly interface for the user.
The system provides freedom to the user to move freely around various screens
and status of the system returned, as it was when he left the screen.
by expert personalities maintaining the web site.
The user can access the system at any time, because its 24-hour online from any
where in the world.
The customer can do all the work online without persisting him to go to the bank
like he can deposit the money, transfer amount from account to another account,
can get this available balance, able to see the transaction reports that has done
etc to mention a few.
The customer can save his money and time that is a valuable one in todays dayto day life.
2.ii. PRELIMINARY INVESTIGATION
1) New Account
Opening an account is possible through Internet. Account can be opened in the
following methods explained below.
Savings Account
Input
Customer Details.
Output
Alert message.
Current Account
Input
Customer Details.
Output
Alert message.
Credit Card
Customer needs to open a savings/current account bank account before opening
the credit card account. Credit card account will be linked with their
savings/current account. Customer needs to give their account detail when
applying for the credit card.
Input
Customer account details
Output
Alert message
Term Deposit
Term Deposit can be of two types: Flexible deposit and Cumulative deposit.
Flexible Deposit
Flexible deposit has links with the savings bank account.
Input
Customer details
Amount
Period
o Years
o Months
o Days
Renewal Option
o Repay the deposit
o Auto Renewal
Principal only
Principal along with interest

Output
Alert message.
Cumulative Deposit
Input
Customer details
Amount
Period
o Years
o Months
o Days
Output
Alert message
Recurring Deposit
Input
Customer details
Period
Installment amount
Output
Alert message
2) Teller Services
Customer can use the facility of Teller to receive the details of their account. Teller
services component provides the following services:
Account Summary
Transaction Details
Card Transaction
Interest Statement
Un Cleared Cheque
Account Summary
Customer can go to the Teller option and select the Account Summary. It provides
account summary of the customer. Account summary will be grouped as:
Regular Accounts
Investment Accounts
Loan Accounts
Credit card Account
On selecting the account summary field, the type of accounts field will be
displayed. Here the customer selects their account type and the account number
will be entered further. On entering these, the account summary is displayed.
Further, customer can enter from and to dates to see the opening balance and the
closing balance.
Input
Account Type
Account Number
Statement Duration
Output
Date
Description
Credit/Debit
Amount
Balance
3) Transaction Details
User can use the transaction details option to obtain the details of their particular
transactions.
Input
Account type
Account number
Period of transaction
Output
Transaction history for the specified period
Card Transaction
The card transaction option will be provided for displaying the card transaction
details.
Input
Card Type
Card Number
Period of transaction
Output
Card Number
Account Number
Expiry Date
Date of transaction
Pay To
Amount
4) Interest Statement
In this option, a customer receives statement on interest earned/debited in their
account for a particular period
Input
Account Type
Account Number
Interest type (accrued/credited/debited)
From and to dates
Output
Date
Description (loan no. or flexi deposit no etc)
Interest Accrued/Credited/Debited
Interest credited during last year
Interest credited during the current year
5) Un Cleared Cheque
Here, a customer gets report about the Un Cleared Cheque. A separate table is
being maintained for tracking cheque clearance.
Input
Account type
Account number
Output
Details of Un-Cleared Cheque:
Date
Drawn on
Cheque number
Amount
6) Transaction Services
This module offers two types of services:
Funds Transfer
Tax Payment
Funds Transfer
Customers can use this service for regular payment from one account to another.
Input
Origin account number

Destination account number
Destination Bank
Destination Branch
Transfer Amount
Frequency (One Time/Monthly/Quarterly/Yearly)
Transfer Date
Output
Alert message. In case if there is no sufficient fund in the origin account, the same
must be alerted to the customer.
Tax Payment
The Tax Payment component facilitates the customer to calculate tax payment
amount and remit the same to the tax collecting authority.
Options provided to the customer include:
Tax Payment request

Tax Payment modification
Tax Payment Cancellation
Input
Account Type
Account Number
Tax Payer ID
Taxing Period
Income during the above period
Tax Payment amount
Tax Collecting Authority
Output
Alert message.
7) Bill Payment Services
Bill Payment Service components facilitate customers to instruct the banks to
issue payment to their bills regularly against utilities such as electricity, gas,
water etc. Customer nominates the service provider to the bank, provided the
bank has a tie up with the provider. Service providers publish the bills to the bank
and the customers will be alerted subsequently. Bank will make payment to these
service providers as they get on line instructions from the customer. Bank debits
service charge from customers account for providing the service.
Following details will be displayed and the customer has multiple options to
choose:
Bill No.
Bill date
Bill period
Payee
Amount
Description
Select for payment (check box)
Customer has to select bills to be paid from the check box option. The customer
also gives the account number in which the amount has to be debited.
Output
Alert message will be displayed to the user showing the service charge amount
that will be debited from his account.
8) Other Payments
Other Payments component incorporates the following services:
Recurring Payments
Remittances
Recurring Payments
A customer can move the regular payment facility from one account to another.
Bank determines the service charge for providing the service to the user. It will be
displayed to the user for information to decide for utilizing the services provided
by the bank.
Here, the Customer instructs the bank to remit their recurring payment.
Input
User has to enter the following fields:
Payee Name
Payment frequency
Start date
End date
Payment Amount
Account Type
Account No.
Branch
Output
Alert message showing the service charge for providing the service.
Remittances
Following services are provided to the customer:
Transferring funds from one account to another within the bank.

Making remittances.
Service charges will be displayed for the customer to avail the facility and will be
determined by the bank.
Input
The customer provides following details:
Payee name
Payee bank name and branch

Payee account number
Amount
Account type
Account No.
Branch
Output
Alert message showing the service charge to be debited from the customers
account.
9) Requests
Under this module, the customer can request for the following services:
Cheque Reorder
New Card Request
Draft / Cashiers Cheque
Stop Payment
Cheque Reorder
In this case, the customer requests bank to issue a new chequebook and the bank
may charge the customer for it.
Input
Account Type
Account No.
Output
account.
New Card Request

In this process, the customer requests for a new card when he has lost his current
card.
Input
Card No.
Card Type
Lost on Date
Output
account.
Draft / Cashier Cheque

The customer requests bank to issue draft/cashiers cheque. Bank may deliver the
DD/cashiers cheque at users doorstep or payees doorstep. Bank will charge
customer accordingly.
Input
Options to user:
Draft
Cashiers cheque
Further, customer enters the following details:
Payee name
Drawn on
Amount
Delivery options
o Deliver at customers doorstep
o Deliver at payees doorstep
Payees address
o Door No.
o Street
o Area
o City
o PIN
Output
account.
Stop Payment
In this process, the customer informs the bank to hold payment for the cheques
he has issued.
Input
Account Number
Branch
Cheque No
Output
On entering the cheque number, following will be displayed:
Payee Name
Date of issue
Branch
Alert message also will be displayed to the customer with service charge.
10) Maintenance Services
Maintenance Services module comprises the following components:
Open another account

Close account
Modify account info
Modify customer info
Open Another Account
In this process, an existing customer opens another account.
Input
Customer ID
Customer details
Output
Alert message showing the new account number.
Close Account
In this process, an existing account holder closes his account.
Input
Account type
Account number
Branch
Reason
For remittance of balance
o Account Transfer
Account number
Bank name
Branch
o Cashiers cheque details
Output
Account summary will be presented to the customer. Check list will be provided to
the customer regarding pending standing instructions, pending Cheque etc.
Modify Account Info

In this process, a customer modifies his account information.
Input
Customer has to enter the following information:
Account type
Account number
Branch
Mode of operation
Account link
Threshold
Output
Alert message displaying that the account details have been modified.
Modify Customer Info

In this process, the customer wants to change information about him such as
address, phone number etc.
Input
Account type
Account number
Branch
Applicant number
Customer details
Output
Alert message showing that the customers details have been modified.
11) User Alerts
The User Alerts module consists of the following processes:
Credit card payment

Flexible deposit maturity
The module provides options to user to receive the alert messages. Customer
requests will be maintained in the database and the alert messages will be
triggered whenever required and reach the customer through email. In addition,
these alert messages will be consolidated and displayed when the user logs into
the application.
Credit Card Payment

User will be provided with two options:
Two days before the due date

One week before the due date
Input
Credit Card number
Bank name
Branch
Alert message option
Output
Alert message displaying that the customers request was processed.
Flexible Deposit Maturity

User will be provided with two options:
Two days before the date of maturity

One week before the date of maturity
Input
Account number
Amount
Start date
Maturity date
Bank
Branch
Output
Alert message displaying that the customers request was processed.
3.FEASIBILITY STUDY
All projects are feasible given unlimited resources and infinite time!
Unfortunately, the development of computer-based system or product is more
likely plagued by a scarcity of resources and difficult delivery dates. It is both
necessary and prudent to evaluate the feasibility of a project at the earliest
possible time. Months or years of effort, thousands or millions of dollars, and
untold professional embarrassment can be averted if an ill-conceived system is
recognized early in the definition phase.
Feasibility and risk analysis are related in many ways. If project risk is great the
feasibility of producing quality software is reduced. During product engineering,
however, we concentrate our attention on four primary areas of interest:
Technical Feasibility
This application in going to be used in an Internet environment called www (World
wide web). So, it is necessary to use a technology that is capable of providing the
networking facility to the application. This application as also able to work on
distributed environment. Application on developed with J2EE (Java 2 Enterprise
Edition platform) Technology. One major advantage in application is platform
neutral. We can deploy and used it in any operating system.
GUI is developed using HTML.to capture the information from the customer. HTML
is used to display the content on the browser. It uses TCP/IP protocol. It is an
interpreted language. It is very easy to develop a page/document using HTML
some RAD (Rapid Application Development) tools are provided to quickly
design/develop our application. So many objects such as button, text fields, and
text area etc are providing to capture the information from the customer.
We can use this application in any OS. They can have their own security and
transactional advantages. But are the responsible for selecting suitable and
secured OS, which is suitable to our application.
The back-end Oracle 8i and front-end application are platform independent. So we
can port this enterprise application in any environment. Both are having their
individual configuration to get better performance and backup issues.
Economical Feasibility
In present system customer need to go to billers place to pay the bill. So he/she
needs to spend some time to complete this protocol. It is time consuming process
some times customer not able to spend that much of time. In such case needs to
pay some additional payment to the biller for late payment.
If it is developed in electronic payment system, He can pay the bill from any
where in the world. No need to travel to pay the bills. For doing this process
electronically have to spend some time.
Operational Feasibility:
In our application front end is developed using GUI. So it is very easy to the
customer to enter the necessary information. But customer has some knowledge
on using web applications before going to use our application.
4. SOFTWARE ENGINEERING PARADIGM APPLIED

DESIGN SPECIFICATION
Design of software involves conceiving planning out and specifying the externally
observable characteristics of the software product. We have data design,
architectural design and user interface design in the design process. These are
explained in the following section. The goals of design process it to provide a blue
print for implementation, testing, and maintenance activities.
DATA DESIGN
The primary activity during data design is to select logical representations of data
objects identified during requirement analysis and software analysis. A data
dictionary explicitly on the elements of the data structure. A data dictionary
should be established and used to define both data and program design.
DESIGN METHODOLOGY
The two basic modern design strategies employed in software design are
1. Top Down Design
2. Bottom Up Design
Top Down Design is basically a decomposition process, which focuses on the flow
of control. At later stages it concern itself with the code production. The first step
is to study the overall aspects of the tasks at hand and to break it into a number
of independent modules. The second step is to break each one of these modules
further into independent sub-modules. The process is
Repeated one to obtain modules, which are small enough to group mentally and
to code in a straightforward manner. One important feature is that at each level
the details of the design at the lower level are hidden. Only the necessary data
and control that must be called back and forth over the interface are defined.
In a bottom-up design one first identifies and investigates parts of design that are
most difficult and necessary designed decision are made the reminder of the
design is tailored to fit around the design already chose for crucial part. It vaguely
represents a synthesis process explained in previous section.
One storage point of the top-down method is that it postpones details of the
decision until the last stage of the decision. It allows making small design changes
when the design is half way through. There is danger that the specifications will
be incompatible and this will not be discovered until late in the design process. By
contrast the bottom-up strategy first focuses on the crucial part so that feasibility
of the design is tested at early stage.
In mixing top-down and bottom-up design it often appears that we start in the
middle of the problem and work our way both up and down there. In a complex
problem, it is often difficult to decide how to modularize the various procedures in
such cases one might consider a list of system inputs and decide what functions
are necessary to process these inputs. This is called back to front design. Similarly
one can start with the required outputs and work backwards evolving so called
front-back design. We have applied both the top down and bottom up approach in
our design approach.
DATABASE DESIGN
Databases are normally implemented by using a package called a Data Base
Management System (DBMS). Each particular DBMS has somewhat unique
characteristics, and so such, general techniques for the design of database are
limited. One of the most useful methods of analyzing the data required by the
system for the data dictionary has developed from research into relational
database, particularly the work of E.F.Codd. this method of analyzing data is called
Normalization. Unnormalized data are converted into normalized data by three
stages. Each stage has a procedure to follow.
NORMALIZATION
The first stage is normalization is to reduce the data to its first normal form, by
removing repeating items showing them as separate records but including in
them the key fields of the original record.
The next stage of reduction to the second normal form is to check that the record,
which one is first normal form, all the items in each record are entirely dependent
on the key of the record. If a data item is not dependent on the key of the record,
but on the other data item, then it is removed with its key to form another record.
This is done until each record contains data items, which are entirely dependent
on the key of their record.
The final stage of the analysis, the reduction of third normal form involves
examining each record, which one is in second normal form to see whether any
items are mutually dependent. If there are any item there are removed to a
separate record leaving one of the items behind in the original record and using
that as the key in the newly created record.
BUSINESS MODELING:
The information flow among business function is modeled in a way that answers
the following questions: what information drives the business process? What
information is generated? What generate it? Where does the information go? Who
process it?
DATA MODELING:
The information flow defined as a process of the business modeling is refined into
a set of data objects that are needed to support the business. The characteristics
(called attributes) of each object are identified and relationships between these
objects are defined.
PROCESS MODELING:
The data objects defined in the data-modeling phase are transformed to achieve
the information flow necessary to implement a business function. Processing
description are created for addition, modifying, deleting, or retrieving a data
object.
THE LINEAR SEQUENTIAL MODEL:
The linear sequential model for software engineering some times called the
classic model or the water fall model, the linear sequential suggests a
systematic, sequential approach to software development that begins at eth
system level and process through analysis, design, coding, testing, and
maintenance.
The linear sequential model is the oldest and the most widely used paradigm for
software engineering. Modeled after the conventional engineering cycle, the linear
sequential model encompasses the following activities:
1) SYSTEM/INFORMATION ENGINEERING AND MODELLING:
Because software is always part of a larger system (or business), work begins
by establishing requirements for all system elements and then allocating some
subset of these requirements to software. This system view is essential when
software must interface with other elements such as hardware, people, and
databases.
System engineering and analysis encompasses requirements gathering at the
system level with a small amount of top-level analysis and design. Information
engineering encompasses requirements gathering at the strategic business level
and at the strategic business level and at the business area level.
2) SOFTWARE REQUIREMENTS ANALYSIS:
The requirements gathering process is intensified and focused specifically on
software. To understand the nature of the programs to be built, the software
Engineer must under stand the information domain for the software, as well as
required function, behavior, performance, and inter facing. Requirements for the
both the system and the software are documented and reviewed with the
customer.
3) DESIGN:
Software design is actually a multi step process that focuses on four distinct
attributes of a program: data structure, software architecture, interface
representations, and procedural detail. The design process translates
requirements into a representation of the software that can be assessed for
quality before code generation begins. Like requirements the design is
documented and becomes part of the software configuration.
4) CODE GENERATION:
The design must be translated into a machine-readable form. The code
generation step performs this task. If design is performed in a detailed manner,
code generation can be accomplished mechanistically.
5) TESTING:
Once code has been generated, program testing process focuses on the logical
internals of the software, assuring that all statements have been tested, and on
the functional externals that is, conducting tests to uncover errors and ensure that
defined input will produce actual results that agree with required results.
6) MAINTENANCE:
Software will undoubtedly undergo change after it is delivered to the customer.
Change will occur because errors have been encountered, because the software
must be adapted to accommodate changes in its external environment (e.g., a
change required because of a new operating system or peripheral devices), or
because the customer requires functional or performance enhancement. Software
maintenance reapplies each of the preceding phases to an existing program
rather than a new one
5. SOFTWARE AND HARDWARE SPECIFICATIONS

Net Banking System is a network-based application. When we talk about hardware
and software, we have to mention requirements on both the Client and Server
part.
Internet connection with 33.6 KBPS Modem.
Pentium 2.77 GHz. 40 GB HDD, 512 MB RAM (Server).
Any P.C with Windows compatibility, 64 MB RAM (Client).
JDK 1.4 Enterprise Edition (J2EE)
Weblogic version 7.0.
Enterprise Java Beans

JDBC/ODBC drivers installed.
Functional Java enabled browser.
Data Base (Oracle).
Operating System (Windows).
INTERNET TERMINOLOGY
Java and Internet:
The Internet helped catapult Java to the forefront of programming and Java in turn
has had a profound effect on the Internet. The reason is simple: Java expands the
universe of objects that can move about freely in cyberspace. In a network, there
are two broad categories of objects transmitted between the Server and your
Personal Computer: passive information and dynamic, active programs like an
object that can be transmitted to your computer, which is a dynamic, selfexecuting program. Such a program would be an active agent ton the client
computer, yet the server would initiate it. As desirable as dynamic, networked
programs are, they also present serious problems in the areas of security and
portability. Prior to Java cyberspace was effectively closed to half the entities that
now live there. Java addresses these concerns and doing so, has opened the door
to an exiting a new form of program.
The rise of server-side Java applications is one of the latest and most exciting
trends in Java programming. It was first hyped as a language for developing
elaborate client-side web content in the form of applets. Now, Java is coming into
its own as a language ideally suited for server-side development. Businesses in
particular have been quick to recognize Javas potential on the server-Java is
inherently suited for large client/server applications. The cross platform nature of
Java is extremely useful for organizations that have a heterogeneous collection of
servers running various flavors of the Unix of Windows operating systems. Javas
modern, object-oriented, memory-protected design allows developers to cut
development cycles and increase reliability. In addition, Javas built-in support for
networking and enterprise API provides access to legacy data, easing the
transition from older client/server systems.
Java Servlets are a key component of server-side java development. A Servlets is
a small, plug gable extension to a server that enhances the servers functionality.
Servlets allow developers to extend and customize and Java enabled server a web
server, a mail server, an application server, or any custom server with a hitherto
unknown degree of portability, flexibility and ease.
JAVA SERVER PAGE (JSP)
Java Server Pages is a simple, yet powerful technology for creating and
maintaining dynamic-content web pages. Based on the Java programming
language, Java Server Pages offers proven portability, open standards, and a
mature re-usable component model.
PORTABILITY
Java Server Pages files can be run on any web server or web-enabled application
server that provides support for them. Dubbed the JSP engine, this support
involves recognition, translation and management of the Java Server Pages
lifecycle and its interaction with associated components.
The JSP engine for a particular server might be built-in or might be provided
through a 3rd party add-on. As long as the server on which you plan to execute
the Java Server Pages supports the same specification level as that to which the
file was written, no change should be necessary as you move your files from
server to server. Note, however, that instructions for the setup and configuration
of the files may differ between files.
COMPOSITION
It was mentioned earlier that the Java Server Pages architecture could include
reusable Java components. The architecture also allows for the embedding of a
scripting language directly into the Java Server Pages file. The components
current supported include Java Beans and Serves. As the default scripting
language, Java Server Pages use the Java Programming language. This means that
scripting on the server side can take advantage of the full set of capabilities that
the Java programming language offers.
PROCESSING
A Java Server Pages file is essentially an HTML document with JSP scripting or
tags. It may have associated components in the form of. class, .jar, or .ser files-or it may not. The use of components is not required.
The Java Server Pages file has a .jsp extension to identify it to the server as a Java
Server Pages file. Before the page is served, the Java Server Pages syntax is
parsed and processed into a servlet on the server side. The servlet that is
generated, outputs real content in straight HTML for responding to the customer.
Because it is standard HTML, the dynamically generated response looks no
different to the customer browser than a static response.
ACCESS MODELS
A Java Server Pages file may be accessed in at least two different ways: A client
request comes directly into a Java Server Page.
In this scenario, suppose the page accessed reusable Java Bean components that
perform particular well-defined computations like accessing a database. The result
of the Beans computations, called result sets is stored within the Bean as
properties. The page uses such Beans to generate dynamic content and present it
back to the client. A request comes through a servlet.
The servlet generates the dynamic content. To handle the response to the client,
the servlet creates a Bean and stores the dynamic content (sometimes called the
result set) in the Bean. The servlet then invokes a Java Server Page that will
present the content along with the Bean containing the generated from the
servlet.
There are two APIs to support this model of request processing using Java Server
Pages. One API facilitates passing context between the invoking servlet and the
Java Server Page. The other API lets the invoking servlet specify which Java Server
Page to use.
In both of the above cases, the page could also contain any valid Java code. The
Java Server Pages architecture separation of content from presentation- -it does
not mandate it.
JDBC requires that the SQL statements be passed as Strings to Java methods. For
example, our application might present a menu of database tasks from which to
choose. After a task is selected, the application presents prompts and blanks for
filling information needed to carry out the selected task. With the requested input
typed in, the application then automatically invokes the necessary commands.
In this project we have implemented three-tier model, commands are sent to a
middle tier of services, which then send SQL statements to the database. The
database process the SQL statements and sends the results back to the middle
tier, which then sends them to the user. JDBC is important to allow database
access from a Java middle tier.
What Is JDBCTM?
JDBCTM is a JavaTM API for executing SQL statements. (As a point of interest, JDBC
is a trademarked name and is not an acronym; nevertheless, JDBC is often
thought of as standing for "Java Database Connectivity".) It consists of a set of
classes and interfaces written in the Java programming language. JDBC provides a
standard API for tool/database developers and makes it possible to write database
applications using a pure Java API.
Using JDBC, it is easy to send SQL statements to virtually any relational database.
In other words, with the JDBC API, it isn't necessary to write one program to
access a Sybase database, another program to access an Oracle database,
another program to access an Informix database, and so on. One can write a
single program using the JDBC API, and the program will be able to send SQL
statements to the appropriate database. And, with an application written in the
Java programming language, one also doesn't have to worry about writing
different applications to run on different platforms. The combination of Java and
JDBC lets a programmer write it once and run it anywhere.
Java being robust, secure, easy to use, easy to understand, and automatically
downloadable on a network, is an excellent language basis for database
applications. What is needed is a way for Java applications to talk to a variety of
different databases. JDBC is the mechanism for doing this.
JDBC extends what can be done in Java. For example, with Java and the JDBC API,
it is possible to publish a web page containing an applet that uses information
obtained from a remote database. Or an enterprise can use JDBC to connect all its
employees (even if they are using a conglomeration of Windows, Macintosh, and
UNIX machines) to one or more internal databases via an intranet. With more and
more programmers using the Java programming language, the need for easy
database access from Java is continuing to grow.
MIS managers like the combination of Java and JDBC because it makes
disseminating information easy and economical. Businesses can continue to use
their installed databases and access information easily even if it is stored on
different database management systems. Development time for new applications
is short. Installation and version control are greatly simplified. A programmer can
write an application or an update once, put it on the server, and everybody has
access to the latest version. And for businesses selling information services, Java
and JDBC offer a better way of getting out information updates to external
customers.
CONNECTION
A connection object represents a connection with a database. A connection
session includes the SQL statements that are executed and the results that are
returned over the connection. A single application can have one or more
connections with a single database, or it can have connections with many
different databases.
OPENING A CONNECTION
The standard way to establish a connection with a database is to call the method
DriverManager.getConnection. This method takes a string containing a URL. The
Driver Manager class, referred to a the JDBC management layer, attempts to
locate a driver than can connect to the database represented Driver classes, and
when the method get Connection is called, it checks with each driver in the list
until it finds one that can connect uses this URL to actually establish the
connection.
-usually the driver or the database connectivity mechanism, which may be supported by one or more drivers. A prominent
example of a sub protocol name is oracle, which has been reserved for URLs that specify thin-style data source names.
- a way to identify the database. The sub names can vary, depending on the sub protocol, and it can have a sub name with any
internal syntax the driver writer chooses. The point of a sub name is to give enough information to locate the database.
SENDING STATEMENT:
Once a connection is established, it is used to pass SQL statements to its underlying database. JDBC does not put any restrictions
on the kinds of SQL statements that can be sent; this provides a great deal of flexibility, allowing the use of database-specific
statements or even non-SQL statements. It requires, however, that the user be responsible for making sure that the underlying
database can process the SQL statements being sent and suffer the consequences if it cannot.
DRIVER MANAGER:
The Driver Manager class is the management layer of JDBC, working between the user and the drivers. It keeps track of the
drivers that are available and handles establishing a connection between a database and the appropriate driver. It addition, the
driver manager class attends to things like driver login time limits and the printing of log and tracing messages. The only method
in this class that a general programmer needs to use directly is DriverManager.getConnection. As its name implies, this method
establishes a connection to a database.
A JAVA2 Platform, Enterprise Edition Deployment
Acquiring a reference to a home object
Life cycle of a Stateful Session Bean(SFSB):
ORACLE 8i
Introduction to Oracle:
Any programing environment used to create containers, to manage human data, in the conceptualization as a Data Management
System. Traditionally, the block of human data being managed is called a Database. Hence, in very simple terms, these
programming environments can the conceptualized as Database Management Systems, in short DBM systems.
All Databases Management Systems (that is, Oracle is DBMS) allow users to create containers for data stories and management.
These containers are called cells. The minimum information that has to be given to Oracle for a suitable container to be
constructed, which can hold free from human data, is
The cell name
The cell length
Another name that programming environments use for a Cell is Field. These can the conceptualized as follows.
Basic Database Concepts:
A database is a corporate collection of data with some inherent meaning, designed, built and populated with data for a specific
purpose. A database stores data that is useful to us. This data is only a part of the entire data available in the world around us.
To be able to successfully design and maintain databases we have to do the following:
Identify which part of the worlds data is of interest to us.
Identify what specific objects in that part of the worlds data are of interest to us.
Identify a relationship between the objects.
Hence the objects, their attributes and the relationship between them that are of interest to us are still owed in the database that
is designed, built and populated with data for a specific purpose.
Characteristics of a Database Management System:
It represents a complex relationship between data.

Keeps a tight control of debtor redundancy.
Enforces user-defined rules to ensure integrity of table data.
Has a centralized data dictionary for the storage of information pertaining to data and its manipulation.
Ensures that data can be shared across applications.
Enforces data access authorization has automatic, intelligent backup and recovery procedures for data.
Have different interfaces via which users can manipulate data.
Relational Database Management:
A relational database management system uses only its relational capabilities to manage the information stored in its databases.
Information Representation:
All information stored in a relational database is represented only by data item values, which are stored in the tables that make
up the database. Associations between data items are not logically represented in any other way, such as the use of pointers
from one table to the other.
Logical accessibility:
Every data item value stored in relational database is accessible by stating the nature of the table it is stored in, the name of the
column under which it is stored and the value of the primary key that defines the row in which it is stored.
Representation of null values:
The database management system has a consistent method for representing null values. For example, null values for numeric
data must be distinct from zero or any other numeric and for the character data it must be different from a string of blanks or any
other character value.
Catalogue facilities:
The logical description of the relation database is represented in the same manner as ordinary data. This is done so that the
facilities of the relation database management system itself can be used to maintain database description.
Data Language:
The relational database management system may support many types of languages for describing data and accessing the
database. However, there must be at least one language that uses ordinary character strings to support the definition of data,
the definition of views, the manipulation of data, constraints on data integrity, information concerning authorization and the
boundaries for recovery of units.
View Updatability:
Any view that can be defined using combination of basic tables, that are theoretically updateable, these capital of being updated
by the relational database management system.
Insert, Update and Delete:
Any operand that describes the results of a single retrieval operation is capable of being applied to an insert update or delete
operation as well.
Physical data independence:
Changes made to physical storage representation or access methods do not require changes to be made to application
programmers.
Logical Data Independence:
Changes made to tables, that do not modify any data stored in that table, do not require changes to be made to application
programmers.
Integrity Constraints:
Constraints that apply to entity integrity and referential integrity are specifiable by the data language implemented by the
database management system and not by the statements coded into the application program.
Database Distribution:
The data language implemented by the relation database management system supports the ability to distribute the database
without requiring changes to be made to application programmers. This facility must be provided in the data language, whether
or not the database management system itself supports distributed databases.
Non- Subversion:
If the relational database management system supports facilities that allow application programmers to operate on the tables a
row at a time, an application programmer using this type access is prevented from by passing entity integrity or referential
integrity constraints that are defined for the database.
6.i. DATABASE DESIGN
1) ACCOUNT_TYPES Table contains details of different types of Accounts.
Field Name Data Type/Size Description

ACC_TYPE_CD Char(2) Account Type Code (Primary Key)*
ACC_TYPE_DESC Varchar(20) Account Type Description
MIN_AMT Number(5) Minimum Amount to Deposit
INTEREST_RATE Number(4,2) Rate of Interest
MIN_PERIOD Number(2) Minimum Period in Months
*Possible values are:

SB Saving Banks Account CA Current Account
CC Credit Card Account TD Term Deposit
RD Recurring Deposit
2) STATES Table contains details of the Indian States.

STATE_CD Char(2) State Code (Primary Key)
STATE_NAME Varchar(30) State Name
3) ACCOUNTS Table contains details of each Account.

ACCOUNT_NO Char(8) Account Number (Primary Key)
ACC_CAT Char(1) Account Category*
OPERATION_MODE Char(1) Operation Mode#
OPEN_DATE Date Opening Date
BALANCE_AMT Number(10,2) Balance Amount
INT_NAME Varchar(25) Introducers Name
INT_ACC_NO Char(8) Introducers Account Number
BRANCH Varchar(20) Introducers Branch
KNOW_APPLICANTS Number(2)) Introducer knows applicants since number of months
* Possible values include:

S Single J Joint C Custodial
# Possible values include:

S Self F Former/Survivor E Either/Survivor C
4) CUSTOMERS Table contains details of each Customer.

Cust_code Char(7) Customer Code (Primary Key)
APPLICANT_NO Number(1) Applicant Number (1 or 2 or 3)
ACCOUNT_NO Char(8) Account Number
ACCOUNT_NO2 Char(8) Second Account Number (Optional)
CUST_FNAME Varchar(25) Customers First Name
CUST_MNAME Varchar(25) Customers Middle Name
CUST_LNAME Varchar(25) Customers Last Name
HOUSE_NO Varchar(10) House Number
STREET1 Varchar(20) Street Name
STREET2 Varchar(20) Street Name
AREA Varchar(20) Area Name
CITY Varchar(20) City Name
PIN Char(6) PIN Code
STATE_CD Char(2) State Code
RES_PHONE Char(13) Residence Phone
CELL_PHONE Char(10) Cell Phone
EMAIL Varchar(30) E-Mail Address
NO_YEARS_ADDRESS Number(2) Number of years residing in the address

PROFESSION Varchar(20) Profession Name
ORGANIZATION Varchar(20) Organization Name
WORKING_SINCE Date Date since working
DESIGNATION Varchar(20) Designation Name
OFF_DOOR_NO Varchar(10) Office Door Number
OFF_STREET Varchar(20) Office Street Name
OFF_AREA Varchar(20) Office Area Name
OFF_CITY Varchar(20) Office City Name
OFF_PIN Char(6) Office PIN Code
OFF_STATE_CD Char(2) Office State Code
OFF_PHONE Char(13) Office Phone Number
PAN_GIRN Char(10) PAN/GIRN Number
GENDER Char(1) Gender (Male/Female)
BIRTH_DATE Date Date of Birth
MAR_STATUS Char(1) Marital Status
REL_FIRST_APP Varchar(10) Relationship with the First Application
EDUCATION Varchar(20) Educational Qualification
MONTHLY_INCOME Number(6) Monthly Income
GUARDIAN_NAME Varchar(25) Guardian Name
5) TERM_DEPOSITS Table contains details of Term Deposit Accounts

DEPOSIT_AMT Number(10,2) Deposit Amount
TENURE_YEARS Number(2) Tenure Years
TENURE_MONTHS Number(2) Tenure Months
TENURE_DAYS Number(2) Tenure Days
PAYMENT_PERIOD Char(1) Payment Period*
RENEWAL_OPTION Char(1) Renewal Option#

M Monthly Q Quarterly O On Maturity

P Principal only D Repay Deposit B Principal + Interest
6) TERM_DEPOSIT_ALERTS Table contains details of Alerts for Term Deposits.

ALERT_OPTION Char(1) Alert Option*

T Two days O One week (before the date of maturity)
7) TRANSACTIONS Table contains details of Credit and Debit Transactions.

TRANS_TYPE Char(1) Transaction Type*
TRANS_DESC Varchar2(30) Transaction Description
AMOUNT Number(10,2) Transaction Amount
TRANS_DATE Date Transaction Date
TRANS_MODE Char(1) Transaction Mode#

C Credit D Debit
C Cash Q Cheque D Demand Draft I Internet S Service Charge
8) NOMINEE Table contains details of Nominees.

NOM_NAME Varchar(25) Nominee Name
NOM_ADDR Varchar(40) Nominee Address
NOM_AGE Number(3) Nominee Age
RELATIONSHIP Varchar(10)) Relationship with Account Holder
9) CREDIT_CARDS Table contains details of Credit Card Accounts.

CREDIT_CARD_NO Char(10) Credit Card Number (Primary Key)
ISSUE_DATE Date Date of Issue
EXPIRY_DATE Date Date of Expiry
MAX_AMT Number(6) Maximum Credit Amount
STATUS Char(1) Status*

V Valid L Lost
10) CARD_TRANSACTIONS Table contains details of Card Transaction.

CREDIT_CARD_NO Char(10)
DESCRIPTION Varchar(50)
CREDIT_AMT Number(10,2)
CREDIT_DATE Date
PAYTO Varchar(30)
11) CREDIT_CARD_ALERTS Table contains details of Alerts for Credit Cards.

CREDIT_CARD_NO Char(10) Credit Card Number
ALERT_OPTION Char(1) Alert Option*

T Two days O One week (before the date of maturity)
12) RECURRING_DEPOSITS Table contains details of Recurring Deposit Accounts.

INSTAL_AMT Number(10,2) Installment Amount
TENURE_YEARS Number(2) Tenure Years
TENURE_MONTHS Number(2) Tenure Months
TENURE_DAYS Number(2) Tenure Days
13) LOAN_TYPES Table contains details of different Types of Loans.

LOAN_TYPE Char(3) Loan Type Code (Primary Key)
LOAN_DESC Varchar(20) Loan Type Description
INTEREST_RATE Number(4,2) Rate of Interest
14) LOANS Table contains details of Loans availed by different Account Holders.

LOAN_CODE Char(9) Loan Code (Primary Key)
LOAN_TYPE Char(3) Loan Type Code
APPLIED_DATE Date Date of applying for Loan
LOAN_PERIOD Number(3) Loan Period in Months
LOAN_AMT Number(6) Loan Amount
EMI Number(6) Equal Monthly Installments
DOC_DETAILS Long Document Details
STATUS Char(1) Status
NO_OF_INSTAL Number(3) Total Number of Installments
LAST_PAID Date Date of Last Payment
15) CHEQUES Table contains details of Cheques submitted by the Account Holders.

CHEQUE_NO Varchar(10) Cheque Number
PAYER_ACC_NO Char(8) Account Number of Payer
PAYER_BANK Varchar(20) Bank of Payer
PAYER_BRANCH Varchar(15) Branch of Payer Bank
PAYEE_ACC_NO Char(8) Account Number

CHEQUE_DATE Date Cheque Date
SUBMITTED_DATE Date Submitted Date
CHEQUE_AMT Number(10,2) Cheque Amount
STATUS Char(2) Status of Cheque
16) FUNDS_TRANSFERS Table contains details of Funds Transfers.

FUNDS_TRANS_CODE Char(10) Funds Transfer Code
ORIGIN_ACC_NO Char(8) Origin Account Number
TRANS_AMT Number(10,2) Transfer Amount
TRANS_DATE Date Transfer Date
DEST_ACC_NO Char(8) Destination Account Number
DEST_BANK Varchar2(20) Destination Bank Name
DEST_BRANCH Varchar2(20) Destination Bank Branch
FREQUENCY Char(1) Frequency of Transfer
INSTALMENTS Number(2) Number of Installments
17) TAX_PAYMENTS Table contains the details of Tax Payments.

TAX_PAY_CODE Char(10) Tax Payment Code
ORIGIN_ACC_NO Char(8) Origin Account Number
TAX_PAYER_ID Char(10) Tax Payer ID
TAX_PAY_DATE Date Tax Payment Date
TAX_FROM Date Tax From Date
TAX_TO Date Tax To Date
INCOME Number(10,2) Income during above period
TAX_AMOUNT Number(8,2) Tax Amount
TAX_AUTHORITY Varchar(30) Tax Authority
18) BILL_PAYMENTS Table contains the details of Bill Payments.

BILL_PAY_CODE Char(10) Bill Payment Code
BILL_NO Char(10) Bill Number
BILL_DATE Date Bill Date
BILL_FROM Date Bill From Date
BILL_TO Date Bill To Date
PAYEE Varchar(30) Payee Name
BILL_AMOUNT Number(10,2) Bill Amount
BILL_DESC Varchar(30) Bill Description
19) CHEQUE_REORDER Table contains the details of the Cheque Reorders.

CHEQ_RO_CODE Char(9) Cheque Reorder Code
REQUEST_DATE Date Request Date
20) DRAFT_CHEQUE Table contains the details of Drafts and Cheques Issued.

DD_OR_CHEQ Char(1) DD or Cheque
PAYEE Varchar(30) Payee Name
DRAWN_ON Date Drawn On Date
DD_CHEQ_NO Varchar(10) DD or Cheque Number
AMOUNT Number(10,2) Amount
DELIVERY Char(1) Delivery Option*
PAYEE_DOOR_NO Varchar(10) Payee Door Number
PAYEE_STREET Varchar(20) Payee Street
PAYEE_AREA Varchar(20) Payee Area
PAYEE_CITY Varchar(20) Payee City
PAYEE_PIN Char(6) Payee PIN Code
STATUS Char(1) Status

C Customers doorstep P Payees doorstep
Requirements while every project needs absolutely clear goals and objectives, the
detailed requirements which need to be implemented to achieve those goals are probably
not well understood in advance, and are likely to change over the life of the project
Understanding of the problem domain while accept that our understanding cannot
be complete and that the initial vision of the solution needs to be able to change as we learn
more about the realities of the problem area

Rate of delivery adaptive projects are largely creative in nature, and the teams are
trying to solve problems where the solution may not be readily understood up front, and
producing the solution requires invention. Individuals are not interchangeable and
productivity is not consistent across individuals
Adaptive projects require an adaptive approach to development that allows the product to evolve
as our understanding unfolds over the life of the project. The Iterative and Incremental way of
working on Agile projects provides the needed feedback mechanism[2] to deliver adaptive
projects.
Despite the adaptive nature of the Agile project ecosystem, it is reasonable and realistic that
management want to know how much will this cost and how long will it take. Organizational
resources need to be allocated to the project and decisions need to be made about what work to
undertake. This means we need to provide feedback at a number of levels to answer the initial
set of questions and on an ongoing basis through the project to ensure we are still delivering the
best value for our organization's investment.
To achieve this we need to plan at many levels.
There are two broad categories which planning happens in:
1.
The highest level of planning happens almost completely outside the team and this has
to do with selecting which initiatives should be funded doing the right work.
2.
Once a project has passed the should we do this? filter we need to focus on doing the
work right. This is where the five levels of planning on a project come in.
Doing the Right Work

This is about selecting which projects should get funded, and is represented by the graphic
below:
Innovations and Problems

Every organisation needs a mechanism to get work into the pipeline idea generation needs to
be encouraged and problems identified. At the initial idea/problem generation stage there should
be very little filtering, every member of the organisation should be able to point out something
that is not working in the most effective way, identify a problem the organisation needs to
address (such as a change in the marketplace or new legislation that we must comply with) or
propose a completely new thing that could be done.
After an idea has been raised there needs to be an initial high-level filter is this worth
considering any further. Frequently this is based on a very quick cost-benefit analysis and
feasibility assessment of the idea. Some ideas will automatically pass the first filter (a project that
is about compliance with a legislation change must be done, for instance), some are quickly
discarded (cost prohibitive or completely out of alignment with the organisations strategic
objectives) and some will be worth considering further.
Those that get automatic approval and those which are worth considering further should feed
into a Portfolio Planning process.
Portfolio Planning
Portfolio planning is a governance level activity which is about selecting the suite of programs
and projects which the organisation should fund at any given time. Inevitably there will be more
work requested than can be funded and the portfolio management process selects those which
will be funded.
Deciding which work to undertake should be based on the organisations mission and goals
work should only be funded that delivers on the strategy set at the highest levels in the
organisation. Portfolio planning is a risk-return based activity the organisations risk
management strategy helps select which pieces of work to fund.
Portfolio planning should happen above the level of any functional group in the business to
ensure the end-to-end impact and value of the selected work is considered. At this level projects
will impact many functional areas and it is important to avoid turf wars over jurisdiction. It is
likely that any significant piece of work at this level will impact and require resources from a
number of functional areas of the organisation (for instance launching a new customer selfservice website is not solely an IT project, there will be an IT component, marketing to promote
the use of the website, the service department to provide content for the knowledge engine, etc).
The portfolio process varies from organisation to organisation but should follow a clearly
understood process and provide guidelines to[3]:
1.
Build the portfolio of all projects
2.
Evaluate the projects quantitatively and qualitatively
3.
Decide which projects to fund now
4.
Rank order the portfolio
5.
Keep a running backlog of projects and actively manage the backlog based on new
project requests and completed work
Where the work to be undertaken crosses multiple functional areas of the organisation and
breaks into logical streams of related but independent activities then manage that set of projects
as a Program of work.
Program Management
A program requires additional coordination to keep the interrelated streams of work synchronised
the advertising campaign needs to be ready to run when the software is completed, the call
centre staff need to be employed and trained before the advertising campaign launches, the
software needs to be on the production server before the advertising campaign launches etc.
The program manager should be a dedicated role who has the strategic view of all the streams
of work that must come together to deliver to overall program. The program manager provides
the unifying vision for the separate project teams who will work on different streams of work.
The program manager is the ultimate customer for all the project teams, and sets overall
priorities and milestones.
Program management is an adaptive process as the program of work will need to respond to the
changing realities of the organisation and the actual delivery and throughput of the separate
project teams.
An overall program plan should be produced and maintained as things change. Key elements in
the program plan include (ref Manage IT chapter 14 page 279):
Overall product high-level requirements and goals/key features to be delivered

Organisational goals to be delivered on by the program
Costs & benefits across all aspects of the program
o
Marketing investment and approach
o
Sales approach
o
o
Likely revenues to be generated over the anticipated life of the product

Estimated costs to deliver across all the streams of work
o
o
Service, support and maintenance costs

Training for internal and external staff
Key milestones and high-level schedule for the program, including the ongoing release
cycle
Staffing profile across the various streams of work and time
Overall risk register for the whole program
Program management needs to provide direction for each of the streams of work. This is ideally
conveyed in a Product Vision that each team fully understands and commits to.
Doing the Work Right

This is about making sure that the team working on a product deliver against the product vision.
This is where the adaptive Agile team delivers business value on an iterative and incremental
basis.
This diagram shows how planning happens at a more and more detailed level:
The Product Vision

The product vision is the point where we move from governance and organisation-wide strategic
decision making to tactical delivery of products that result in changes to the way people in the
organisation work.
The product vision is a crucial tool that needs to convey to the team why they are working, what
they are working on and what key constraints they must work within.
The vision is often conveyed in a Project Charter document.
Ideally preparing the project charter should be a whole-team activity in a collaborative workshop.
The project sponsor and product owner should be present at this workshop and they are
responsible for articulating why the project is of importance to the organisation and what the key
measures of success are for delivery of the product.
Sanjiv Augustine describes the key question for the project vision as What do we hope to
achieve for the organisation with this project?[4]
The answer to this question will then guide all the work the team undertakes on the project, and
also tells the team when to stop work. The overall definition of done for the project should be
conveyed in the product vision.
Typical contents of the project charter include:
Problem/opportunity description and rationale why does this project matter to the
organisation?
What value will this project deliver to the organisation?
How does the project align with the organisations strategic goals?
High level solution description what are we trying to deliver?

Key features of the product to be built
Any assumptions that are driving this project

Technology or other constraints the project must work with
Scope what is included and what is excluded from this teams responsibilities?
Key timelines that the project should deliver against
Budget and cost-benefit analysis

Dependant & related projects and key milestones for coordination with those projects
especially important where this is part of a broader program of work

Risks associated with this project, with mitigation actions where appropriate
There are a number of simple tools that can be used in visioning workshops to help the
participants articulate and express the product vision. A few are listed below:
The Focusing Question or Elevator Statement

A one or two sentence statement that conveys the goals and objectives of the project.
The elevator statement is something that will enable any team member to explain the purpose
of the project in the time it takes to ride between floors in an elevator (imagine you get into the
elevator with the CEO of your company and are asked to explain what the project is you are
working on before the elevator gets to their floor).
During the workshop this is one of the first things that should be produced, and written up for all
to read it provides focus for the rest of the workshop activities.
The Vision Box

A Vision Box presents the features and benefits of the project as a box of cereal the front has a
name and branding, along with a list of the key benefits the product will convey to its buyers (the
customers who will eventually use the product, be they internal to the organisation or real paying
customers). The back of the box contains operating instructions (high level design decisions) and
a list of the key features the product will have.
Building a vision box is a creative activity that helps the team articulate what they are thinking
about. It can be useful to break into smaller groups and have the groups each build a vision box
that they then sell to the remainder of the team. After the separate presentations a shared
vision box should be produced that conveys the ideas of the whole team.
Business Benefits Matrix
A simple matrix which articulates the strategic value that the product is intended to provide. The
matrix looks like the following table:
Primary
Increase Revenue
Secondary
Tertiary
(25% revenue
increase within 12
months of launch)
Reduce/Avoid Costs
Improve Service
(n/a)
(Increase customer
satisfaction rating by 20%
based on quarterly
satisfaction survey results)
(Other)
(Reduce staff turnover in

call centre because of
customer satisfaction)
The goals of the project are expressed against the strategic drivers, there should only be one
primary driver and there might be a number of secondary or tertiary goals. Where there is more
than one goal in a column then they need to be ranked to avoid the everythings critical conflict.
Preparing this as a group activity helps the team to understand the clear and explicit focus for the
project.
Sliders
A tool for showing the priorities for the team across multiple dimensions.
The sliders range from Fully On to Fully Off if an element is On then it will be the strongest
factor that drives the decision making as the project continues. No two sliders can be set at the
same level, and the more sliders there are on the On side of the grid the higher the risk of
catastrophic failure this project accepts. Where there is little leeway in the project sliders then the
choice becomes deliver everything or deliver nothing, whereas more leeway allows for partial
delivery that contributes to the organisations goals.
Rob Thomsett describes the Slider tool in his book Radical Project Management.
Mike Cohn provides an online tool for setting sliders on his website
Scope Matrix
The in/out list is a simple tool that conveys clearly what will be done as part of this project, what
will not be done and where there is uncertainty about deliverables.
Where a topic is in the project team is responsible for delivery of this component.
Where something is explicitly out of scope the team will not spend any time or effort on this
component. If an out topic is something that the broader program of work is dependent on then
it is important that the responsibility for undertaking this work is clearly defined, the project
stream and person taking responsibility for ensuring this is delivered.
Where there is uncertainty about a topic being in scope or not then it goes into the Undecided
area. The team will not work on his piece and the product owner or project manager needs to
investigate further to identify if the piece of work is in or out of scope.
This tool is also explained in Radical Project Management, by Rob Thomsett.
Cost/Benefit Matrix
This should convey the level of uncertainty surrounding the estimates of both cost and benefit
the organisation will get from the project. Early in the project the costs will have a large Cone of
Uncertainty[5] and as the project progresses this will get narrower and narrower. It is likely that
the benefits also have a wide range of uncertainty. Uncertainty in both costs and benefits is not
necessarily a problem on a project provided the range is correct. Both costs and benefits should
be shown at three levels optimistic, likely and pessimistic. For example:
The figure in each cell is the net of benefit minus the cost.
This project should be considered high risk, as there is a distinct possibility that the organisation
will lose money on it. There might be other drivers which warrant the investment and the reward
profile if things go well is significant.
Undertaking cost/benefit analysis on a project is primarily a management level responsibility, but
the financial goals and drivers should be shared with the team.
Articulate the Vision

These tools can help teams gain a clear understanding of the goals and objectives that have
driven the selection of this project to be worked on.
Preparing the product vision is a very important starting point for the project. This provides the
focus for the work the team will undertake as the project continues. The wallware[6] artefacts
produced during the workshop(s) should form part of the team environment so anyone working
on the project can see at a glance the project drivers and goals. It may also be valuable to
produce a formal document that summarises the product vision. Remember that the value lies
only partly in the document but in the shared understanding that the team has achieved in
producing the vision.
If the team who will work on the product are distributed they should be brought together for the
production of the product vision this will help to create a one team culture and help with the
ongoing communication when they are dispersed.
Team members who join after the vision has been created need to be walked through the project
charter by someone who was present at the workshop(s) to help them understand the drivers
behind the work being undertaken.
Stewardship of the product vision is the responsibility of the product owner the person who
brings the business need to the project team. If during the execution of the project the
environment changes and the vision is no longer achievable or the organisation goals/drivers
change such that the project no longer delivers on them then the project should be stopped and
reassessed. Changes in the product vision are frequencly evidence of massive change in the
organisation ecosystem.
The Product Roadmap

The product roadmap is a list of the key features and characteristics that the product will need to
deliver in order to achieve the vision. The product roadmap is important where the project spans
a number of releases of the product. If there is only a single release then the product roadmap
and the release plan could be the same thing.
The product roadmap is a time-based view of the anticipated delivery lifecycle of the product. It is
a high-level plan maintained by the product owner and project manager that is expected to
change over time.
The product roadmap is regularly validated against the product vision and is used to convey to
the team and the outside world the likely release schedule for components of the product.
The product roadmap is at the level of features and epics user stories are not included.
A product roadmap should be expressed as a big visible chart that shows important milestones,
features and target release dates. As changes are made items are added, moved and removed
from the roadmap.
The picture below is an example of a product roadmap from a real project, showing two releases
over a six month period:
(Image credit - Livestock Improvement Corporation, New Zealand)

This roadmap is on the passage in the team environment and acts as an information radiator for
all the teams who are working on the program of work, and for anyone else who is interested in
the project. The product roadmap provides a context for the teams working on a single release.
The Release Plan

The release plan shows the features that are to be delivered in the current release of the
product. It contains the currently agreed prioritised list of features at the level of epics and
stories. The release plan is based around the teams anticipated velocity and conveys a shared
understanding about what needs to be included in the current release.
The initial release planning activity is undertaken by the team with the product owner providing
the goals for the current release. A release consists of a number of iterations during which the
team will undertake work to deliver a set of features that deliver measurable value to the
organisation. The set of features and capabilities make up the release criteria the subset of
overall product functionality and capability that is to be delivered in this release.
Stories and epics need to be sized (in story points[7] or ideal days) and prioritised so that the
work can be allocated to iterations. Release planning starts with the product owner explaining the
goals for the release. The team discusses what is needed to deliver against these goals and
expresses any other factors that need to be taken into account when delivering the release.
Other factors can include risk and dependency between epics and stories. High risk-high value
features should be prioritised for delivery early so the project can adapt should the risk evolve
into a problem (eg the technology cant actually do what we anticipated it would). Dependencies
might impact the sequence of delivery (if we do this piece first then that piece will be easier to do
later).
The teams velocity is used as the starting point for the release planning activity. If this is the first
release then the velocity needs to be estimated, for subsequent releases then the actual velocity
from the previous release should be used (unless the team changes significantly between
releases).
Identifying the estimated velocity is initially a guess the more accurate the guess needs to be
the longer it will take to come to the answer. The simplest approach is to ask the team how many
story points they think they can deliver in an iteration and plan based on that number. It will
probably be wrong, but it could be a good enough starting point.
To get a better estimate of the teams capacity to deliver, use more thorough estimation
techniques, understanding that more accuracy costs more to achieve and may not provide
significant benefit for the cost incurred James King provides a useful estimation toolkit
downloadable from his website:
Once you have the estimated velocity this can be used to plan the iterations as follows:
1.
List the stories and epics for the release in priority order with their size in story points
2.
Decide (from your estimation activity) how many story points can be delivered in a single
iteration
3.
Consider the impact of non-story work the team may need to undertake (for example it is
common that early iterations will be slowed down by not having all the tools and environments
the team needs in place)
4.
Add a new iteration to the plan
5.
Add stories to the iteration until the available capacity is consumed
6.
Ask have all the stories been addressed and the release goals achieved
7.
If not then add a new iteration to the plan and repeat steps 5 &6
8.
Once all the stories have been allocated, socialise the plan and ask for feedback from the
team is it sensible and achievable.
This process can be seen as a flowchart:
The release plan is an adaptive plan it WILL change as the project progresses.
Once the release plan has been produced and agreed to it is used to guide the work in the
iterations.
The release plan is also used to produce the initial target velocity graph for the project.
The Iteration Plan

At the beginning of every iteration the team is able to completely replan the project based on
what has been learned from the work done so far, and changes to the broader project
environement. The iteration planning session has two primary activities:
Validating and updating the release plan and
Making the iteration plan for the current iteration.
The first activity is to examine the current release plan and update it based on any changes that
have happened since the last update. The beginning of iterations is where an Agile project
adapts changes are made to the plan based around the actuality of the project environment.
Specific things that impact the revised release plan are:
Actual velocity of the work delivered in previous iterations is it faster or slower than was
originally planned; changes in velocity define the scope of work that can be undertaken in the
remaining time of the project

Changes in priority of existing stories and epics
New stories and epics that need to be introduced to the project because of changes in
the project ecosystem

Defects and technical debt[8] that have surfaced as the work is undertaken
New or changed stories that have surfaced as a result of risk identification

Hangover stories from the previous iteration that have not been completed
Non-project work that reduces the teams ability to undertake project tasks
The first part of the iteration planning meeting is to identify the currently most important set of
epics and stories that the team will work on during the iteration. The product owner explains the
current priorities and the reason behind the changes, to ensure that the whole team has a clear
understanding of why priorities have changed.
Once the list of stories and epics has been reprioritised and everyone on the team understands
the revised release plan, the team builds the detailed iteration plan for the work to be done in this
iteration.
The team estimates how much they will be able to complete in the iteration based on
yesterdays weather (it is very likely that they will complete the same amount of work in the next
iteration as they did in the previous iteration, unless something has significantly changed in the
working environment or team makeup) and common sense. They then pick the stories to be
worked on for the iteration based on the capacity to deliver work.
Once the set of stories and epics to be worked on is identified then the team breaks the work
down into specific tasks for each team member task allocation is ideally done on a pull basis
whereby team members identify the work they are able to do and select their own tasks. Tasks
should be very small from a few hours to a day or so, and are discrete measurable activities.
The iteration manager (Scrum Master in Scrum) confirms that all the tasks are allocated and
performs a sanity check on the work being committed to is it likely that the team will be able to
deliver what they are committing to given the reality of the project environment?
Once tasks have been identified the team members sequence and estimate them. Estimation is
now at the level of hours of work needed to undertake a single task. These tasks could then be
written up on task cards and the task cards tracked on the storywall.
Tasks are linked to stories, and tracking a story from one state to the next on the storywall should
be accompanied by the completion of the task for that activity.
Tasks include every piece of work needed to complete the stories in the iteration, and to start
preparing for the next iteration.
The Iteration Backlog is the list of stories and epics which will be tracked on the story wall for this
iteration.
An example of a partial list of tasks is shown below:
Story ID
Task
Who
S123
Elaborate story to acceptance

criteria
Bob, Mary,
Peter, Steve
S123
Build test cases from acceptance Mary
Estimated Remaining
Actual
Hours
Hours
Hours
criteria
S123
Design UI
Peter, Steve, 2
Bob
S123
Code UI
Peter, Steve
S123
Code Middleware
Peter, Steve
S123
Code Database
Peter, Steve
S123
Code Interface to Furblesplong Garth
system
S123
Integrate Furblesplong interface Peter, Steve, 2

into codebase
Garth
S123
Execute system tests
Mary
S123
Exploratory testing (system)
Mary
S123
Design acceptance tests
Bob, Mary
S123
Write release note
Peter
S123
Execute acceptance tests
Bob
S124
Story writing workshop to
Bob, Mary,
expand Epic into stories for next Peter, Steve

iteration
During the iteration team members report and track their work against the tasks. This is their
individual daily commitment.
A burn-down chart shows the initial estimate and remaining effort for the iteration. The actual
amount of time taken for each task can be tracked and used to help the team improve their
estimation in the next iteration planning meeting.
Daily Commitment
This is where the team members monitor their own progress and report against the tasks they
have committed to.
The Daily Standup is the primary communications tool for communicating progress within the
iteration. Every working day of the project the team gets together and reports to each other their
progress against the tasks they have committed to. The Daily Standup has a few simple rules:
It is held standing up
Maximum duration is 15 minutes
Each team member will speak for no more than one minute
Progress is reported against stories and tasks ONLY
Task reporting is binary a task is either Done or Not Done

Tasks that are not done are reported with hours/points/effort remaining to completion
Obstacles that are preventing a task from being undertaken or hindering progress are
reported separately
Each team member answers the following three questions:
o
What have you done since the previous meeting (with reference to the tasks, not
o
o
how you spent your day)?

What will you do before the next meeting?
What is in your way? (Nothing means you have confidence that you will deliver
the current task within the timeframe that was estimated for it)
If there are issues to be addressed they will be taken up AFTER the daily standup it is
common for the daily standup to be followed by a few short one-on-one sessions to address
specific issues
The iteration manager is primarily responsible for getting the obstacles removed so the
team can be fully productive
An Agile project must be a safe to fail environment team members will not be punished for not
meeting task commitments. It must be safe to tell the truth about task status and to learn from the
actuality of the project environment. Sometimes we will estimate badly (it is an ESTIMATE not a
quote) or something will happen that prevents someone from working on their task the
environment must make if OK to report the truth, as that way team members can adjust their
schedule and sequence of tasks and adapt to the realities of the project.
When all the tasks for a story have been completed the story will move into the Done state, and
the project velocity is credited with the story points for that piece of work.
Conclusion
In preparing for battle I have always found that plans are useless, but planning is
indispensable. Dwight David Eisenhower
This table summarises the levels of planning and the involvement in the planning process at
each level:
Individual
Daily
Commitment
Individual
task plan
Team
Extended
Project
Team
Sponsor
PMO
Strategy Group
Iteration Plan
Plan tasks Influence

and work
for this
iteration
Release Plan
Define release Influence

milestones
Product Vision
Define and
articulate
vision
Program
Review
Overall program
structure and
integration
Portfolio
Review
Pick which
projects to do
Influence
driven by
strategic goals
Strategy
Provide overall
Review
direction
Planning pervades Agile projects simple tools and safe environments support adaptive
planning and honest reporting which means progress is reported truthfully and management
have the information they need to make good decisions that enable the delivery of the best
outcomes for the organisation, team and project.
Agile planning takes into account that systems development is undertaken in complex and often
unpredictable environments and that flexibility and the ability to respond to change is paramount.
References
Agile Project Management Sanjiv Augustine
Agile Project Management Jim Highsmith

Manage IT Johanna Rothman
Manage Your Project Portfolio Johanna Rothman

Radical Project Management Rob Thomsett
Agile Estimation & Release Planning Software Education

This link
[1] We use the term predictive instead of the more emotive waterfall. Predictive projects are
ones in which the needs are not likely to change and where the work being done can be easily
identified and measured. An example of a predictive project would be the deployment of a new
operating system across all the computers in an organisation the amount of time and effort
needed for upgrading each computer is predictable and (to a certain extent) putting more people
on the work will result in a directly proportional reduction in the time needed. Adaptive projects
are those where requirements are likely to change and the work is largely creative with high
levels of uncertainty software development is an inherently adaptive process and does not
suite a predictive project framework.
[2] Alistair Cockburn provides a very valuable discussion of the meaning of Iterative and
Incremental iterative means subject to change, incremental means piece by piece. Agile
development is both iterative and incremental. See this link.
[3] Manage IT by Johanna Rothman Chapter 16, p 307
[4] Agile Project Management Sanjiv Augustine
[5] See this link
[6] Wallware refers to flipcharts, graphs, story cards and other artifacts that are prominently
displayed in and around the team space, they provide a visual record of the project, serving as
reminders of key decisions and visible to anyone who has an interest in the project. Other
commonly used terms are Information Radiators and Big Visible Charts.
[7] Story points are an estimation tool based on the relative level of effort and complexity involved
in delivering the product. Planning using story points takes advantage the power of collaboration
where each team members participates in evaluation of the user stories in terms of complexity.
Criteria such as difficulty of implementation, clarity of understanding and technical risks are
included in the estimate of the effort required to implement a particular story. This approach has
been found to o be much more effective than traditional one off estimates at the beginning of a
project.

Data

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Data

Hochgeladen von

Copyright:

Verfügbare Formate

http://www.esi-intl.com/searchresult?

A thorough discovery of business requirements is almost never readily

Prepare for Elicitation

The first step in requirements elicitation is gleaning a comprehensive and

An analysts next step in eliciting requirements is ensuring that an adequate

methods with stakeholders as far in advance as possible to ensure adequate

Brainstorming The purpose of gathering your stakeholders for brainstorming

Document analysis Document analysis involves gathering and reviewing all

Focus Group Focus groups consist of a mix of pre-qualified stakeholders who

Interface Analysis An interface analysis carefully analyzes and deconstructs

Interviews One-on-one interviews are among the most popular types of

Observation (job shadowing) Observation is quite helpful when considering

Prototyping (storyboarding, navigation flow, paper prototyping, screen

business requirements have been identified. At the latter, more detailed

Requirements workshops A requirements workshop involves gathering a

Survey/questionnaire While they preclude the opportunity for in-person, ad

Confirm Elicitation Results

Elicitation serves as the underlying research to requirements creation phase.

Select participants: Decide who needs to be involved in the interview in

Select participants: Decide who needs to participate in the workshop in

Conduct preliminary interviews: Some workshop methods include

Select participants: Decide who needs to participate in the focus group in

Select participants: Decide who needs to participate in the brainstorming

Decide on mode: Observation may be done in either of two ways:

Choose survey type:

Anonymous vs. signed vs. optional: People may be more

With vs. without pre-survey or post-survey interviews: Pre-survey

Write questions: This step is more challenging than it sounds. Writing

Test the survey: Because it is so difficult to write questions well, it is

Online Banking Survey

1. Do you prefer Online banking?:

2. What type of account(s) do you have with Indiaone?:

3. How important would Online Banking be in your daily banking activities?:

4. Which online service you think is more user friendly:

5. Do you think that Internet Banking is convenient?:

6. What type of Banking would you do over the Internet?:

Bill Payments from Savings/DDA:

Stop and Hold Inquiries on Savings/DDA:

8. Are you aware of our Telephone Banking Services?:

Yes, but not sure how to use the service:

9. How often have you used our Telephone Banking service?:

10. Do you know of our online 24hr ATM Services?:

Yes, but not sure how to use the service:

11. How often do you log on to our website?:

13. Is the information on the website updated often enough?:

14. If you answered NO, what improvements would you suggest

15. Are the services being offered adequate?:

16. What other improvements would you like us to make?:

Online Banking Questions:

1. Do you know about Online banking?

2. Have you ever used Online Banking?

3. Have you purchased anything through online?

main reason you typically visit your bank?

8. What features, while opening an account do you expect from bank?

10.Who influenced to open bank account in Indiaone bank?

on product of Indiaone Bank?

13.Do you thing the number of counters available is sufficient?

INTRODUCTION & OBJECTIVES

2.i. IDENTIFICATION OF NEED

Principal along with interest

Origin account number

Tax Payment request

Transferring funds from one account to another within the bank.

Payee bank name and branch