Rational Unified Process:

Inception:
 Defining the scope of the system
 validating initial costing and Budgeting
 Analyzing Business Context, Success Factors, and Financial Forecast is developed.
 Develop Business Case, A business Use case model, Project Plan, Initial Risk assessment
and project description (core project Requirements, Constraints and Key features).
 Stake holder’s Approval on Scope definition and cost schedule estimate.
 Requirements understanding as per the primary use cases.
 Credibility of the cost /Schedule estimates, priorities, risks and development process.
 Analyzing the architectural Proto type that has been developed.
 Establishing a baseline to compare actual expenditures Vs planned expenditures.
 If the project does not pass this milestone called “Life Cycle Objective mile stone” it can
be cancelled or repeated after it has been redesigned.

Elaboration:
 Primary objective is to mitigate the key risk items that are identified by analysis
 Project starts to take shape: the problem domain analysis is made and the architecture
of the project gets in to basic form.
 Use case models in which the use-cases and the actors have been identified and most of
the use cases descriptions are developed.
 Use case model should be 80% complete.
 Description of software architecture in software system development process.
 Business case and risk list which are revised.
 Development plan for overall project.
  Prototypes for each identified technical risk.
 After this stage the project the project transitions in to high risk operation where
changes are much more difficult.
 System architecture is the key output of elaboration stage.

Construction:
 Main objective is to build the software system.
 Main focus is on development of components and other features of the system.
 Most of the coding takes place.
 In Large projects several construction iterations may be developed in an effort to divide
the use cases in to manageable segments that provide demonstrable prototypes
 This phase provides the first external release of the software.
 Its conclusion is marked by initial operational capability milestone.

Transition:
 Transition of the system is from Development to Production
 Making it available and understand to the end user.
 Activities include training the end-users and Maintainer’s and beta testing the system to
validate it to the user’s expectations.
 The system will be tested against the Quality level set at the inception stage.
 If all the objectives are met the product release milestone is reached and development
life cycle ends.

6 Engineering Disciplines

Business modeling discipline:

 Describes how to describe the vision of the organization in which the system will be
deployed.
 How to then use the vision as a basis to outline the process, roles and responsibilities.
 Establish a better understanding and communication between the business need and
proposed system.
 Understand the structure and dynamics of the client.
 Their current problems and possible solutions for the client.

Requirements:
How to elicit stake holder requests and transform them in to set of requirements that includes
in the scope that the system would be built

Analysis & Design:

 Design a system that performs in a specific implementation environment the tasks and
funtions that are specified in the use- case descriptions.
  Fulfills all the client requirements
 Easy to change when functional requirements change.

Implementation:
 Implementing subsystems that are organized in layers.
 To implement classes and objects in terms of components (source file, binaries,
executables etc)
 To test the developed components as units.
 To integrate the systems developed by different teams in to a executable system.
 The process describes how to reuse the existing components with well-defined
responsibility.

Test:
 To verify the interaction between the objects.
 To verify the proper integration of all the software.
 To verify all requirements have been correctly implemented.
 To identify and ensure defects are addressed prior to the deployment of the software.
 Ensure all defects are fixed, retested and closed.
 Testing occurs throughout the process.
 Tests are carried out along 4 quality dimensions
o Reliability
o Functionality
o Application Performance
o System Performance

Deployment
 Purpose is to successful product release and delivers the software to end users.
 External release of the software
 Packaging the software & business application
 Distributing & Installing the software
 Providing help and assistance to the users
Basic things a BA should know
1. What is a requirement?
a. A requirement is anything that is important enough to discuss, analyze, document and
validate.
b. The intent and the stake holder need that make it a requirement.
c. Core Requirement components
i. People
ii. Information
iii. Process
iv. Rules
2. What are the techniques for eliciting, analyzing and presenting requirements?
3. Who are stakeholders and what is a BA responsibility towards them?
4. How is business problems solved?
5. What technologies are available?

Six Key Characteristics of a Senior Business

Analyst:

1. Business Analysis Techniques: Breadth and Depth of Knowledge and Experience

As BAs we need to have knowledge and experience in the various techniques to elicit, analyze
and communicate requirements.  We need a large tool box which we can pull from to meet the
specific needs of each project.  Without this large tool box your ability to perform at a high level
for any project type that you are a part of is limited. Take a look through the IIBA's BABOK® to
see how large your toolbox is.   

I have been asked by BAs who focus on specific areas, like facilitation or process modeling, if I
felt they were senior BAs.  My answer is no.  They are most definitely senior facilitators or
senior process modelers, but senior BAs need a broader, deeper skill set.  

2. Project Types and Business Area Experience

Senior level BAs need experience working on multiple project types.  At the highest level there
are three types of projects I feel are necessary, COTS (commercial off the shelf), new
development, and enhancements/support.  Each of these project types requires some different
techniques and skills.  Having worked on different types of projects gives you the knowledge of
which techniques work best for each project type. This will aid in planning which is
characteristic number three, coming up next. 
Working in multiple business areas within a company helps lay the foundation for strategic
thinking, characteristic number four.  By being involved in multiple business areas you start to
see overlapping functions and interdepartmental dependencies. This allows you to start
recommending solutions that benefit the whole company, not just the specific business area
you are involved in.

3. Business Analysis Planning

How do you answer the following question when you are first assigned to a project? "How long
will the analysis effort take?"  Senior BAs respond to that question with an intelligent business
analysis work plan. They think through the people they will be working with. They identify the
stakeholders, get to know them and understand key characteristics to best work with them. 
They think through critical project characteristics like the size of the project, the business risks
involved, and how many interfaces the project will include.  They think through the processes
that need to be adhered to for the project.  They make sure they understand what project
methodology is being used for the project, project roles and responsibilities, and what
deliverables are required.  Thinking through the people, project, and process gives you the
ability to outline the tasks and deliverables needed for the project, to estimate their time
needed, as well as the time of the stakeholders involved.

4. Strategic Thinking
A senior BA needs to see the big picture and do a deep dive for the project.  Senior BAs will try
to see the bigger picture before heading into the details trying to understand where this project
fits in with the organizational goals.  They will also be aware of, or try to determine how the
project they are assigned to impacts other projects or business areas.  They also take a look at
the big picture during the project.
In an earlier post, Get Your Head Out of the Weeds, I highlighted the need for BAs to find ways
to pull themselves out of the detail during a project to ensure their project is still meeting the
needs of the organization.

5. Advocate and Advisor

Many BAs report into IT departments, but still need to be viewed as part of the business team
they support.  You work for the business and need to truly be an advocate for the business and
their needs.  I'm sure many of you can tell stories where there was conflict between the
technology team and the business.  A senior BA steps up to resolve the conflict to provide the
best solution for the business. 

A way to know you have this characteristic is if the business calls you for advice before and
after a project.  Do you have discussions with the business to determine what's most important
for an upcoming project? Do you attend their staff meetings to find out their pains and to
understand their values and goals?

6. Ability to Learn a New Domain

 The need to have domain experience for BAs is one of the biggest debates in our profession.  I
do think you need some domain knowledge prior to starting a project, but that does not mean
you need to have worked in that domain for years.  I believe a senior BA needs to be able to
learn a new domain to be effective.  Here are three ways that I primarily use to learn new
domains prior to an interview or starting a project.

 Google: There is so much information out there at your finger tips. Google the subject
you need and take an afternoon reading.
 My network: I am a big believer that I don't need to know everything; I just need to
know the people that have the answers. I use my network to help answer questions I have to
learn about a domain. Continue to build your network.
 Personal experience: I may not have worked in banking, but I do interact with banks as
a consumer. I draw from my personal experiences to help understand a domain.

General Documentation Tools

a. Rational Rose, Star UML, Microsoft Visio – UML modeling tool

b. Rational ReqPro – Requirement Management
c. Rational ClearCase – Revision control of source code
d. Rational ClearQuest – Change Management
e. iRise Studio 7.0 Modeling, simulation and requirements tool  
f. PVCS / Serena
g. Documentum

BA’s work with the below people

Project Initiation

The components of a complete project initiation analysis are:

1. Approach or methodology
a. This is simply an acknowledgment/description of how the project work will
be done. It is a paragraph or two describing the overall approach that will
be taken by the team.(RUP etc.)
2. Statement of purpose
a. This is a short description of the project focused on explaining why the
project has been initiated /approved/funded.
b. It is the elevator speech
c. This description may be referred as the problem description , vision
statement or project request
3. Objectives:
a. Specific goal or outcome of the project.
4. Problems/opportunities:
a. projects are typically initiated in response to a business problem or
opportunity

5. Stakeholders (all SMEs and team members):

a. The list of stakeholders should be included in the project initiation
ocumentation.

6. Business risks:
 a. potential problems/events that may impact the success of the business
with respect to the project

7. Items out of scope:

a. Explicitly stating that particular items will not be addressed clearly sets
expectations about these items and also tells stakeholders that the
items/requests were heard and not ignored.

8. Assumptions:

a. Another optional section of the project initiation is assumptions, or facts

that are assumed to be true and will remain true for the duration of the
project.

9. Scope of the business area (external interactions and high-level processes)

a. Scoping the analysis area using a context-level data flow diagram
b. Area of study
c. High-level business processes
d. Scoping the analysis area using a use case diagram

Scoping the Analysis Area Using a Context-Level Data Flow Diagram

 BA understands how to determine and document the scope of the area to

analyze.
 Scoping helps set boundaries around the area of study and keeps the team
focused.
  Organizational units that will interface with the project (external agents)
 Existing enterprise applications that may require an interface to the project
(external agents or interactions)
 Personnel, customers, vendors, etc. that will be involved with the project
(external agents)
 The name of the project or area of study (the circle)
 Information that flows into and out of the project (arrows)

Area of study:
 Ideally, instead of thinking of the center circle in a context-level data flow
diagram as the project, the BA should think of it as his or her area of study.
High-level business processes:
 A process is an activity performed by a business that transforms information
(data)
 Processes may be named and described at various levels of detail. During
scoping, high-level processes should be named and listed with the context-level
data flow diagram.

Scoping the analysis area using a use case diagram:

  The BA uses the scope diagram to remind himself or herself and the SME to stay
on topic.
 This will keep everyone on the team focused on the agreed-upon scope.
 The documented scope should be formally reviewed and approved before the BA
begins detailed requirements work.

HOW A BUSINESS ANALYST LEARNS THE BUSINESS: Elicitation Techniques

1. Review existing documentation

a. Reviewing existing material helps the analyst by introducing the
terminology used by the business
b. Look at forms, screen layouts, and reports of clients existing Application.

2. Observation
a. Work in or observe the work as it is being performed.

3. Interviews
a. most appropriate for eliciting requirements with one or two individuals at
a time

4. Surveys and questionnaires

a. Can be useful when the sources of information are in different locations or
the number of participants answering a given question is large.

5. Facilitated sessions:{Requirements workshop}

a. Facilitated information gathering sessions are led by a facilitator who is
usually supported by a recorder and a timekeeper.
b. Topics on the agenda, participants, meeting location, and length of
sessions are all carefully considered and documented.
c. Multiple vs. individual input: As stakeholders listen to other
stakeholders describe their requirements, they all may be reminded of
 additional requirements that might have been missed with one-on-one
interviews.
d. Resolution of differences: Individual interviews with stakeholders often
result in different answers to the same question. This causes the BA to
reinterview people to try to resolve the discrepancy.
e. Balancing priorities: Different stakeholders often have different
priorities with respect to requirements. Leading the group through a
discussion of priorities will result in everyone understanding other
stakeholder needs.
f. Scope of the project discussion at the beginning of the project by
having all stakeholders understanding and agree to common boundaries.
g. Team Building
h. Process Improvement identification: People from different
departments how they do their work and exchange their experiences.

6. Focus groups:
a. Focus groups are sessions with randomly selected individuals who
represent a particular demographic or viewpoint.
b. A few customers are selected to discuss current products or discuss new
product prototypes and ideas.

7. Competitive analysis
8. Interface analysis