****CODE B Answers****

**1**
DO’S AND DON’TS FOR BA
1.Never say NO to client.
2.There is NO word called as “BY DEFAULT”
3.Never imagine anything in terms of GUI.
4.Question the existence of existence/question everything in the world.
Ex: what the client gives is not always correct
Consult an SME for clarification in Requirements
Every problem of Client is unique. No two problems of different Client are same.
May be the approach, technology, place of use, local laws may be varied to make
them(Problems) to be different.
Go to Client with a plain mind with no assumptions. Listen carefully and
completely until Client is done and then you can ask your Queries. Please do not
interrupt the Client, when he/she is giving you the problem. Maximum Try to
extract the leads to Solution from the Client itself. Never try to give Solutions to
Client straight away with your previous experiences and assumptions. Try to
concentrate on the important and truly required Requirements. Don’t be washed
away by add on Functionalities or don’t imagine solutions on Screen basis.

**2**
Business Process Modelling
A business process:
1.Has a Goal
2.Has specific inputs
3.Has specific outputs
4.Uses resources
5.Has a number of activities that are performed in some order.
6. Creates value of some kind for the customer. The customer may be internal or
external.
A business process is a collection of activities designed to produce a specific
output for a particular customer or market. It implies a strong emphasis on how
the work is done with in a organization, in contrast to a product’s focus on what.
A process is thus a specific ordering of work activities across time and place, with
beginning, an end, and clearly defined inputs and outputs: a structure for action.
**3**
Challenging areas of BA
1.Lack of training
2.Obtaining sign-off on requirements
3.Change management- with respect to cost and timelines
4.Coordination between developers and testers
5.Conducting meeting
6.Making sure status reporting is effective.
7.Driving clients for UAT completion
8.People Management(coordinating with different people and different teams)
9.Overall making sure project health is in good shape and delivered as per the
timelines without any issues.
**4**
Different categories of tools used in projects
**Documentation tools**
 MS Office
 Thinkfree
 Adobe Buzzword
 Zoho writer

**UML drawing tools**

 MS Visio
 Rational Rose
 Smart Draw
 Visual- Paradigm
 Magic Draw
 Concept Draw
 Enterprise Architect
 ArgoUML
 StarUML
 Case Complete
**Protyping Tools- Wireframe tools**
 JustinmindPrototyper
 WireframeSketcher
 Axure
 iPlotz
 Pidoco
 Pencil
**Screen capturing tools**
 Snagit
**Business Modelling Tools**
 ActiveModeler
 Agilpro
 Iserver
 Oracle Business Process Analysis(BPA)Suite
**Software Development Process Model**
 RUP

**Change Management Tools**

 Rational Clear Quest
 Perforce
 Affiniti
** Brainstorming Tools**
 Evernote – A note taking, brainstorming and web clipping tool
**Meeting minutes**
Meeting sense
**SDLC TOOLS**
 Microsoft project plan(MPP)
 Pivotal Tracker- Agile
 Rational Focal Point
 ALM Complete
**Database Tools**
 Microsoft Access
 My SQL Workbench
 SQLyog
 Navicat
 Reporting tools
 Rational SoDA
 Telerik
  Requirements Management Tool
 Rational Requisite Pro
 Serena Requirements manager
 Reconcile
 Analyst Pro
 IBM DOORS(Dynamic Object Oriented System)
 Contour
 Blueprint
**Configuration(VersionControl) Tools**
 VSS(Visual Source Safe)
 Win CVS(concurrent Versions System)
o Rational Clear case
**Testing tools**
 Win Runner
 Load Runner
 Test manager
 Silk Test
**Analysis Tools**
 Google Analytics- Web Analytics tool
 WebFOCUS
 SQL server profiler
**Enterprise Architecture**
 TOGAF(The Open Group Architecture Frameworks)
 ProVision
**5**
Generalization:
 It is a kind of relationship.

 Parent class doesn’t exist without none of its child class.

 Direction of arrow is based on dependency.

Generalization is of two types:

 1.Actor Generalization: It is a kind of relationship between the actor.
Example: If we generalized Customer into Customer and VIP Customer then it is
the example of Actor Generalization.

Example: When it comes to air travel, both a "Business Traveler" and a "Tourist"
are "Passengers". The fact that they are passengers allow them to have common
behavior such as "Buy Ticket" but the fact that they are separate actors implies
they can also have differences. The "Business Traveler" might be able to
"Redeem Business Miles" while the "Tourist" cannot.

2.Use Case Generalization: It is a kind of relationship between the usecase.

Example: We can do the Payment either by Cash or by Card or by Coupons . Here
Parent class doesn’t exist without its Child class means we have to opt one mode
to do the payment .

Example: If you are creating a payment system which allows students of a training
provider to pay for courses both on-line and by phone, there will many things in
common between the two scenarios: specifying personal info, specifying payment
info, etc. However, there would also be differences between the two. So, the
best way to accomplish this is to create one use case (the parent) which contains
the common behavior and then create two specialized child use cases which
inherit from the parent and which contain the differences specific to registering
on-line vs. by phone.
 **6**

Include:
 It is a compulsory relationship between the elements.

 Parent class is not complete without its child class.

Example: To transfer Cash it is mandatory to check the availabity of balance in

account. It is the mandatory relationship between Transfer Cash and Check
balance in Account.

Extend:
 It is an optional relationship between the elements.

 Parent class exist without child class.

Example: To Withdraw cash from ATM it depends upon the customer to take print
out of receipt or not. So we can say that it is optional relationship between
Withdraw Cash from ATM and Print Receipt.

For Example:

<<include>> relationship can be used to simplify large use cases by splitting it into
several use cases. It can also be used to extract common parts of the behavior of
two or more use cases.
When the checkout option is used, the other sub options can be scanning of item and
calculating total and tax and making a payment. These options are a part of checkout
feature. Hence <<include>> is used.

<<extend>> is a directed relationship that specifies how and when the behavior
defined is usually supplementary (optional)
**7**
SRS Document
Software Requirement Specification (SRS) document usually contains a software
vendor’s understanding of a customer’s software requirements. This document
ensures that the software vendor and the customer are in agreement as to the
features required in the software system being built. SRS is created after the
initial requirement elicitation phase in which Software vendor interacts with the
customer to understand the software needs. Usually SRS documentation is
prepared by a business analyst who has some technical background.
An SRS is written in precise, clear and plain language so that it can be reviewed by
a business analyst or customer representative with minimal technical expertise.
However it also contains analytical models (use case diagrams, entity relationship
diagrams, data dictionary etc.) which can be used for the detailed design and the
development of the software system. SRS is one of the most critical pieces of
software development since it acts as the bridge betweens the software
developers and business analysts. An incomplete or incorrect SRS can have
disastrous effects on a software project.
In this article I explain the major sections of a typical Software Requirement
Specification document. I also provide a generic SRS template which can be
customized for your project needs.
What is the need for an SRS document?
Software Requirements Specification is usually the first deliverable for any
software project. As they say, first impression is the best impression!, and you
should ensure that even the first draft of an SRS is of high quality.
The benefits of a good SRS are,
 A contract between the customer and the software vendor – A good SRS
document specifies all the features required in the final system including
technical requirements and interface requirements. SRS document is used by
the customer to determine whether the software vendor has provided all the
features in the delivered software system. To the Software vendor it provides a
solid foundation to fix the scope of the software system.
 Enables costing and pricing of the project – A well defined SRS enables software
developers to accurately estimate the amount of effort required to build the
software product. Function point analysis and SMC are some the techniques
adopted for estimating effort.
 Input for detailed design – A good SRS enables experienced developers to
convert the requirements directly to a technical design. For example, a well
defined data dictionary can be easily converted to a database specification.
 Management of customer expectations – Since SRS precisely defines project
scope, it ensures that customer expectations don’t change during software
development. If they do, SRS can be modified and costing/pricing can be done
again on the changes required.
What are the contents of an effective SRS document?
There is no single precise template for writing good Software Requirement
Specifications. The contents of an SRS document depends on the software
product being developed and also on the expertise of the people doing the
requirement elicitation. Different business/technology domains in a company
usually have their own customized version of SRS template. Still a good Software
Requirement Specification (SRS) usually contains project scope section, functional
requirements, requirement analysis models, external interface requirements and
non functional requirements. Each of these are explained below.
Scope of the project/ Product vision
One of the most important items in the requirements specification is the precise
scope definition of the project. Accuracy of this is important since SRS is also used
for estimation and costing. This section should include a brief overview of the
project and should also indicate the goals of the project including its benefits.
Sometimes it is better to separate the project scope into a separate document.
If the project is for the development of a product, product vision defines the
scope and the target user base of the product.
Functional Requirements
Functional requirements specify the business requirements of the project in
detail. Usually business requirements are specified in terms of the actions that
 user performs on the software system. This is known as the use case model. But
not all requirements need to be specified as use cases. Functional requirements
should contain a combination of use cases and plain textual description of system
features. System features are specified at a higher level and use cases attempt to
translate into user actions.
Again there is no fixed format for use case description, but it usually contains the
following information,
 Use case diagram – For a small systems, a single diagram can be used to depict
all the use cases in the system.
 List of actors and their details – This identifies the various types of users
interacting with the software system.
 Use case description – Purpose of the use case and how and when it is invoked
by the user. This should also include an identifier for easy reference.
 Preconditions – List of system states/conditions that must be true for the
successful execution of the use case. This section is optional and could be easily
incorporated into the basic steps section.
 Basic steps – These indicates the various fine grained steps required for the
execution of the use case.
 Alternate steps – These indicate alternate events of the use case being
described.
 Business validations/rules – These indicates various types of input validations or
business rules required in the use case being described.
 Post conditions – Indicates the results of the use case. Please note that this
section is optional and could be incorporated into the basic steps section.
To ensure that all the business requirements are addressed in the final software
product, a traceability matrix document is used. Traceability matrix tracks each
requirement through various phases of software development (detailed design,
unit test plans, system testing plans, user acceptance test plans and code
components). This requires that every requirement in the SRS should be
identifiable by a unique number or tag.
For software projects where majority of features are available as user interfaces,
it is better to complement this section with screen prototypes. These user
interfaces can change during detailed design, but having a draft version of user
interface in the requirements document helps a lot in communicating business
requirements. However some customers insist on having finalized user interfaces
in the requirements specification document.
Requirement Analysis Models
Once the overall use cases in the system are identified in requirements elicitation,
requirement analysis models can be developed to drill down to specifics of each
requirement. For example, a use case such as “Add customer” may not specify all
the customer details that needs to be captured by the system. This is usually
specified in the data dictionary model and also in the screen prototype.
Requirement Analysis models act as the bridge between functional requirements
and the detailed design of the software system. For example, Use cases lead to
user interface design, data dictionary and entity relationship diagrams are used
for designing database schema and class diagrams.
Following are some of the widely used requirement analysis models,
Entity Relationship Diagrams
Entity relationship model diagram (ERD) is a conceptual representation of the
data in a software system. During detail design this model is mapped in to the
physical database model. There are different diagramming conventions available
for creating ER diagrams. Following is a sample ERD in Crow’s foot notation (this is
taken from the ERD of a course registration Web application requirements),

This diagram indicates that there is one and only one instructor for a course and
an instructor can have one or more courses. The relationship is captured as
instructor “teaches” course.
Data Dictionary
Data dictionary in a requirements document is an extension of the entity
relationship diagrams. Which ER diagrams specify system entities and their
relationships, a data dictionary lists all the attributes pertaining to each of those
entities.
In a data dictionary, each attribute of the entity data in system is analyzed in
detail including type of attribute, whether it is optional and a brief description of
the attribute. Please see the sample SRS template section for more details.
In addition to the above models, sometimes it is useful to develop state transition
diagrams and data flow diagrams. To describe a complex process flow or a
workflow in the application, process flow diagrams or flowcharts can be used.
External Interface Requirements
It is very rare that we have a standalone software system. Usually a software
system interacts with a number of external applications for data input and output.
For example, an e-business application usually needs to be integrated to an
external payment gateway. All the external interface requirements are detailed in
this section. The important thing to document here are the entities that are
passed across the external interfaces.
Non Functional Requirements
Non functional or technical requirements specify how the software system should
operate. In contrast functional requirements specify what a software system
should do. Some of the non functional requirements are derived from the
functional requirements. Non functional requirements captured include
performance requirements, application scalability, application security,
maintainability, usability, availability, logging and auditing, data migration
requirements, multi lingual support etc. Please note that only a subset of the list
are applicable for a specific project.
Importance of a good SRS template
A good SRS template ensures that all important information required in a
Software Requirement Specification is captured during requirement elicitation.

Contents of Software Requirements Specification (SRS) Template

**8**
Sequence Diagram

**9**
20Questions to client (on first meeting)on Online cab booking system
1. What Features you need in the APP?
2. What problems are you facing in the previous version of APP?
3. What are your expectations?
4. What is your budget and when do you want to start?
5. Who can access the APP?
6. What’s the TAT for booking a cab?
7. Which areas are serviceable?
8. What are the charges per km?
9. What are the modes of payment of customer?
10.Is there any restrictions for the users?
11.What differences should be maintained for driver’s APP and Customer’s
APP?
12.What design considerations/constraints does the mobile APP have to
work with in?
13.Is there scope to use APP with same login credentials in different
mobiles?
14.Is Verification required for drivers and customers through APP?
15.What dependencies are there, that we need to consider before we can
get started with APP?
16.What kind of car information should be provided in the APP?
17.What kind of options to be given for the customer for ex: sharing, private
car etc?
18.What’s the TAT to finish one ride?
19. What is the timing for serviceability , is there any extra charges if we
service in peak hours?
20.Any compensation if we fail to service?
**10**
Role of BA in change request
As BA will study and understand the characteristics feature of Requirement
is change over a period of time. As Requirements are inherent to Change,
Requirements need to be managed throughout their life. People change
their minds, preferences, trends, etc. over time. So as the Businesses
change and Markets also change accordingly.

As the project progresses through time(like a month or a year or long), it’s

inevitable that some things will change that affect the project and so your
requirements may also change.

Ba’s always will be prepared for Change Requests and their management.
Whenever a Change Request comes from the Client, The BA will analyse
this Change Request. Initially he performs Feasibility Study to accept the
Change and then the Impact Analysis to measure change to project and
finally Effort Estimation to implement the change in the project.
Change Management will impact the project scope. That means that any
requirement which was not scoped as a part of the initial Business
Requirements document, must be managed under a proper change
management/control technique and the Business Analyst along with the
Project Manager has to carefully review and follow a rigorous change
control process. This means, when a change is requested, a Business
Analyst should

 Initially the BA Documents the Change Request

 The BA will Analyse the Change Request is really a change or a defect
discovered from previous need communications.
 The change manager or the project manager must provide an initial
approval if the business analyst needs to move further in analyzing
the change request
 When it comes to change management whether or not to
incorporate the changes, depends on yet to another important factor
which is for the Business Analyst as well as the Project Manager to
ensure whether the requested change is a complex one or just a
minor change
 Incase the change is complex, it will not only expand the scope of the
project drastically which in turn leads to increase the delivery time
 Business Analysts will help the Stakeholders to understand the
impact, the change request will have on the organization and to help
minimize negative impact that results from that particular change.
 Successful change efforts necessitate the Business Analyst to
articulate a realistic or convincing vision that appeals to both internal
and external stakeholders.

As BA must be able to communicate a sense of urgency among the

stakeholders, lead by example, show strong personal commitment and
enable stakeholders to contribute to their full potential.
Successful change management therefore, requires organization to
overcome the challenge of bringing all stakeholders to an
agreement/consensus about the changes to be incorporated and to avoid
conflicts which generally causes delay in the project completion.
**11**

Use case diagram for Library Management System

Activity diagram for Library Management system

 **12**
Role of BA in Projects

Stages Activities Aritifacts &Resources

Preproject Enterprise analysis-Swot Business case
Analysis, GAP analysis, SOW(statement of work)
Market research, Feasibility Study, Root PO(Purchase order)
cause Analysis, Decision Analysis,
 Strategy Analysis, Enterprise
Architectural Frameworks, Project
Scope and Business case writing, Risk Sr.BA, Business Architects
analysis. Presales Consultants

Planning 1.Understand Assumptions and

&Estimations&Assess Constraints along with the Business
ment rules and Business goals.
2.Plan Packages for Big projects.
Project Kick off 3. Understands the project plan from
(Big picture plan) PM.
4.BA conducts stakeholder Analysis.
5.Plan BA approach Strategy(Req .
gathering techniques, communication, PM
Req. mgmt, documents to follow, Tools Sr.BA
to use, change request Handling
methodology) for this
project

Requirements 1.Stakeholders identify and document BRD(Business Requirements

Gathering 2.Client gives BRD or BA prepares BRD Document)
by interacting with client-Brainstorming,
Document Analysis, Reverse
Engineering, Interviews, workshops,
Focus Groups, Observation,
Questionnaires.
3.Protyping can be used by BA to make
the client to give more specific
requirements
4.Sort the gathered
Requirements(avoiding duplicate Reqs, BA
grouping into similar functionality or
into modules) PM
5.Priortize requirements-MOSCOW
6.Validate Requirements-FURPS
Requirement Analysis 1.Draws UML Diagrams Functional Requirements
(Use case and Activity Diagrams) Specification
2.Prepares Functional Requirements SSD(Supplementary Support
from business requirements Document)
3. All architects comes up with Technical SRS(Software Requirements
Requirements(SSD) Specification)
4.SRS will have Functional Requirements RTM(Requirements Traceability
and Technical Requirements Matrix)
5.Takes Sign off on SRS from Client. SRS
is the first legal binding doc between
the business and the technical team.
BA
 6.BA prepared RTM from SRS before PM
design phase starts.(BA is the owner of Solution Architect
RTM). DB-Architect
7.BA traces hoiw requirements are dealt NW-Architect
in each phase of development life cycle
from Design till UAT
Design 1.From Use case Diagram, Test manager
or BA will prepare test cases BA
2.Communicates with client on the PM
design and Solution documents(updates Solution-Architect
Status to client and make them DB-Architect
understand how the solution would NW-Architect
look like to prepare them to drive UAT) GUI-designer
3.BA will initiate the preparation of End Test Manager
user manuals
4.Updates RTM
5.From Use case Diagram Solution-
Architect recommends Architecture of
the IT solution
6.DB Architect uses Persistence
classes(Entity Classes) come up with ER
diagrams or DB schema
7.GUI Designer will look into Transient
Classes(Boundary Classes) and designs
all possible Screens for the IT Solution
Coding/development 1.BA organizes JAD sessions LDD-CDD
2. BA clarifies queries of Technical Team Application
during Coding
3.Developers refer Diagrams and
Transient(controller classes) of BA and
code their unit.
4.Update End User manuals

5.Update RTM Development Team

6.Conducts regular status meetings with BA
technical team and the client and tuning PM
client for participation in UAT
Testing 1.BA-Prepares Test Cases from Use Test Concerning Documents
cases or assists Test manager to do so Application with less errors
2.BA performs high level testing

3.BA prepares Client for UAT

4.Test data is requested by BA from
Client.
5.Updates End User Manuals Testing team
6 Updates RTM BA
7 Take sign off from client on client PM
project acceptance form Client
Deployment and 1.Forwards RTM to client or the PM
implementation which should be attached to the project
Closure document
2 Coordinates to complete and share
end user Manuals
3.Plans and Organizes Training Sessions
for end users
4.Prepares Lessons learned from this
project(to take precautions for coming
projects)