What were your responsibilities in your last project?

In the last project I worked as a Business Analyst for bank of New York. The bank
wanted to develop a private website with limited access to parties involved, so as to
streamline their bond trading operations. My prime responsibilities included:
Acting as a liaison between the users and the project management group.
Understanding the requirements and constraints from both sides.

Interviewing the users about their existing and potential processes, which they
are looking for in the new system.
Developing use case specification document and diagrams based on the
interviews.
Gathering the requirements and to develop the functional specification document
so as to list the features of the system users are looking for.
Developing the test plans and scenarios and recording the observations of the
users about the test and release.
Conducting JAD sessions in case there is something extremely critical or there is
some disconnect between users, stakeholders and PM team.

Have you been involved in compliance issues?

Basically if you look at compliances, they are nothing but different business
requirements. Since I have been working in the fixed income, there are a lot of SECs
requirements which need to be taken care of. As for example who should be given
what kind of access to the system, what path will the document follow and within
how much time the sanctions has to be done by an individual (Reg. T) etc. I made
sure that all these regulations should be inducted in the requirements documents and
has to be highlighted in the features of the system through the specification document.
I worked with the tech leads and the project teams to clarify all these requirements
and compliance issues and to generate certain business rules for them.

Tell me something about the project at the Deutsche Bank.

The relevant data were stored in multiple outdated customer repositories that did not
allow visibility to customers in other units of the client. The client's legacy system
included 1600 application interfaces and the challenge was to manage so many
interfaces and simultaneously streamline the migration process. Also, apart from
typical data quality issues, the existing system was also dependent on several other
applications and calling programs. This posed added complexity to the migration
exercise.

How did you document the requirements?

In gathering requirement I start with the reading of the
Scope document.
Vision document.
And any other related document.

Discuss with the project manager, his preferred approach to come with the
approach for business requirement.
I use several different methods to collect requirements, based on the kind of user I am
dealing with and his availability. Basically if there are several different users of the
same designation and performing same jobs, I prefer to conduct certain group
sessions, group interviews and focus interviews. In case if I have to interview a
manager or a VP I would take a one to one interview or if he is unavailable I would
send him a questionnaire online or shall do a telephonic interview. At certain points
of the projects, I also facilitate JAD sessions between the technical and non technical
groups. In certain extreme cases, I have also been a part of RDTs (Rapid
Development Teams), which are kind of JAD sessions but on an extremely fast
schedule.

What is a JAD?
Joint Application Development (JAD) is a management process which helps IS work
effectively with users to develop information technology solutions that really work.
Its purpose is to define the project, design a solution, and monitor the project until it
reaches completion. JAD Scope - The JAD should cover the complete development
life cycle of a system. The JAD is usually a 3 to 6 month well-defined project. For
large-scale projects, it is recommended that the project be approached incrementally,
and that separate JAD's be used for each increment.

Who do you invite in a JAD session?

Sponsor- The one who provides resources and support for the project
Business users- There are the users of the system being designed
System Analysts- they provide non-technical explanations to help JAD members
understand and fully utilize the technology available

Have you ever worked with the management?

Yes, I have worked with the top-level management at many different occasions. 1)
During the requirement-gathering phase, I had the opportunity to do 1 on 1 interview
with the business managers. 2) Kept good communication with the management
during the project phase. 3) Whenever there were any issues, I worked with the
project manager to resolve the issues. 4) I also had a chance to interact with the
managers during the requirement and project review meetings. 5) I made project
presentations to senior management during project review meetings.

What was the scope of the project?

The project was to develop a private secured website so as to facilitate the bond
initiation process. The access was kept limited to Trading Officers, Swap
Counterparties, Legal counsel, banks and few lending institutions. The scope was also
limited to the NY Office Private Wealth Management group.

There were certain things specified which were out of scope like the project was
limited to bond initiation process only. Routing of bonds to different exchanges was
not in scope although integration of the website with the TPS (Trade Processing
System was in scope).

What are the issues you came across during the project?
I believe that if the project is going extremely smooth, then there is definitely
something wrong. At every phase of the project you come across certain issues which
are sometimes pertaining to users and sometimes with the process and sometimes
with the PM group. Most common issues which I think every business analyst comes
across is changing requirements, which I think is healthy for the success of project if
you are managing them properly. I think it is extremely important to have a proper
change control process so that changing requirements can be traced and managed
properly through a proper channel.
Another challenge which I have experienced is the Mine First effect. Especially in a
multi release project, every user wants his requirements to be given the highest
priority. This is I think a little tricky to handle and you sometimes have to involve
managers and top management so as to clear the objectives and releases time by time,
phase by phase. I always make sure to ask the users their priorities and also match
them up with their managers and the vision documents, so as to find anything which
is out of scope or has already been identified. All the approvals are taken and
everyone is asked to review the documents.

How did you make sure that the requirements you gathered from the users are
exactly what they are looking for?
After every interview, and develop a preliminary draft of the requirements through
the use case document and functional specification document. These documents are
then sent to the user for their review for any disconnects and additional information.
After few drafts the final document is produced and matched with scope and vision
documents. The documents is then signed by the users and managers and put into a
formal system.

At the end of the project, was there any case when the user might have come up
and said this is not what I desired from the system? (In other words, they
expected more from the system.) How did you handle that? Did you enhance the
requirements and re-released the product?
This has happened once in my last to last project. The users expected a functionality
which was not considered in the first release. I went back to the requirements docs,
and showed them the priorities and specifications they have asked for. I always the
minutes of the meetings and the action taken over them, which also help to trace back
things and if there is any action which either the user or PM team has not taken.
In case the feature is important to the project, I discuss it with my PM or Tech lead
and ask the user to fill up a CRF (Change Request Form), through which we can ask
for additional budget/time or increase in scope.

What are Business Requirement Document, Use Case Specification Document

and Functional Specification Document?
Business Requirement Document
Business Requirement Document, which highlighted all the requirements, their risks
issues, the mitigation plans, the changes in the original plan etc.
Also known as the vision, this document gives the overall view of the system: main
characteristics, major features, key stakeholder needs, and key services provided.
Supplementary Requirements Specification
This document captures any requirements that cannot be tied directly to any specific
use case, and especially many of the nonfunctional requirements and design
constraints.
Use Case Specification Document
Use cases serve as a format to express functional requirements in sequence. A use
case is a sequence of actions performed by a system that yields an observable result (a
work output) of value to a particular actor. Use cases are especially good at
documenting functional software requirements.
Functional Specification Document
A Functional Specification document is a blueprint for like how we want a particular
project or application to look and work. It also details what the finished product will
do and how a user will interact with it. The Functional Specification is in essence a
contract between the business customer and the IT project team, describing from a
technical view what the customer expects.
We will translate the business requirements into system functionality in technical
terms. I, personally, worked with tech lead to come up with the high level
architecture. This system architecture can be broken down in functional modules
based on the requirements. These functional modules are component of the system,
which can be clearly distinguished from the other system. In between, initial
recommendation of the technology will also help in designing the functional
specification document. I documented the functional module behavior in use case
diagrams and use case scenarios.

How do you come up with functional specific documents?

After gathering all the requirements, with the help of tech leads functional specific
documents are prepared, which includes
Product description: Describes briefly why the software (or upgrade) is being
developed, and lists the most important features and capabilities
Product functional capabilities: Presents a list of the functions that the software
will be required to perform. The list of functional capabilities may be an updated
version of the capabilities listed in the Software Requirements Document.
User characteristics: Describes the intended users of the software in terms of job
function, specialized knowledge, or skill levels.

What is Conceptual, Logical and Physical designs?

Architecture Design- It describes the overall system design including the operating
environment, the development environment, and the components of the system. It is
divided into 3 parts:Conceptual Design It defines object usage scenarios, the input and output
parameters, the application high level feature requirements and high level relationship
among all the players in the system. The usage scenarios / use cases describe all the
participants and activities within a business environment that require a solution. The
Conceptual Design addresses that need by describing one or more alternative
solutions. This design statement is expressed in the context of the solution users, and
describes what the solution will do to support their activities.
Logical Design It identifies a set of objects and services as well as a user interface
and a logical database design. A logical design identifies and defines all the objects
and their behaviors, attributes, and relationships within the scope of the solution. The
goal of the logical design is to convert the contents of the usage scenarios and
conceptual design into an abstract model that identifies the cooperating logical
components that support the solution.
Physical Design The Physical Design is the application of real-world physical
design constraints applied to the Logical Design. This is developed by analyzing
which pieces of the Logical Design already exist in components, what can be reused
or modified, and what new pieces must be created. It identifies the final development
technology and packages the objects and services, user interfaces and physical
database design into components targeted for the identified technology platform.

Have you worked on any Rational tools?

I have normally worked on RUP methodology and Rational tools are based on the
same. I am quite well versed with Rational Rose for making use case diagrams, use
case documents, realizations etc. I have used Requisite pro for managing and
documenting the requirements. I have used SoDA for generating certain reports etc.

How far were you involved in the testing phase?

During the testing phase I was responsible for:
Developing Test Cases and Test Plans.
Recording the observations of the users and reporting them back to my manager.
Discussing any changes and updates with the user and if need arises handling the
Change Request procedures and tracking.

How do you decide which features to include in what releases?

Everyone wants there features to be release in the 1st iteration. We normally decide on
the features of the Ist release or any releases ahead on the basis of:
Business priority
st
What feature goes 1 based on the scope document.
st
Review with the business managers what they require in the 1 release and get
their approval.
Business complexity/Risk

What is your main strength or what do you think that you have accomplished in
your last project with which you are most proud of?
I think my strength is my ability to be organized and detail oriented. There are always
times when there are disconnects or constant changes in the project and in case if you
are not organizing your information and documents properly it might lead to a
disaster and failure. I am also quite detailed oriented which helps me to list the use
cases and requirements properly and comprehensively so that there is minimum
element of doubt.

What were the risks involved in the project? How did you come with the
solutions for those risks?
There were several risks involved in the project:

Securities Regulations: During this project there were a lot of regulations

involved which needed to be considered while developing the site. As for
example who should be given what kind of access to the system, what path will
the document follow and within how much time the sanctions has to be done by
an individual (Reg. T) etc. I made sure that all these regulations should be
inducted in the requirements documents and has to be highlighted in the features
of the system through the specification document.
The other risk was the site had to integrate the central trading application within
CO without changing current system logic.
Another risk was to follow a very formal business process as chartered by the
SEC. This was mitigated by various checkpoints and especially understanding the
current business process in detail by all of us in the team.
The dramatic fluctuations of trading volumes (from month-to-month and hour-tohour) needed to be accommodated

USE CASES REVIEW

What is Use Case?
A use case is a description of a set of sequences of actions, called scenarios that a system
performs to yield an observable result providing value to an actor. The individual use
cases represent functionality, or requirements of functionality of a system. Use Case
model is about describing what our system will do at a high level and with a user focus,
for the purpose of scoping the project and giving the application some structure. Any
increment that is planned is described in terms of the Use Cases.
What is the Use Case Diagram?
Use Case diagram is the graphical representation describing the functionality of a system.
It consists of actors and use cases. A use case describes a sequence of actions that provide
something of measurable value to an actor.
An actor is a person, organization, or external system that plays a role in one or more
interactions with your system. Actors are drawn as stick figures.
What is Use Case Realization?
Use Case scenarios are the scenarios which are used to depict the interactions of the use
cases with objects, classes etc. Scenarios are developed to identify various objects,
classes, and the object interaction needed to carry out a piece of the functionality
specified by the use case.
What is flow of events in the Use Case Diagram?
The two main parts of the flow of events are basic flow of events and alternative flows
of events. The basic flow of events should cover what "normally" happens when the use
case is performed. The alternative flows of events cover behavior of optional or
exceptional character in relation to the normal behavior, and also variations of the normal
behavior. You can think of the alternative flows of events as "detours" from the basic
flow of events, some of which will return to the basic flow of events and some of which
will end the execution of the use case.
Basic Path
One complete basic path from start to the end
Most commonly followed path that yields the most obvious value to the actor
Involves few exceptions
Alternate path
Deviations or exceptions from the basic path
Actor may choose to take different path
If multiple actors involved, the actions of one of the actor may influence the path of
actions for other actors.
The system may detect erroneous input from the actor

Use Case Glossary

Extension Use Case

A fragment use case that is used to add behavior to the base use case is called extension
use case and it is used to simplify the addition of behavior to an already complete use
case description.

Included Use Case

A use case used by two or more other use cases is called Included use case. They are used
to eliminate redundant description in two or more use cases.

Scenario
A scenario is a basic flow of events. It includes alternative flows if any.

Use- Case Storyboard

A visual use case description that depicts the flow of events with a sequenced series of
screen shots, often supplemented or annotated with the actual use case description. Used
to visualize the behavior of the system or to get feed back on a highly visual use-case
description.
What are artifacts?
Artifacts are the documents which are produced after each phase in the RUP
methodology. After every phase there are certain documents which needs to be furbished
which mark the end of the iteration or the phase. As for example you prepare a risk
assessment document and scope document during inception phase etc.
What is the difference between activity diagram and sequence diagram?
Activity Diagram shows different activities involved in the work flow. The sequence
diagram shows in what order they are related to each other.

What is an Object?
An object is a representation of an entity, either real world or conceptual. An object
can represent something concrete or a concept. It has some well defined boundaries
and meaning for an application. Each object has three characteristics: State, behavior
and identity.

What is a class?
A class is a description of a group of objects with common properties (attributes),
common behavior (operations), common relationships to other objects and common
semantics.

RUP Methodology
RUP or Rational Unified Process is a standard developmental process, which help in
describing the Business Model. It is a software package which helps in the various phases
of the business model. It can also be termed as a Software Development Life Cycle. It is
an iterative process which means a repetitive process.
RUP is generally structured along two dimensions, both of which are very important for a
successful completion of a project.
Time division of the life cycle into phases and iterations.
Process Component production of a specific set of artifacts with well defined
activities.
On the time dimension, The RUP can be divided into four major phases:
1. Inception.
2. Elaboration.
3. Construction.
4. Transition.
In the first or Inception phase, the project is visualized. The broad picture of the project
is drawn. A rough list of the various activities of the project is noted along with their
prime objectives. What kind of software, database or other technical details which needs
to be implemented are chalked out. How much budget should be allocated and what time
span will the project take is also broadly decided in this phase. What are the iterative
considerations that should be implemented is also decided in this phase. Whatever is
listed in this phase may not be finally implemented as well. In one word this is the basic
foundation of the project.
At the end of the inception phase is the first major project milestone.

Lifecycle Objectives Milestone

Stakeholder concurrence on scope definition and cost / schedule estimates

Agreement that the right set of requirements have been captured after the first
milestone following the inception phase (for example)

In the second or Elaboration phase, a lot of brain storming is done to polish the basic
guidelines of the project. The requirements are gathered in this phase from the
stakeholders, end users and everybody involved with the project. All the requirements are
scrutinized in detail, so that all the different possibilities can be taken into account. The
architectural configuration which will be implemented is also decided in this phase. The
requirements are gathered in various different techniques. At the end of this stage a firm
understanding of the whole project is derived and what needs to be solved is also
understood. Major risk analysis is also done at this stage. The various pre and post
conditions are also decided in this phase, along with the required iterations. The whole
team interacts and forms a good bonding from here on till the successful completion of
the project. The various use cases, actors and their relationship is given a lot of weightage
in this phase. A preliminary manual is also written. At this phase the stakeholders get a
good picture of the project and how it will be achieving their objective.

Lifecycle Architecture Milestone

At the end of the elaboration phase is the second important project milestone, the
Lifecycle Architecture Milestone. At this point, you examine the detailed system
objectives and scope, the choice of architecture, and the resolution of the major risks.
Evaluation Criteria
The product vision and requirements are stable
The architecture is stable
The key approaches to be used in test and evaluation are proven
Actual resource expenditure versus planned expenditure is acceptable.
In the third or Construction phase the most important task is done. Here the software is
coded. Most of the use case is written along with all its actors as well as their relationship
between them are mentioned. A lot of iterative operations are performed. Each iteration;
adds features to the software. A complete picture is obtained with most of the alternative
flows, probable flows and operations implemented in the software. The high risk factors
are considered and priorities are set. The basic flow is obtained so that the stakeholders
can have a first hand experience of the software and suggest specific changes which need
to be implemented in the final finished product. This feedback is very important in the
successful completion of the software. Testing of the software is also done in this stage
and a user manual is also documented. Most of the flaws in the software should be
encountered in this stage so that there is no problem once it is Okayed for transition and
release.

Initial Operational Capability Milestone

At the Initial Operational Capability Milestone, the product is ready to be handed over to
the Transition team. All functionality has been developed and all testing has been
completed. In addition to the software, a user manual has been developed, and there is a
description of the current release.
Evaluation Criteria

Whether product release stable and mature enough to be deployed in the user
community is checked

Actual resource expenditures versus planned is checked.

The final phase is Transition, where the final iterations are implemented before the
finished product is released to the stakeholder or the end user. Here also the beat testing
is done for one final time. In some cases, the match up with the legacy system is also
implemented. The legacy database is converted. The final manual is documented and

training to the users is initiated. The next upgrade decision is also made in this phase and
when it is needed to be implemented is also decided. The up gradation process again
repeats the above steps.

Product Release Milestone

At the end of transition phase is the fourth important project milestone, the Product
Release Milestone. At this point, you decide if the objectives were met, and if you
should start another development cycle.
Evaluation Criteria

User satisfaction is checked

Actual expenditure versus planned is checked.

What are the nice workflows of RUP?

There are nine core workflows in the RUP, which represents a partitioning of all workers
and activities into logical groupings. The first six are also termed as engineering
workflows and the last three are referred to as supporting workflows. The workflows are
as follows.
1. Business Modeling workflow here the business process is documented in the
business use cases.
2. Requirement workflow the various requirements are gathered from the
stakeholders as per their choice and integrated into the systems after a thorough
consensus is obtained from everybody involved in the project. All the use cases and
the actors are also identified. How the system will be developed is also decided in this
stage.
3. Analysis & Design workflow here the blueprint of the whole project is developed
and how the project will be done is decided. The source coding is also done at this
stage.
4. Implementation workflow here all the individual subsystem is integrated into the
whole system and implemented into an executable system.
5. Test workflow here the beta testing and all other testing is done to verify the
smooth running of the system. If any defects arise then it is also implemented into the
system.
6. Deployment workflow the basic thing done in this stage is delivering the flawless
finished product into the market along with proper manual documentations.
Installation is also undertaken at this stage.
7. Project Management workflow this manages the proper functioning of the whole
project from inception to the end without any hiccups. Risk analysis is also done here.
8. Configuration and Change Management workflow conflict of multiple users
using the same artifacts, multiple version integrations, enforcing specific
development techniques are undertaken in this workflow.
9. Environmental workflow this gives us the guidelines of which specific software is
best for the system.

What are the best practices of RUP?

There are six best practices of RUP:
Develop Iteratively.
Manage Requirement.
Use Component Architecture.
Model Visually.
Continuously verify Quality.
Manage Changes.

Rational Tools
What is SODA? (Software Documentation Automation)
Rational SODA is used for the automation of the software projects through out the life
cycle of a project. It increases the productivity by eliminating errors in the extraction of
the information. It retrieves information from various sources and use it to generate a
document or report according to a template.
What is ClearQuest?
Its a customizable defect and change request management system which is designed for
the dynamic environment of software development. With clearquest, we can manage
every type of change activity associated with software development.
What is clearcase?
It is a version control software. During the construction phase, when developer finishes
coding, they will send it to the clearcase for source code control.
What is Rose?
It is a visual modeling tool that facilitates use of the Unified Modeling Language. It helps
improve communication both within teams and across team boundaries, thereby reducing
development time and improving software quality.
How does Rational Unified Process relate to the Unified Modeling Language
(UML)?
The UML is a visual modeling language for software systems. Rational Unified Process
is a software engineering process that provides a disciplined approach to assigning and
managing tasks and responsibilities within a development organization. RUP uses the
UML visual notation and provides you with guidelines on how to use the UML
effectively. RUP has been developed hand-in-hand with the UML.
How do you integrate requirements?
Using Rational Rose tool

Q1) what was your responsibility?

A1) i worked as a business analyst for 4 years in bank one. I was given the opportunity to
build the enterprise reporting system to support.
A) Asset management.
B) Portfolio.
C) Risk management.
There are 3 main component of the system.
A) Extraction, transferring and loading. (etl).
B) Database.
C) Reporting
The main business area from which i collected the data was

A) Marketing.
B) Payment.
C) Getting credit beuro report.
D) Transaction summary FDR (first data).
My major responsibity lies in the reading of the
A) Scope document.
B) Vision document.
C) Any other document.
D) Arranging user manager meeting and gathering requirement.
E) Converting the business requirement into the functional requirement.
F) Carrying out the gap analysis.
G) And document the entire gathered requirement.
Coordinating with the tech-lead to design
A) Architectural design.
B) Logical design.
C) Physical design.
D) Documenting all designs in the design document.
Coordinating with the developers to develop the system
Providing help to quality assurance manager in designing
A) Test plan.
B) Test procedure.
Coordinating in providing support and maintenance for the system. And working with the
risk managers.
Q2) how do you collect the requirement?
A2) in gathering requirement i start with the reading of the
A) Scope document.
B) Vision document.
C) And any other related document.
D) Discuss with the project manager, his preferred approach to come with the
approach for business requirement. Describing the current business areas.
There are 3 main approaches:
A) Regular user meetings.
B) Interview individual business managers or key user managers on 1 on 1 basis.
C) Conduct JAD session.
A) Regular user meetings.
1) Find out the users from the related business manager based on the scope
document.
2) Arrange meeting by making the.
A) Agenda for the meeting.
B) Venue of the meeting
C) And the time at what meeting is held.
3) Taking down the notes at the time of meeting.
4) Bring out the outstanding issues that are not resolved.

5) Open issue documentation, finding out the person that can help in solving
them, getting the time from him.
B) 1 on 1 meeting.
1) All business manages have to be presented with the question list if they lie
in the scope of the project.
2) They are asked the time according to their convenience and the meeting is
arranged.
C) JAD sessions.
1) JAD session is the focus on the specific area generally takes up the
outstanding issues.
2) JAD session might have the it people involved.

Q3) how do you come with the functional document?

A3)
Q4) how many business area did you interacted?
A4) i interacted with 4 main business areas
A) Marketing.
Sending mails, emails, collection of there date etc.
B) Payment.
Customer payment, late payments, dues, etc.
C) Getting credit beuro report.
Buying the whole illegible population credit report and the credit score. Gives the
demographic data, life style etc.
Some of the credit beuros
1) Trans union.
2) Equi fax
3) Experian.
D) Transaction summary FDR (first data). Gives fico score.
Get the transaction report for the exiting customer of the fdr.
Q5) have you ever worked with the management?
A5) yes i have worked with the top-level management at many different occasions.
1) During the requirement gathering phase had the opportunity to do 1 on 1
interview with the top-level management.
2) Keep good communication with the managers during the project phase.
3) Whenever any issues come up worked with the project manager to resolve
the issue with the business manages.
4) Also interacted with the managers during the requirement and project
review meetings.
5) Gave functional requirement presentation on numerous occasions.
Q6) what is the most challenging thing that you faced?

A6) the kind of challenge I faced is a business challenge that is

1) Meeting the user expectations.
A) On delivery of the project the user might be expecting more.
B) In multi release all user want there features to go in the 1st release.
The user expectations can be met by
1) Review meeting at the end of requirement phase.
2) Documenting the reviewed requirements in the review document. Which
user managers review.
3) Getting the approval from user managers.
4) Keep the user and the managers updated with the latest status of reviewed
requirements.
5) In case any feature was missed out or a new feature is to be added in the
system or the scope changes then work out with the project manager and
change request form is to be filled. (CRF).
6) Keep updating about the design document with review, with the technical
person.

Q7) what is use case?

A7) a use case is a description of a set of sequences of actions, called scenarios, that a
system performs to yield an observable result providing value to an actor.
Q8) what is use case diagram?
A8) a use case diagram shows actors and use cases together with their relationships. The
individual use cases represent functionality, or requirements of functionality of a system.
Q9) what is flow of events in the use case?
A9) the flow of events of a use case contains the most important information derived
from use case modeling work. It should describe the use case's behavior clearly enough
for an outsider to easily understand.
The following represent some guidelines for the contents of the flow of events:

Describe how the use case starts and ends.

Describe what data is exchanged between the actor and the use case.
Do not describe the user interface.
Detail the flow of events. Remember that test designers are to use these to identify
test cases.

Structure

The two main parts of the flow of events are basic flow of events and alternative flows
of events. The basic flow of events should cover what "normally" happens when the use
case is performed. The alternative flows of events cover behavior of optional or
exceptional character in relation to the normal behavior, and also variations of the normal

behavior. You can think of the alternative flows of events as "detours" from the basic
flow of events, some of which will return to the basic flow of events and some of which
will end the execution of the use case.
Documenting

A flow of events document should be created for each use case. The format of the
document can vary depending primarily on how formal they are. The rational unified
process provides templates for documenting flow of events. Alternatively, soda can be
used.
Q10) how to convert business requirement in the functional requirement?
A10) work with the tech lead comes up with the high level architecture. These are the
components of the system, which has an input, an output, and there inter relationship.
System architecture is one, which can be broken down in functional modules based on
requirements.
Functional modules are component of the system, which can be clearly be distinguished
from the other system but has the interaction with the similar system. Can develop use
case for the different modules.
Q11) how do you know that you have collected the right data?
A11)
1) Review questions with the user managers and get their approval on the
review document.
2) Compare the review document with the request document they should
match.

Q12) how do u decide which iteration contains what features?

A12) cause everyone want there features to be release in the 1st iteration or the 1st release
is could be decided on the
A) Business priority:
1) What feature goes 1st based on the scope document.
2) Review with the business managers what they require in the 1st release and
get their approval.
C) Business complexity:
1) Depending on the business complexity what feature will come in what
release changes.

The following sample interview questions and answers are for the types of questions you should expect
during an interview for a business development research analyst position.
1. Can you give me an example of a project you were involved with that illustrates your
interest and skills in bringing people together?
I was the founder of the biotechnology club at my college. Although several other people cofounded the group, it was created at my initiative. We set up seminars where I got several key

people in the industry to come speak to us on hot topics in the industry - like the agricultural biotech
controversy and the ethical dimensions of stem cell research. The biotech club also sponsored a
career fair, where we got over 100 students, soon to graduate, connected with over a dozen
companies. I personally approached about half of those companies. I feel really proud about my
contribution to this project.
2. How would you value a biotech company as opposed to a consumer products company?
Most companies are valued based on their growth prospects. That's what determines their stock
price and overall dollar value, when they are sold. Biotech companies, as are other pharmaceutical
companies, are valued based on the perceived quality of the products in their pipelines. That's what
determines if they are going to have sustainable revenues and earnings. It's also why so many
Analysts on The Street pay such close attention to FDA pronouncements.
3. What kinds of metrics would you gauge to determine the financial, strategic and
operational health of a prospective alliance partner?
Several metrics are available in each sector you mention. To gauge the financial health of a
prospective partner, I would look at product sales growth or I might look at whether they've met
their milestones. To gauge strategic health, I'd consider their market share growth or, how well their
customers have access to the company. For operational health, I'd again look to see whether
they've met their milestones, how well they make decisions as gauged by the rating we give them
and how quickly they resolve conflicts. Good evaluations in these areas suggest that the
prospective alliance will be viable for both parties.

1. How would you describe yourself?

Sample excellent response:
My background to date has been centered around preparing myself to become the very best
financial consultant I can become. Let me tell you specifically how I've prepared myself. I am an
undergraduate student in finance and accounting at _________ University. My past experiences
has been in retail and higher education. Both aspects have prepared me well for this career.
2. What specific goals, including those related to your occupation, have you established
for your life?
Sample excellent response:
I want to be working for an excellent company like yours in a job in which I am managing
information. I plan to contribute my leadership, interpersonal, and technical skills. My long-range
career goal is to be the best information systems technician I can for the company I work for.
3. How has your college experience prepared you for a business career?
Sample excellent response:
I have prepared myself to transition into the the work force through real-world experience
involving travel abroad, internship, and entrepreneurial opportunities. While interning with a
private organization in Ecuador, I developed a 15-page marketing plan composed in Spanish that
recommended more effective ways the company could promote its services. I also traveled
abroad on two other occasions in which I researched the indigenous culture of the Mayan Indians
in Todos Santos, Guatemala, and participate din a total language immersion program in Costa
Rica. As you can see from my academic, extracurricular, and experiential background, I have
unconditionally committed myself to success as a marketing professional.
4. Please describe the ideal job for you following graduation.
Sample excellent response (equates ideal job with job he's interviewing for):
My ideal job is one that incorporates both my education and practical work skills to be the best I
can be. Namely combining my education in finance with my working knowledge of customer

service operations, entrepreneurial abilities, computer skills, and administrative skills. I want to
utilize my analytical expertise to help people meet their financial goals. This is exactly why I am
convinced that I would be a very valuable member of the Merrill Lynch team.
5. What influenced you to choose this career?
Sample excellent response:
My past experiences have shown me that I enjoy facing and overcoming the challenge of making
a sale. Without a doubt, once I have practiced my presentation and prepared myself for
objections, I feel very confident approaching people I don't know and convincing them that they
need my product. Lastly, I like sales because my potential for success is limited only by how
much of myself I dedicate toward my goal. If any profession is founded on self-determinism, it
surely must be sales.
6. At what point did you choose this career?
Sample excellent response:
I knew that I wanted to pursue information systems technology about my sophomore year in
college. It was then that I realized that my that my hobby (computers) was taking up most of my
time. My favorite courses were IT courses. I also realized that I was doing computer-oriented
work-study that I enjoyed so much I would have done it for free.
7. What specific goals have you established for your career?
Sample excellent response:
My goals include becoming a Certified Financial Advisor so I can obtain a better working
knowledge of financial research analysis, which would allow me contribute to my client base as a
better financial consultant since I would have that extra insight into the companies they are
seeking to invest in. Also this is the foundation block to advancing my career to portfolio manager
or even branch office manager.
8. What will it take to attain your goals, and what steps have you taken toward attaining
them?
Sample excellent response:
I've already done some research on other workers at Merrill Lynch to see how they achieved
similar goals. I know that Merrill Lynch encourages the pursuit and will reimburse for tuition of a
graduate degree. I plan on pursuing a MBA to give me an even more extensive knowledge of
business and financial analysis.

A Basic Use-Case Glossary

Alternative Flow
A use-case flow that describes some alternative or exceptional behavior something that
causes the system to deviate from the basic flow of events.
Basic Flow
The use-case flow that describes the most likely course of events the system will take
when the use case is performed.
Extension Use Case
A "fragment" use case that adds behavior to at least one other use case (referred to as the
"base" or "extended" use case). Extension is used to simplify the addition of behavior to
an already complete use case description.

Flow
A section of a use case description that describes some full or partial path through the use
case. A use case always has at least a basic flow and may have one or more alternative
flows.
Included Use Case
A "fragment" of a use case that is referred to by two or more other use cases (referred to
as the "base" or "including" use cases). Included use cases are used to eliminate
redundant description in two or more use cases.
Scenario
A scenario is a basic flow of events plus zero or more alternative flows.
Use Case
A use case is a description of how an actor or actors use a system to achieve a goal,
including what the system does for the actor or actors to achieve that goal.
Use-Case Storyboard
A visual use-case description that depicts the flow of events with a sequenced series of
screen shots, often supplemented or annotated with the actual use-case description. Used
to visualize the behavior of the
system or to gather feedback on a highly visual use-case description.
Use case FAQ
http://www106.ibm.com/developerworks/rational/library/content/RationalEdge/jan03/UseCaseF
AQS_TheRationalEdge_Jan2003.pdf

How does Rational Unified Process relate to the Unified Modeling Language
(UML)?
The UML is a visual modeling language for software systems. Rational Unified Process
is a software engineering process that provides a disciplined approach to assigning and
managing tasks and responsibilities within a development organization. RUP uses the
UML visual notation and provides you with guidelines on how to use the UML
effectively. RUP has been developed hand-in-hand with the UML.
RUP PDF
http://www.objectmentor.com/resources/articles/RUPvsXP.pdf
Phases
There are four phases to a RUP project: Inception, Elaboration, Construction, and
Transition. These phases represent a certain emphasis to the activities within an iteration.
Inception. In this phase, the goal of the iterations is to help the project team
decide what the true objectives of the project will be. The iterations will expore differnt
possible solutions, and different possible architectures. They will be used to
measure how quickly iterations can be done, so that the schedule can be calibrated.
It may be that all the physical work done in this phase is discarded. If the only thing
that survives the Inception phase is the increased knowledge of the team, then the
phase is a success.

Typically, however, several physical artifacts do indeed survive. Amongh these artifacts
may be:
A simple statement of major requirements, possibly in the form of use cases.
A rough picture of the software architecture.
A description of the project objectives.
A very preliminary project plan.
A business case for the project.
Life Cycle Objective Milestone. The Inception phase ends at the Life Cycle
Objective Milestone. This milestone is crossed when the project team and stakeholders
agree upon:
1. what the business need is, and what set of behaviors will satify that need.
2. a preliminary schedule of iterations.
3. a preliminary architecture
Though it may be common to wait till the end of an iteration to make these agreements,
this is not strictly necessary. Once the agreements can be made, the project
enters the Elaboration phase.
This event has no more significance other than that the project team and stakeholders
have agreed what the project objectives are. Crossing the milestone is not necessarily
accompanied by any change in activities. Indeed, for the average developer, the day
after the milestone ought to be very similar to the day before.
Some project managers may wish to schedule the end of the Inception phase. It
should be understood however, that crossing the milestone is not a matter of certainty.
Its simply a statement by the project team and stakeholders that the risk is low
enough to make a resonably confident decisions about what is to be built and how
long it might take. It shoudl also be understood that the time spent in the Inception
phase is not a good predictor of the time that will be spent in other phases. Indeed, it is
concievable that the Inception phase can be accomplished with no iterations at all,
taking virtually zero time.
Elaboration. The iterations in the Elaboration phase will:
Establish a firm understanding of the problem to be solved.
Establish the architectural foundation of the software
Calibrate and support a detailed plan of subsequent iterations.
Refine the process and gel the team.
Eliminate high risks.
The iterations produced in this phase are, on average, significantly less disposable
than those produced in the inception phase. Each iteration should be adding new features
to the growing body of software. Each iteratoin will also be adding new tests to
the growing body of verification software.
During this phase, stakholders will see real progress against the project plan, and they
will see the project plan becoming more and more stable and reliable. From iteration
to iteration, confidence in the project and the plan will increase.
High risk development items are tackled early in this phase. The goal is simply to
address these risks up front so that they dont catch the team later. Addressing the
risky items up front also calibrates the esimates in a conservative manner.
Four artifacts are sure to be produced by this phase:

1. the growing body of software in the form of an architectural prototype,

2. the test fixtures and verify the operation of the software,
3. the use cases that describe the majority of system behavior,
4. a detailed project plan describing subsequent iterations.
Other artifacts that may also be produced are:
5. a preliminary user manual,
6. a software architecture description.
Life Cycle Architecture Milestone. This milestone marks the end of the Elaboration
phase, and the beginning of the Construction phase. It is delineated by the
ability of the project team and stakeholders to agree that:
1. the use cases describe the detailed behavior that will address the business need,
2. the chosen architecture will scale to support the full software development,
3. the major risks have been addressed,
4. the project plan is achievable, and will achieve the project objectives.
Construction. The iterations in the construction phase are not much different
from the iterations of the Elaboration phase. Each iteration adds features to the software;
features that the stakeholders care about, and give feeback about.
During this phase, one would expect the use case descriptions to stabilize to a certain
extent; though in many project domains they will continue to change throughout the
lifetime of the project.
Use cases are added, iteration by iteration, to the software. This continues until the
stakeholders can reasonably make use of the system. The system may be far from
complete at this point. Indeed, the earlier the customer can start using the product in
anger, the better.
The artifacts that are produced during this phase are:
1. The software system.
2. The test fixtures.
3. The user manual(s).
Initial Operational Capability Milestone. Often called a beta release, this
milestone marks the end of the Construction phase and the beginning of the Transition
phase. This is not the end of the project, nor even close. Indeed, the project may
be much closer to its beginning than its end. This milestone is crossed when the
project team and stakeholders agree that:
1. the product is stable enough to be used,
2. the product provides at least some useful value,
3. all parties are otherwise ready to begin the transition.
Getting to this point as early as possible is important for a number of reasons. Transition
of a small system is a lot less risky than transition of a big system. This is especially
true if the big system remains operating except for the small part that the
nascent system can do. Developers will learn much more by watching the system in
production use.
Transition. The iterations in this phase continue to add features to the software.
However, in this case, those features a being added to a system that users are actively
using. Clearly, the stakeholders and the developers will have to negotiate how often

the production system can be upgraded. Short upgrade cycles are better than long
upgrade cycles however.
The artifacts produced in this phase are the same as those produced in the Construction
phase. The team is simply improving and enhancing the system towards the
objectives that were set at the end of the Inception phase.
Product Release Milestone. This milestone marks the end of the Transition
phase, and possibly the beginning of the next Inception phase. It is crossed when the
project team and the stakeholders agree that:
1. The objectives set during the Inception phase (and modified throughout the other
phases) have been met.
2. The user is satisfied (which may or may not be synonymous with point 1)

Fabrica
Executive Summary
What should a weaving mill do when a customer wants a sample of a new fabric
pattern? It seems like a reasonable request, and one that should be met quickly - a
yard or two is all that's needed. But a modem loom is scaled to hold yarn to make a
bare minimum 120 yards of cloth, and the smallest economical production run is
1,000 yards. Weaving the first couple of yards of sample takes only a few minutes,
but setting up the loom requires 67+ hours' labor and overtime - not counting
waiting time for a free loom in a busy mill. Today there are four ways out:
a) charge the customer as much as you dare of the $3,000 cost (in the US) of
making the sample;
b) make the sample for free, hoping the customer turns out to be worth it;
c) try to convince the customer to place a firm order without a sample; or
d) provide a computer-generated image of the pattern from a high-end color printer.
Fabrica has come into being to offer a true no-tradeoffs solution to the weaver's
quandary. In no more than three working days, for less than a sixth of the cost of
producing it on the mill's own looms.1, Fabrica can provide a sample woven to the
same pattern from the same yarns, dyed with the same dyes, as the finished
product. Production plans are unaffected - there's no need to annoy the customer
with talk about how expensive it is to make samples - response is immediate - and
the customer can assess the drape, color, texture and sheen of real fabric (all
impossible with computer printouts).
The secret to Fabrica's unique capability lies in 10 years of research and experiment
in textile engineering by inventor Dr. Sathit Putthachaiyong, our Director for
Research and Development. Over this time he perfected and patented a small dobby2
loom that embodies a unique constellation of features: it is cheap to construct, easy
to operate, highly reliable and produces fabric of the same quality as a large, modem
loom. This loom, the KS 16 can produce a sample of virtually any type of woven
fabric within as little as three hours from receipt of the design. This is not a
projection from specifications: it is a market-proven fact, confirmed by over 20
current industrial users.

Our market research has clearly confirmed what common sense suggested: weavers
(and also fabric traders and designers) are extremely eager to find a way to get their
customers production identical samples fast and affordably, As trade barriers fall and
fabric production migrates from country to country and continent to continent
following the opposing pulls of advanced technology and cheap labor, more and more
transactions are between comparative strangers. Excluding the very poorest
countries, annual woven textile production is about 49 billion meters, worth over
$200 billion exfactory.3 This amount of cloth involves a very conservatively estimated
12.5 million separate production runs, of which at least 2 million will be of woven
patterns.4
There is no direct competitor to Fabrica on the horizon, and we are convinced because the KS loom series is already far along the learning curve, and because of
the optimal combination of technical, entrepreneurial and managerial skills embodied
in our management team - that we can dominate our target market for many years,
and that by 2004 we can sell one Fabrica sample for every five patterned fabric
production runs in the major nations of the Americas, Asia, and Western Europe.

Year

YEAR
ASSETS
DIVIDENDS
EBIT
NET SALES

1999

2000

2001

2002

2003

2004

413,913 1,004,944 2,940,306 3,201,543 3,093,477

3,318,372

0 1,137,239 2,109,479 3,421,762

5,801,595

(105,703)

47,163 4,088,042 3,411,198 4,666,508

8,462,053

935,476 7,115,474 5,870,898 7,776,928 12,470,861

Our strategy of expansion by licensing, with licensees paying the entire cost of their
plants in advance, will permit us to grow rapidly while returning most of our earnings
to shareholders.5 The result is a business that will require initial investment of only
US$1,000,000 and yet grow to gross sales of $51 million in 2004, with an NPV of
$4.26 million, payback within 21 months and IRR of 176%.
The need to proceed with all possible speed and the near-total paralysis of Asian
financial systems have led us to seek Western venture financing for half the
company's equity, and to offer extremely attractive terms.
+ See graph on page 9
1 See cost comparison table in appendix A

2 The dobby is the mechanism that enables a loom to weave small figures or patterns into the fabric, such as are
commonly seen in checked or plaid shirting, women's blouses, neckties, household linen, upholstery.
3 These and other data on world textile production and trade from the International Textile Manufacturers'
Association 1998 World Data Summary, and from a proprietary market opportunity study by Decision Data Ltd.,
Bangkok.
4 Estimates of the patterned proportion of all woven fabric range from 3.4% to 6.5%, with average run length
estimates from 600 m to 1,334 m. These figures imply anywhere from 1.25 to 5.3 million production runs.
5 As Fabrica retains legal title to all KS looms and ancillary equipment installed for licensees, our balance sheet
gives the impression of heavy investment in plant From a risk-assessment perspective this is very misleading:
each increase in plant run by licensees produces immediate positive cashflow greater than the assets' book value,
with minimal contingent liability.