Table of Contents

BA with UML
Domain Focus: Session 0 8/10/2011 9.00PM EST 6.00 PM PST

BA roles s and responsibilities Goal of the training program: Goal of the training program is to get a job as a BA Other Names for BA : SME Domain Expert Functional Consultant / Presale Consultant Data Analyst, Process Consultant Where To Apply : IT Product Company - IBM , HP , Honeywell , Oracle IT Application Company - Customization of products is done to specific business process IT User Company - Banking, Insurance, JP Morgan.. IT product companies(IBM, Oracle etc), IT application and IT user companies Why should they hire u? They will be looking for certain skill sets in a candidate who can become their employee

Skills Required for a BA: 1.Domain Knowledge A quick way of gaining domain knowledge can be done by Reading the literature related to domain Case studies

 Downloading the software products related to specific domain and work on that product by referring the end user manual. Tips to gain the domain knowledge: Like Flexcube banking product from oracle crop. And competitor is Finnacle by Infosys. This will be used by the stake holders (Cashiers, managers, cust. , end users. etc) Ex: Try to locate some soft products related to Insurance claim management, health care domain (clinical trails) , download it and start working on it with an end user manual. Download EZ claim product and find out similar products like EZ Claim and preferably search in open source category. Ram will help u in giving list of more products. Pick your domain: Try to find out software products related to that domain and download the same, work on the end user manual, do a reverse engineering (create documentation like BRD,SRS looking at the product ) 2.Methodology Understanding Methodology is the processes involved in developing a software product or application. Other terms for methodology SDLC (Software Development Life Cycle) PDLC (Product Development Life Cycle) ADLC (Application Development Life Cycle) This methodology can be broadly classified into two categories: a. Traditional Methodology: By traditional methodologies we mean earlier methodologies. Ex: (Waterfall Model, spiral model, Prototype model etc.) b. Modern Methodology/ Agile Methodology: Modern methodologies are the most recently used methodologies. The examples of them being: - RUP (Rational Unified Process) - SCRUM - XP(Extreme Programming) - Lean Software Development

- TDD(Test Driven Development) - Crystal Clear 3. Entire understanding of SDLC SDLC comprises of the following steps: Business modeling Requirements Analysis Design Development Testing Change Management Project Management Delivery/ Deployment/ Maintenance Post Maintenance Each of the above is the process by itself. Now, you need to have a overall understanding of all the steps involved in SDLC/PDLC etc 4. Modeling techniques used in SDLC In all the steps mentioned above, for as is and to be modeling we use various modeling techniques and these techniques are: - UML(Unified Modeling Language) For a BA there will be three diagrams which are important and one of the diagram is use case diagram and the other ones are activity diagram, object state diagram and if you have idea of two more diagram thats also helpful and thats class and sequence diagram - Data Modeling (Domain Modeling or Conceptual Modeling) Data modeling is further segregated into logical modeling (Entity Relationships diagrams) and physical modeling (Converting ER diagrams into tables/physical diagrams). - Process Modeling (Data Flow Diagrams ) - Organizational Modeling Organizational Charts (Identifying key stake holders positively or negatively impacted by the outcome of the project).

- Workflow Diagrams - Process Flow Diagrams - Flow charts - Business Rule Catalog - Decision Tree 5. Requirement Process in-depth understanding We should know who (BA) should do what, when, how, why and what should be the deliverables. Deliverables can be also be called as artifact, work product, output (The guiding methodology will be RUP). 6. Requirement Process Elicitation Techniques Understandings Benchmarking Joint Application Development Interviews Questionnaires Requirement Workshops

7. Business Problem Analysis Techniques GAAP analysis SWOT (Strength, Weakness. Opportunity, Threat) analysis PERETO (80-20 rule) Fishbone (Root cause Analysis)

8. Requirement Process Deliverables Understanding Vision Documents Requirement Management/ Work plans BRD (Business Requirement Document) SRS ( Software Requirement Specification) FRS ( Functional Requirement Specification) DRS ( Detail Requirement Specification) PRD ( Product Requirement Document)

RFI ( Request For Information) RFP ( Request For Proposal) RFQ (Request For Quotation) SOW (Statement Of Work) Job Order SLA ( Service Level Agreement) Release Notes Business Use case models System Use case models

9. Testing (Black box or functionality) Processes Who should do what, when to do, why to do, how to do and what should be the deliverables 10. Testing Deliverables Test Plan Test Case Test Script Test Data Test Reports

11. Change Management Process Understanding in- depth Who should do what, when to do, why to do and what should be the deliverable 12. Change Management Deliverables Change plan Change Request Requirement traceability matrix Impact analysis report

To do all this the software use is RUP Microsoft Visio Enterprise Arch. Rational Requisite Pro

13. Project Management overall macro understanding and project deliverables Project Data 14. Software Understanding MS Office, MS Visio, Enterprise Architect
Learning Take Away: To have an understanding of all the skill sets required for a Business Analyst Reading Material : Course PPT ( BA Session 0 ) Assignments : Locate the domain products ( refer to recap Document of Session 1 and 2 ) Prepare PPT on Waterfall, Spiral, Prototype, Iterative, Incremental Models Add Ons

Session 1 8/11/2011 9.00PM EST 6.00PM PST

Software Engineering Process Models Methodology Definition Framework of steps (Requirement analysis, design, etc) when applied should result in development of a quality product or application within right time, right budget and meet the expectations of all the stake holders( is anyone who is positively or negatively impacted by the outcome of the project) If you r able to achieve the above then which ever methodology u r following is a good methodology There r many methodologies and have a common goal develop a quality product in right time, right budget and meet the expectations of all the stake holders Depending on the need of the project we should know, which methodology or a combination of methodology that can be applied. Methodology proven best practices which have yielded good results Framework collection of best practices which are repeatable

Learning Take Away : there r 3 scenarios how a methodology is applied 1) Client tells u what methodology u have to follow to develop their software product or application 2) Software development company will have internal processes defined (Quality assurance team will design) to develop a product for an application 3) Every project is unique itself. A methodology can be defined for that unique project

Reading Material : Roger Preesmen Software Engineering Assignments Assignment 1: Costs of Product and market share of all? How many core modules will be there? Everything in Excel and find out end user manuals. 1) Temenos 1000 institutions in 125 countries 2) Microbanker and Finware - Flexcube 395 instalations , 125 countries. Windows, unix platform. Head quarter in india. HDFC, HSBC, Kotak Mahindra,etc 3) Finnacle by Infosys 4) Fedility 14000 institutions in 100 countries. Head quarters in Jacksonville, FL. Cust are MAC, Assignment 2: Find out products realted to healthcare domain. Narrowing it down to Clinical trails. Open Clinica Find out competetors to open clinica, their market share, clients, costing and need in the market Assignment 3: Create a data base of all the brouchers for tomorrows sessions Assignment 4: Refer White Paper, Blogs on sdlc and prepare a PPT similar to white papers, and even add RAD and Concurrent Developement

Find Process Model details as much as possible

Add Ons

Session 2 8/14/2011 7PM IST 9.30AM EST 6.30 AM PST

AGILE Methodologies Many agile methodologies that follow a Common manifesto giving more imp to communication rather than process (taking decisions fastly and based on communications) - Compliance process (following a set of rules) is kept at bare min. - Less imp to documentation - Working deliverables in an incremental way - Involving the customer in every phase

1. 2. 3. 4. 5. 6. 7. 8.

RUP* Scrum* Xp* Test driven development Crystal clear Lean software development Open unified process Essential unified process

RUP: Rational Unified process by IBM - Use case driven, architecture centric*, iterative and incremental Every project will have triple constraints -time , cost and scope (inter-related)- a change in 1 puts pressure on the other 2 constraints - Extremely documentation centric *Used on product oriented projects Phases in RUP : inception, elaboration, construction and transition Inception : scope is determined here , deliverables called many deliverables (BA , customers ) -involved Elaboration : architecture of the product (designer and architect )involved Construction : Code (product id developed)

Transition : transferring the product to the customer (BRD* other names- opportunity definition doc, business process assessment reports) Disciplines: -business modeling , req Analysis and design , development, testing, change mangt , project magt , environmental The process models are granular who, what, when, how to do the deliverables RUP follows the concept of iterative approach (one complete discipline iteration) 1 iteration= 1 complete sdlc Small projects- do 3 iterations 6 for medium projects 9 for large projects
Milestone : progress of the project Deliverable: Build : something that is not handed over to the customer(internal) Release :something that is been tested (given to external stakeholder)

SCRUM : The entire concept of scrum is based on time boxing (start and end point) Deliverables : there are 4 - Product backlog - Sprint backlog - Impedepement list - Burned down chart
People involved in scrum are 1. Scrum master 2. Scrum team 3. Product owner

Meetings (cermonies) : sprint backlog meeting daily scrum meetings sprint backlog review assesment meeting Everything in scrum starts with product backlog(template) (which contains the reqs documented as user stories) User stories will be prioritized , how to give a demo to the customer for the req completion Attributes of the user story - Priority - Effort Assume product backlog has 500 reqs In scrum a delivery has to be made in either 2 weeks or 30 days. 1 sprint = 2 weeks or 30 days =1 sdlc A meeting will be called which is sprint backlog meeting (suggested guideline 4 hrs meeting) Product owner sponsor Scrum master PM level Scrum team- not to exceed more than 9 ppl (no hard rule) (BA. Architect, developer, QA, stake holders etc., ) Output of the meeting :sprint backlog (contains the shortlisted reqs from product backlog to be finished in 30 days) Assuming to do 200 reqs in sprint backlog in 30 days 7 reqs a day Every day: scrum meeting 15 mins What did you do today , yesterday and any problems ? All problems will be documented in impediment list .

Responsibility of scrum master to manage the impediment list Burned down chart monitors the progress contains accomplished tasks 180 only could have been developed and demo has to be presented to the customer Conduct a review assessment meeting why only 180 instead of 200 as planned ?

Remain 20 +300 for next sprint Cycle repeats and sprints are repeated to conclusion. Extreme programming- XP Developer is the boss and talks to the customer , Customer gives reqs to developer Good for small projects
Learning Take Away To have an understanding of agle methods and manifesto , RUP, XP & SCRUM Their APPLICABILITY IN SOFTWARE DEVELOPMENT OR PRODUCT DEVELOPMENT , Reading Material Assignments Do the comparative analysis of RUP , XP and Scrum (check in white papers/articles/blogs )

Add Ons Session 3 Small ppt on Lean software development

Analysis & Enterprise

Analyzing a business process 1. Study the business process 2. To identify the business problem of the business users and stakeholders(diagnostic approach to be followed) 3. Gain Stake holder agreement on the problem* 4. Propose solutions 5. Gain agreement of the solution from the stake holders 6. Document the business process problem(documentation, plain text or as is modeling) solution (text, to be modeling) and take a sign off BRD (main focus of BRD business process and business solution only*) O/P of analyzing business : Business case , BRD
Learning Take Away To analyse a business process and to deliver a business process and solution in documented manner

Reading Material Assignments

Add Ons

Session 4

UML & Basic OOPS Concepts Unified modeling language (UML) in 1997 : Anything can be called a language if it has a syntax n semantics Syntax: notations/symbols/ elements(same things) that we use
Sementics of UML: are basically the rules that we follow to combine all these elements and make a particular diagram . OMG- Object mangt group- diff it companies put together

UML2.1 VERSION CURRENT Uml2.0 is being used. Applying UML results in prominetly 9 diagrams(5 static and 4 dynamic diagrams) 5 static diagrams : 1. 2. 3. 4. 5. Important diagram : -Use case diagram* (BA Resp) Object diagram Class diagram Component diagram Deployment diagram

4 dynamic diagrams 1. 2. 3. 4. Sequence diagram Collaboration diagram Object state machine or transition diagram Activity diagram

4 new diagrams added to UML adding upto 13 diagrams 1. Timing diagram 2. Package dependency diagram 3. ? Communication diagram 4. - ? Composite structure diagram BA perspective diagrams : Use case diagrams Activity diagram Object state event diagram Other technical diagrams : class and sequence diagrams

UML constitutes 4 things Structural things (symbols that are used in the static diagrams are structural ) Behavioral things ( symbols used in behavioral diagrams) Grouping things (packages and subsystems) Annotations (notes attached to the diagrams)

UML syntax and semantics can be extended by using stereo types & constraints resp. Learning Take Away To have an understanding of UML and applications

Reading Material Read UML ppt sent by ram Assignments Small ppt on UML Add Ons EA ENTERPRISE ARCHITECTURE

Session 5

Managing Requirements- rup Req Definition : Need of the stakeholder. Formal def: condition or capability to which a system must conform to. IIBA : Condition or a capability to solve a problem or reach an objective. Managing rqs is about - Eliciting reqs , ( Discovering reqs (existing reqs); Ex: elicitation techniques like JAD sessions, interview etc., ) - Document reqs ( Pictorial/documented, Ex: Business case, VD, RWP, RMP, BRD, SRS, RFI, RFP, RFQ, SOW, SLA etc., ) - Organize reqs ( catogerize based on their attributes like highmediu-low priority reqs ; assigned to who ; critical/noncritical , must have, good tohave, ) - Managing the changing reqs . ( change management procedures , RTM - req tracebility mx***(reqs related in all ways, top down/bottom up)) Base lining**: mutually agreed reference point. (Can be applied to every project deliverable) Business rules (independent of technology) documented using decision tables or business rule catalogs. Ex: emp cant work more than 8 hrs a day etc.,

Reqs need to be managed to eliminate confusions. All the deliverables mentioned in 5.3 depicts reqs in a documented way

which can be textual or diagrammatical. These deliverables mentioned in 5.3 are interrelated. The inter relationship is called tracebility . It is done by requirement tracebility matrix. Changes in 1 doc reflects changes in all docs.

Need to install : enterprise architect, Ms Visio, rational rose (optional)

Learning Take Away : Is to have an understanding of all req mngt deliverables. And how to manage using tracebility matrix. Reading Material : Read RUP**- Introduction & concepts Assignments : Make a ppt of the reading material. Add Ons :

Session 5.1

Types & Levels of Requirements

Business architecture (by business analyst): Identifying the business problem
and solution. Deliverables: BRD, business case etc.,

Technical architecture(by system analyst/architect)

Deliverables: SRS, Design document (high level, low level , technical specification document)

Database architect : responsibility of database design

Deliverables: Conceptual model, logical model(Entity relationship diagram) and physical model (tables)

Infrastructure architect : Is to work on network design, connectivity,

hardware and software related stuff Deliverables: n/w diagrams , deployment diagrams etc.,

Enterprise Architect** (keyword) :

Requirement definition: Need of the stake holder. Documented solution proposed to a stakeholder Formal DEF: A condition or a capability to which the system must conform to. (Defined by IBM RUP) IIBA(International institute of business analyst) Types of requirements : 1. Functional requirements (can be depicted as use case diagrams)These add business value(tangible reqs) 2. Non functional requirements Quality of service reqs (performance, Reliability , how many years data can be retained )
**Functional and non functional reqs are part of BRD(called business use case diagrams & SRS(called system/application use case diagrams)

3. Find out any additional requirement types?? Solution : Other types of requirements are a. Transition or Implementation Requirements: b. Customer/User/Stake Holder requirements: Expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability Other requirements include Domain Requirements : Architectural requirements: Architectural requirements explain what has to be done by identifying the necessary sys architecture of the system. Structural requirements: Structural requirements explain what has to be done by identifying the necessary structure of the system. Behavioral requirements: Behavioral requirements explain what has to be done by identifying the necessary behavior of the system. Derived requirements: Requirements that are transformed from higherlevel requirement. Allocated requirements: A requirement that is established by dividing or

otherwise allocating a high-level requirement into multiple lower-level requirements. Design requirements: The build to, code to, and buy to requirements for products and how to execute requirements for processes expressed in technical data packages and technical manuals.

Levels of requirements : Part of BRD 1. 2. 3. 4. 5. Regulatory reqs : enforced by govt , HIPPA rules Strategic level of reqs :CEO level Business reqs : sr.level managers Operation level reqs : Solution or user level reqs :

Risk : Unforeseen conditions which may impact the project in a positive or negative way. - Risk mitigation (reducing the severity) - Risk transfer (ex: insurance) - Risk acceptance - Exploit(if its a positive risk)

Learning Take Away: Reading Material : Zachman architecture , Togaf architecture, cloud computing , service oriented architecture Assignments Add Ons :

Session 5.2

Requirement Elicitation Techniques

Learning Take Away Reading Material

Assignments Add Ons

Session 5.3

Requirement Deliverables Purpose Comparison

Business modeling (in RUP) OR Requirement analysis step : Organizational goals: Every org will be keen to achieve their goals. The project starts with the following documents Everything starts with one particular document called

1. Vision document (Template- define/customize by QA team) : High level business problem and business solution are to be presented to key stake holders who are sponsors. 2. Requirement work plan: Budget and time will be sanctioned by the sponsors after assessing the vision doc. (ESI guide line, 10-15% of the time is allocated for reqs process ; 1525% costing) 3. Requirement management plan: Contains the whole plan , planning. 4. BRD : Business problem(as is modeling Business use case diagram, business use case spec) and solution(to be modeling business use case diagram, business use case spec) 5. SRS : Business solutions will be converted into detailed specifications. Those detailed specifications are documented in SRS(Software Requirement Specifications or Technical Design Document) From architect (sys analyst) or designer Note: Develop the project internally or company can outsource the project. 6. RFI(Request for Information) : Potential Vendor information is gathered.

RFI Template is designed by QA. 7. RFP(Req for Proposal) : Shortlisted vendors have to submit the proposal. Non disclosure agreements and confidentiality agreement would need to be signed by vendors. Presentations, discussions will follow. Base line RFP will be signed( mutual agreement) 8. RFQ( Req for Quotations) : submitted by the vendor. After deliberations, a single vendor is finalized. 9. SOW(Statement of work or job order) : 10.SLA(Service level agreement) :warranties etc., Develop the project internally case: Development plan Test plan Change mangt plan Project charter

Learning Take Away Reading Material Assignments : Download empty and filled templates and prepare a small ppt. Ram will provide ppts after assignments Add Ons

Session 5.4

Requirement Deliverables Of RUP 2 Areas : Business modeling & Requirements Business modeling: when we are conducting business modeling, main focus is on identifying business problem and proposing a business solution Deliverables/artifacts/output/workproducts of business modeling are 1. Business stake holder request 2. Business Vision 3. Business use case model 4. Business use case specification 5. Business glossary 6. Business rules All these become input to reqs. Requirement deliverables : 1. 2. 3. 4. 5. 6. Stake holder request Vision document Use case model Use case specification Glossary Rules

Use case model : Purpose of Use case* diagrams: To depict the behavior of the system as expected by users (stake holders) of the system. Use case digram talks about .What the system does ? only and not how. Use case diagram Ingredients : 1. Actor An external entity (human being/users , device/Automated /triggered by itself) , external system/ anything outside the scope or secondary actors ) who should invoke or receive an observable result ( positive or negative) of a value. Tips for finding actors: Nouns have a potential to become actors but not all nouns are not actors. 2. Use case - A distinct business functionality which invoked by an actor should produce an observable result. Ex: withdra/deposit cash, generate reports. 3. Relationships- Actor to usecase ->binary association , which is actor can talk to use case and vice versa . There can be relation to an - actor to actor. ( Is a kind) generalization and specialization - usecase and usecase. (Include and extend) - actor and a use case. (Binary association) 4. Boundary This determines the scope of the project and is represented by a rectangle 5. *Scenarios (or flow of events) No symbols, All scenarios are to be documented in use case specification document/ use case narrative document or use case destination. Normal flow : When use case is successful All permutations and combinations are to be captured in use case specification document. Ultimate business logic is in the use case

specification document. Use case Specification talks about the complete detailed functionality for a particular use case Many companies have different templates for Use case specification The most common thing in any of the templates r the following: 1. Use case name name of the use case Maintained TC 2. Use case brief description this use case allows all employee to maintain time card info 3. Flow of events: normal( successful) and alternate ( non successful) Techniques to keep in mind to identify the flow of events are: Keep CRUD( create, read, update, delete) in mind Always think from actors/user (Emp) perspective this use case starts when emp wishes to either create/update/read TC If emp wishes to create TC the following should be performed Emp clicks on the button Create TC System will display the following info fro emp confirmation ( ID(non editable autofetch field) Name (non editable) Type(non editable) Emp confirms the above and wishes to proceed Then system will present the following info for emp TC ID (auto generate integer) Emp Name,Emp ID ( Auto generate) Project ID and name ( Autofilled ) Start Time ( date and time format) End Time Over Time ( derived attribute) Error messages ( all messages are alternate flow of events) If the use cases are done well then itself can become an input for a test case. Then actor clicks OK, TC is saved. Use case ends. Use starts when emp clicks on update TC button

Write down the steps by tomorrow Maintain TC srujana Maintain PO Keerthi Select Payment method suneetha and hitesh Generate emp query reports deepa, murdula Maintain emp info prashamsa Generate Pay check all Run admin reports Raj Kiran
Req deliverables comparision PPT Pre condition Login Post condition Timecard saved Extension points none Special reqs statutory req

Learning Take Away Reading Material Assignments : 1. Asset mngt, payroll and course specification case studies ( On both Visio and enterprise architect)

Add Ons

Session 6.0

Analysis & Design

Learning Take Away

Reading Material Assignments Add Ons

Session 7.0

Testing Process
Learning Take Away Reading Material Assignments Add Ons

Session 8.0

Change Configuration Process

Learning Take Away Reading Material Assignments Add Ons

Session 9.0

BABOK (Orientation)
Business analyst body of knowledge(Version 2) Learning Take Away Reading Material Ram will send a ebook Assignments Add Ons

Session 10

Project Management (Orientation)

Case Studies

Payroll Case Study Course registration Insurance Claims Management System Personal loan Approval System

BPM Tools (Optional).

Discussion on Aug 15th : 1) Requirement management : (eliciting , managing, documenting and organizing etc., ) (session 5) 2) Requirement deliverables: (vision doc, req mangt plan, req work plan, brd, srs rfi, rfp, rfq, sow , NDA etc., for all methodologies except for RUP methodology)(session 5.3) Assignment: download empty and filled templates. 3) Requirement definition : Types of reqs and Levels of reqs Assignments: Refer RUP for session 5 Session 5.1: Small ppt on types and levels of reqs session 5.1 Session 5.2: Req elicitation techniques( discussed tomorrow) Session 5.3****: Requirement deliverables ppt (empty/filled templates) Read all case studies*** Agenda for tomorrow: USE CASE MODEL, Session 5.2 & 5.4 and Case studies August 16th Session : Session 3 : Ram to send ppt Session 4 : Ram to send ppt Session 5 : read RUP (Introduction and concepts) Keerthy to send PPT to everybody Session 5.2 : Req Elicition Tech Srujan ans ram Session 5.3 : Req deliverables comparision *** Whole class Ppt Session 5.4 : RUP Deliverables (Business modeling and requirements) Only practicals- No ppts (In class discussions of 3 case studies ) Session 6 : Analysis and design (In class) -- Ram to send ppt Session 7 : testing process - Ram to send ppt Session 8: change mangt Session9 :BABOK (In Parallel to session 5) Ram to send a book Session 10 : PM (Ram)

The tip for Comparing the deliverables of requirements is

For every doc download the table of contents and compare the table of contents Compare table of contents for different BRD and SRS, RPI,RFP,etc Suppose there is a BRD Inside the BRD there is a use case diagram, glossary, RUP Business use case diagram Business use case specification Business Glossary Business supplementary specification All the above can be clubed and become a single doc called BRD Suppose there is SRS.. Inside SRS they will be RUP System use case diagram System use case specification System Glossary System supplementary specification Suppose if it is not RUP and it is SCRUM, then what is BRD? It is product backlog - inside this the reqs are documented as user stories Suppose if it is not RUP, not SCRUM then we may have only BRD The Quality Assurance team will decide the template contents of the BRD For a project most of the BRDs will be filled templates. If you r a BA , then you should understand the contents of a BRD, then we will be in a position to modify the BRD.
Agenda for aug 19th 6 Analysis and design Testing process, change management process