ba material

7/28/2019 BA Material

1/40

Business Analysis

Tutorial


2/40

Business Analysis Tutorial

Table Of Contents

1. Introduction.............................................................................................................3

2. Pre Requisites:........................................................................................................4

3. Role & Responsibilities of a Business Analyst......................................................5

Functional Requirements:......................................................................................5

Non Functional Requirements (Supplementary requirements):.............................5

4. Requirement Analysis.............................................................................................9

5. Gathering Effective Requirements........................................................................10

6. Recommended Requirements Gathering Practices...............................................11

7. Preferred Requirements Gathering Techniques....................................................13

8. Requirement Gathering Methodologies................................................................15

Waterfall Model...................................................................................................15

Rational Unified Process......................................................................................15

Agile Methodology .............................................................................................16Extreme Programming ........................................................................................18

9. Requirement Gathering Tools...............................................................................19

10. Unified Modeling Language........................................... ........................... ........20

11. Business Requirements Document.....................................................................21

12. Use Case Document ..................................................... ................................ .....28

13. Test Case Document ..........................................................................................33

14. Frequently Asked Questions...............................................................................35

Page 2


3/40


1. Introduction

Business Analysis is a process of identifying, gathering, analyzing, documenting, and managing the requirements within in a business process.

Over the life of the project the Business Analyst will: Organize Meetings, Involve the concerned Stake Holders and gather various

types of requirements pertaining to the system. Perform a high-level analysis of the Requirements from a business value

perspective to determine the feasibility of constructing the application. Re-engineer businesses processes and assist the client with the development of

new process flows, documents, forms and administrative processes.

Produce initial project scope, schedule and budget. Act as arbiter (interface) between client and developer with respect to projectimplementation issues.

Conduct analysis at a sufficient level of detail to determine the essential functionalityof the application expressed as use cases or user stories (shall deal with these later)

Capture information flows and determine general data storage and retrievalrequirements.

Efficiently transfer the high-level analysis products, use cases and processdiagrams, to the development team.

Assist clients with transition planning, data migration, administrative processredesign and implementation support.

Conversely, the Business Analyst may also be requested to: Developing a comprehensive design document specifying detailed

requirements of the application like form layouts and navigation, data models,entity relationship diagrams and other design artifacts.

Managing the project schedule

Page 3


4/40


2. Pre Requisites:

Communication Skills: Business Analysis is all about communication, bothOral and written. Besides any thing a Business Analyst interacts with variousstakeholders and does documentation extensively. Therefore to excel as aBusiness Analyst, Written and Oral Communication Skills are very vital.

Software Industry: General Over view of Software Industry like:

o Client Server Applications: Examples: Visual Basic, PowerBuilder.o Web based Applications: Examples: Html, Xmlo Programming languages: Examples: Java, C++, ASP, .Net.o Databases: Examples: Oracle, Sal Server, Sybase, DB2, Sybase,

Access.o Technologies: IBM Websphere, BEA Weblogic, Microsoft .Net,

ATG Dynamo.

Other Stakeholders: within the project and their responsibilities namely:

o Project Manager o Technical Architecto Programmerso Database developerso Database Administratorso Quality Assurance Analysts

Page 4


5/40


3. Role & Responsibilities of a Business Analyst

A Business Analyst is the key behind the development of a system, where he is theinterface between the stakeholders from who he gets out what exactly they want andcommunicate to the Development team, so that they build the system accordingly.

In IT (software) Industry typically a Business Analyst would gather the requirementsfor a developing software system.Requirements could be classified into the following types.

Functional Requirements:

Functional requirements are associated with specific functions, tasks or behaviours thesystem must support. In terms of the ISO quality characteristics for evaluation, thefunctional requirements address the quality characteristic of functionality

Non Functional Requirements (Supplementary requirements): Non Functional Requirements are also called the 'ilities' because they are most simplyexpressed like this:

UsabilityReliabilityInteroperability

ScalabilitySecurity

Time to marketCostSpeedRAM

Secondary storage

Non-functional requirements are adverbially related to tasks or functionalrequirements: how fast, how efficiently, how safely, etc., is a particular task carriedout by a particular system.

Graphical User Interface (GUI) RequirementsGraphical User Interface Requirements involve developing prototypes; designingmock ups for a system. This also involves defining the various parameters, screen

Page 5


6/40


7/40


Example of the tasks performed by a Business AnalystLet us try to understand the role of a Business Analyst at a greater detail taking anexample.

Consider that yahoo email does not yet exist. The owners of Yahoo.com came upwith this idea of developing yahoo email system and approached your company to

build the site mail.yahoo.com. Now to build the system you are hired as a BusinessAnalyst apart from various other people in the responsibility of Project Manager,Technical Architect, Programmers, and Database developers/Administrators, QualityAnalysts etc.

Now, as a Business Analyst you are responsible do the following.

Gather all the requirements pertaining to what the client envisions mail.yahoo.com to be, document them and pass it on to the technical (development) team so that theycould develop (program) to build the system.

Identify the requirements at a high levelEvery user is required to register on to yahoo before being able to emailEvery user is required to sign on to their site before being able to emailYahoo email has search capabilityYahoo email has calendar features.

Now think of other features of yahoo, which could be categorized into High-levelrequirements.In the next phase - Elaborate the above high-level requirements into detailed ones

Example:Registration (Sign Up) Process should record the following user details

1. First Name2. Last Name3. Date of Birth.

The Login Process should involve the following

1. The User is required to fill in the UserId and Password and click the submit button

2. The system should check for the validity of the User entered details andIf the information correct then redirect the user to the Inbox pageElseRedirect the user back to the sign on page.

Page 7


8/40


9/40


4. Requirement Analysis

Requirements are prone to issues of ambiguity, incompleteness, and inconsistency.Techniques such as rigorous inspection have been shown to help deal with theseissues. Ambiguities, incompleteness, and inconsistencies that can be resolved in therequirements phase typically cost orders of magnitude less to correct than when thesesame issues are found in later stages of product development. Requirements analysisstrives to address these issues.There is an engineering trade off to consider between requirements which are toovague, and those which are so detailed that they

1. Take a long time to produce2. Begin to limit the implementation options available3. Are costly to produce

Writing Requirements

Requirements are written in such a way that they direct the creation/modification of asystem according to the business rules appropriate to the domain in which the systemwill be used. Systems should normally conform to the business domain of operation.The general form of a requirement looks like.. "who shall what". Example: "Thecontractor shall deliver the product no later than xyz date."

Changes in requirements

With time, requirements may change. In this case, once defined and approved,requirements should fall under change control. For many projects, some requirementsare altered before the system is complete. This characteristic of requirements has ledto requirements management studies and practices.

Disputes regarding the necessity of rigor in software requirements

Some modern software engineering methodologies like extreme programmingquestion the need for rigorously describing software requirements, which theyconsider a moving target. Instead, they describe requirements informally using user

stories (short summaries fitting on an index card explaining one aspect of what thesystem should do), and compose a series of acceptance test cases for this user story.

Page 9


10/40


5. Gathering Effective Requirements

To develop software projects on time and budget there is nothing more important thangathering and clearly defining the requirements. In defining requirements, you are notspecifying how the software will be built, but exactly what you need your software todo. According to Steve McConnell in Software Project Survival Guide, "The mostdifficult part of requirements gathering is not documenting what the users 'want'; it isthe effort of helping users figure out what they 'need' that can be successfully providedwithin the cost and schedule parameters available to the development team."

Begin by understanding the organization's "business requirements." This leads to a"vision and scope" document that describes the background leading to the decision todevelop a new or modified system or capability and describes the system to bedeveloped.

The next step is to gather the stated requirements of the customers and users of thenew capability. An effective requirements practice distinguishes stated requirementsfrom real requirements. Industry experience has shown that customers and systemdevelopers should jointly evaluate stated requirements to ensure that each is a verifiedneed.

Part of the requirements process is to prioritize requirements. This is important, because rarely is there enough time and money to provide everything that is wanted. Itis also beneficial to focus on product benefits, not features. Benefits refer to thenecessary requirements. Adding unnecessary features adds design constraints andincreases costs.

It is estimated that 85 percent of the defects in developed software originate in therequirements. Once defects are embedded in the requirements, they tend to resistremoval. They are especially difficult to find via testing. Therefore it is crucial thattraining be required for requirements analysts and engineers that explain how toreduce the common types of requirements errors.

Peer reviews and inspections are a best practice way of eliminating defects. Using peer reviews, scenarios, and walk-through to validate and verify requirements results in amore accurate requirements specification and higher customer satisfaction.

One of our most common problems is attempting to exceed requirements rather thanaddressing the minimum requirements to meet real needs. Thus, meeting minimumrequirements is in the customers best interests. It helps avoid the problems of latedeliveries, budget overrun, low moral, and poor quality.

Page 10


11/40


6. Recommended Requirements Gathering Practices

The following is a list of recommended requirements gathering practices.

Write and iterate a project vision and scope document.Initiate a project glossary that provides definitions of words that are acceptableto and used by customers/users and the developers, and a list of acronyms tofacilitate effective communication.Evolve the real requirements via a "joint" customer/user and developer effort.Focus on product benefits (necessary requirements), not features. Address theminimum and highest priority requirements needed to meet real customer anduser needs.Document the rationale for each requirement (why it is needed).

Provide training for requirements analysts and selected customer/user representatives that explains the following:

o The role of the requirements analyst, e.g., to evolve real requirementsworking with customers and users, not to invent requirementsindependently or to "gold plate."

o How to write good requirements?o The types of requirements errors and how these can be reducedo The value of investing more in the requirements processo The organization's requirements processo Overview of the methods and techniques that will be used.o How to use the project's automated requirements tool.o The role of validation and verification during requirements definition.

Establish a mechanism to control changes to requirements and newrequirements.Prioritize the real requirements to determine those that should be met in thefirst release or product and those that can be addressed subsequently.When the requirements are volatile (and perhaps even when they are not),consider an incremental development approach. This acknowledges that someof the requirements are "unknowable" until customers and users start using thesystem.Use peer reviews and inspections of all requirements work products.

Use an industry-strength automated requirements tool.o Assign attributes to each requirement.o Provide traceability.o Maintain the history of each requirement.

Page 11


12/40


Use requirements gathering techniques that are known, familiar, and proven inthe organization such as requirements workshops, prototyping, andstoryboards.Provide members of the project team (including requirements analysts) whoare domain/subject matter experts.Evolve a project and organizational approach based on successful use of

policy, process, methods, techniques, and tools. Provide a mechanism such asworking groups to share information and "best practices" among projects.Establish a continuous improvement ethic, teamwork approach, and a qualityculture.Involve customers and users throughout the development effort.Perform requirements validation and verification activities in the requirementsgathering process to ensure that each requirement is testable.

Page 12


13/40


14/40


quality attributes and other information such as interface characteristics. Manydevelopers believe that use cases and scenarios (descriptions of sequences of events)facilitate team communication. They provide a context for the requirements byexpressing sequences of events and a common language for end users and thetechnical team.

Storyboards: A storyboard is a set of drawings depicting a set of user activities thatoccur in an existing or envisioned system or capability. Storyboards are a kind of

paper prototyping. Customers, users, or developers start by drawing pictures of thescreens, dialogs, toolbars, and other elements they believe the software should

provide. The group continues to evolve these until real requirements and details areworked out and agreed upon. Storyboards are inexpensive and eliminate risks andhigher costs of prototyping.

Interfaces Analysis: Missing or incorrect interfaces are often a major cause of costoverruns and product failures. Identifying external interfaces early clarifies productscope, aids risk assessment, reduces product development costs, and improvescustomer satisfaction. The steps of identifying, simplifying, controlling, documenting,communicating, and monitoring interfaces help to reduce the risk of problems relatedto interfaces.

Modeling: A model is a representation of reality that is intended to facilitateunderstanding. The core requirements tool has behavioral modeling capabilities.Behavior is allocated to physical components of the planned system. Use of prototypesand models helped eliminate ambiguities and inconsistencies and correlated with themost successful projects.

Page 14


15/40


16/40


THERE ARE DIFFERENT PHASES INVOLVED AND AT THE END OF EACHPHASE CERTAI MILESTONES IS REACHED.

The very first phase is the inception phase. The basic goal in the inception phase is tounderstand the cope of the entire project, building the business cases and to get thestakeholders approval to proceed with the next phase. Once the inception phase isreached we would have the stakeholders agreement the estimation of the cost adschedule and the most important part of prioritizing the requirements.

Once we have reached the elaboration phase the major goal is to reduce the technicalrisk and basically understand what it takes to build the system. Once all the relevantconsiderations have been studied we would have an estimate of the architecture as tohow stable it is and if the product is stable or not.

The construction phase and the transition phase are more so in the control of thetechnical team who upon studying the use cases and relevant documents start the work of building the system. Once the product is released it is of utmost importance tosatisfy the user requirements and have achieved that without going above theestimated cost.

The various rational tools that are involved area. Test manager: to manually manage the software testing process.

b. Rational rose: object modeling toolc. Rational robot: testing tool for functional and performance testing.d. Rational clearquest: to manage changes in the request.e. Rational clear case: version control

Agile Methodology

The Agile project carried out was basically to understand better ways of developingsoftware by doing it and helping others do it.

Things such as Individuals and interactions, working software, Customer collaboration,Responding to change is valued more than the items on the right.

The principles of agile configurations for RUP are basically to start by selecting asmall set of critical artifacts. If there is any doubt about a particular artifact the processis to skip it.

Page 16


17/40


The project will be carried out by basically a group of 10 developers over period of 18months and the issues such as delivering the product to the market is of extremeimportance as well staying within the budget.

As in every project there are also some recommendations involved for long term planning. For every iteration there are certain aspects that are involved. Iterationsshould be defined by specifying the start and end dates, the major objectives and the

planned release are the other aspects that would be involved; every iteration carriedout has a certain objective as to implement the first version and then on up gradation.Since the agile project is a long the period of each iteration would be long.in every phase of the project the number of iterations can vary .for the inception phasethere are 1 to 2 iterations, elaboration phase has 2 to 4 iterations, construction phasehas 2 to 5 iterations and transition phase has 1 to 3 iterations.

Irrespective to the short or long term planning the customer must be involved initeration planning. to track the progress there are people assigned to manage theiterations .during the course of the project there would be one meeting per week for acouple of hours.The estimation of the project agile will be done based on the previous experiences,expert judgment.The deliverables involved for the inception phase would be basically prioritizing listof system features, description of important use cases, risk analysis. The typical effortinvolved for the inception phase is 10% of the overall project.

The agile project will have separate contracts for all the phases .at the end of theinception phase we would have the first version of the list of requirements, featuresidentified and use cases implemented. At the end of elaboration 80% of features anduse cases briefly should have been described.

The architecture of the agile project will basically have 4+1 views involved1. Logical view.2. Implementation view.3. Use case view.4. Process view.5. Deployment view.

The rational tools involved in this project will help keep the design and cod in syncautomatically.

Page 17


18/40


Extreme Programming

Extreme Programming (or XP ) is a software engineering methodology , the most prominent of several agile software development methodologies, prescribing a set of daily stakeholder practices that embody and encourage particular XP values (below).Proponents believe that exercising these practicestraditional software engineering

practices taken to so-called "extreme" levelsleads to a development process that ismore responsive to customer needs ("agile") than traditional methods, while creatingsoftware of better quality.

Proponents of XP and agile methodologies in general regard ongoing changes torequirements as a natural, inescapable and desirable aspect of software development

projects; they believe that adaptability to changing requirements at any point during

the project life is a more realistic and better approach than attempting to define allrequirements at the beginning of a project and then expending effort to controlchanges to the requirements.

Page 18
http://en.wikipedia.org/wiki/Methodology_(software_engineering)http://en.wikipedia.org/wiki/Extreme_Programming#Practiceshttp://en.wikipedia.org/wiki/Extreme_Programming#XP_valueshttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Methodology_(software_engineering)http://en.wikipedia.org/wiki/Extreme_Programming#Practiceshttp://en.wikipedia.org/wiki/Extreme_Programming#XP_valueshttp://en.wikipedia.org/wiki/Requirement


19/40


9. Requirement Gathering Tools

Requisite Pro

Rational RequisitePro solution is a requirements and use case management toolfor project teams who want to improve the communication of project goals,enhance collaborative development, reduce project risk and increase thequality of applications before deployment.

1. Uses advanced integration with Microsoft Word to provide afamiliar environment for activities such as requirementsdefinition and organization

2. Incorporates a powerful database infrastructure with real-timeWord document synchronization to facilitate requirementsorganization, integration and analysis

3. Enables detailed attribute customization and filtering tomaximize informative value of each requirement

4. Provides detailed traceability views that display parent/childrelationships and show requirements that may be affected byupstream or downstream change.

5. Performs project-to-project comparisons using exportableXML-based project baselines

Integrates with multiple tools in the IBM Software Development Platform to improveaccessibility and communication of requirements

Page 19


20/40


10. Unified Modeling Language

In the field of software engineering, the Unified Modeling Language (UML) is astandardized specification language for object modeling . UML is a general-purposemodeling language that includes a graphical notation used to create an abstract modelof a system , referred to as a UML model .

UML is officially defined at the Object Management Group (OMG) by the UMLmetamodel, a Meta-Object Facility metamodel (MOF). Like other MOF-basedspecifications, the UML metamodel and UML models may be serialized in XMI.UML was designed to specify, visualize, construct, and document software-intensivesystems.

UML is not restricted to modeling software. UML is also used for business processmodeling, systems engineering modeling, and representing organizational structures.The Systems Modeling Language (SysML) is a Domain-Specific Modeling languagefor systems engineering that is defined as a UML 2.0 profile.

UML has been a catalyst for the evolution of model-driven technologies, whichinclude Model Driven Development (MDD), Model Driven Engineering (MDE), andModel Driven Architecture (MDA). By establishing an industry consensus on agraphic notation to represent common concepts like classes, components,generalization, aggregation, and behaviors, UML has allowed software developers toconcentrate more on design and architecture.

UML models may be automatically transformed to other representations (e.g. Java) bymeans of QVT-like transformation languages, supported by the OMG.

UML is extensible, offering the following mechanisms for customization: profiles andstereotype. The semantics of extension by profiles have been improved with the UML2.0 major revision.

Page 20
http://en.wikipedia.org/wiki/Object_modeling_languagehttp://en.wikipedia.org/wiki/Systemhttp://en.wikipedia.org/wiki/QVThttp://en.wikipedia.org/wiki/Object_Management_Grouphttp://en.wikipedia.org/wiki/Profile_(UML)http://en.wikipedia.org/wiki/Object_modeling_languagehttp://en.wikipedia.org/wiki/Systemhttp://en.wikipedia.org/wiki/QVThttp://en.wikipedia.org/wiki/Object_Management_Grouphttp://en.wikipedia.org/wiki/Profile_(UML)


21/40


11.Business Requirements Document

< PROJECT NAME >Business Requirement Document

Version: < 0.0 >

[Note: Text enclosed in square brackets and displayed in blue italics(style= InfoBlue ) is included to provide guidance to the author and should be

deleted before publishing the document. Text entered above (style=InfoBlue) andbelow the heading will automatically be set to body text].

Revision HistoryDate Version Description Author

Page 21


22/40


23/40


Overview DescriptionThis section of the BRD describes the general factors that affect the product and itsrequirements. This section does not state specific requirements. Instead, it provides a

background for those requirements, which are defined in detail in Section 3, andmakes them easier to understand. Include such items as:

Product perspectiveProduct functionsUser characteristicsConstraintsAssumptions and dependenciesRequirements subsets

Specific RequirementsThis section of the BRD contains all software requirements to a level of detailsufficient to enable designers to design a system to satisfy those requirements, andtesters to test that the system satisfies those requirements. When using use-casemodeling, these requirements are captured in the Use Cases and the applicablesupplementary specifications. If use-case modeling is not used, the outline for supplementary specifications may be inserted directly into this section, as shown

below.

Functional Requirements Specifications

This section describes the functional requirements of the system for thoserequirements that are expressed in the natural language style. For many applications,this may constitute the bulk of the BRD package and thought should be given to theorganization of this section. This section is typically organized by feature, butalternative organization methods may also be appropriate; for example, organization

by user or organization by subsystem. Functional requirements may include featuresets, capabilities, and security.Where application development tools, such as requirements tools, modeling tools, andthe like, are employed to capture the functionality, this section of the document wouldrefer to the availability of that data, indicating the location and name of the tool usedto capture the data.

The requirement description goes here

Page 23


24/40


UsabilityThis section includes all those requirements that affect usability. For example, specifythe required training time for a normal users and a power user to become productive at

particular operations specify measurable task times for typical tasks or base the newsystems usability requirements on other systems that the users know and like specifyrequirement to conform to common usability standards, such as IBMs CUA standardsMicrosofts GUI standards

The requirement description goes here.

ReliabilityRequirements for reliability of the system should be specified here. Some suggestionsfollow:Availabilityspecifies the percentage of time available (xx.xx %), hours of use,maintenance access, degraded mode operations, and so on.Mean Time Between Failures (MTBF) this is usually specified in hours, but itcould also be specified in terms of days, months or years.Mean Time To Repair (MTTR)how long is the system allowed to be out of operation after it has failed?Accuracyspecifies precision (resolution) and accuracy (by some known standard)that is required in the systems output.Maximum Bugs or Defect Rateusually expressed in terms of bugs per thousandlines of code (bugs/KLOC) or bugs per function-point (bugs/function-point).Bugs or Defect Ratecategorized in terms of minor, significant, and critical bugs: therequirement(s) must define what is meant by a critical bug; for example, completeloss of data or a complete inability to use certain parts of the systems functionality.

The requirement description goes here .

PerformanceThe systems performance characteristics are outlined in this section. Include specificresponse times. Where applicable, reference related Use Cases by name.Response time for a transaction (average, maximum)Throughput, for example, transactions per secondCapacity, for example, the number of customers or transactions the system canaccommodate

Page 24


25/40


Degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner)Resource utilization, such as memory, disk, communications, and so forth.


SupportabilityThis section indicates any requirements that will enhance the supportability or maintainability of the system being built, including coding standards, namingconventions, class libraries, maintenance access, and maintenance utilities.


Design ConstraintsThis section indicates any design constraints on the system being built. Designconstraints represent design decisions that have been mandated and must be adheredto. Examples include software languages, software process requirements, prescribeduse of developmental tools, architectural and design constraints, purchasedcomponents, class libraries, and so on.


On-line User Documentation and Help System RequirementsDescribes the requirements, if any, for o-line user documentation, help systems, helpabout notices, and so forth.

Purchased ComponentsThis section describes any purchased components to be used with the system, anyapplicable licensing or usage restrictions, and any associated compatibility andinteroperability or interface standards.

Page 25


26/40


27/40


could include legal, quality and regulatory standards, industry standards for usability,interoperability, internationalization, operating system compliance, and so forth.

Supporting InformationThe supporting information makes the BRD easier to use. It includes:Table of contentsIndexAppendicesThese may include use-case storyboards or user-interface prototypes. Whenappendices are included, the BRD should explicitly state whether or not theappendices are to be considered part of the requirements.

Page 27


28/40


12. Use Case Document

Note: Each time a document is delivered for review to anyone, the next version delivered should have a differentversion number. Reviewers would modify the name of the document by adding their initials to the name asdelivered by the writer and should NOT change the version number. Only the document owner should change theversion number.

General InformationSummary Brief description of the business process that will utilize the system as described in the use case. Include verbiage to

put in context of overall process.Guarantees Brief description of the end state of the use case and any guaranteed outcomes. E.g. for Condo process, the end state

may be confirmation that a condominium project is approved for mortgage lending by Client,Pre-

Conditions

Any activity that must have occurred for the first step to execute. e.g. User has successfully logged in to the system

Trigger Brief description of event(s) required for execution of the use case. This is particularly relevant to Use Cases thataddress only system actions. E.g. if the use case defines the system actions to order and receive a credit report , theremay be no pre-conditions, only a trigger that user has selected Order Credit on a any screen.

Actors List of all actors included in the use case e.g. Authorized User. For a list of actors, see the Roles list in Addendum 1.If a required Role is not in the list, add the Role to the Actor list and identify the Role as New Role e.g. Clerk (NewRole)

Page 28

Version Description Author Date1 Initial Draft (Each document will have the first row

description of Initial Draft).Writers name Completion Date (or

publish data)2 Subsequent rows should have a description of the changes

were made or why modifications have been made. e.g.Modifications based on client feedback or Final Version


29/40


RequirementsList all requirements from the BRD that are covered by this use case. As with all tables in a use case, there should

be no blank fields. If the information is not available or not required, enter N/A or None.

For the How Addressed section, give a brief description of how each requirement is being addressed, for examplelink or reference to the section of the use case where it is addressed. If it is determined that all or part of therequirement has been deferred or is no longer a requirement, highlight in yellow.

Use Case StepsIn a use case, the possible actors are user and system only. If a user needs specific security to access the definedsection of the system, that information should be listed as a Pre-condition above.

Main FlowStep

Number User Action Step

Number (System) Reaction Notes

1

A user action may or may not berequired. If no user action is requiredto begin a use case, this field shouldcontain None.

2System reaction be sure toinclude any error messages thatmay result from a user action.

IncludeComments/clarifications/ Linksto any sectionor Illustrations

3

No field in this table should be left blank. If there is no relevantinformation required for a field, enter N/A or None

4

If the next step has two possible paths, select one for the main flowand reference the alternate flow for the other(s)

None

Page 29

Req # Req.Title

Description Other Comment Gap Comment How Addressed


30/40


Exception # NameEach exception has a unique number and name. Name should give context of what is accomplished in the extensionor why it is required.

Post Use Case

Identify use cases that connect to this use case. If an alternate flow is defined in a separate use case, the use caseshould be named in the appropriate location in the use case table above as well as listed in this section.

Page 30

Step Number User Action

Step Number (System) Reaction Notes

1 Each step in an alternate flow shouldhave a unique number 2

Point in Main Flow where thisalternate flow initiates should beincluded at the beginning of this firststep.

None


31/40


Data ElementsThis section references data elements discussed in the use case and any new fields being added to screens. Any newfields that are required must be listed in the table.

Gap Analysis

Requirements that have been deferredList all requirements that are in the functional specification group that have been deferred. If no requirements have

been deferred, enter None

New Requirements

Page 31

Business Name Description Data Type / Length Comments / Values Validation Rules

The businessname for the field,as referenced inthe use case

BusinessDescription of thefield

The Screen on whichthe field appears, andthe Field Label. If the field appears onmultiple screens,indicate the one most

pertinent to the usecase.

Note: If the screenhas not yet beendeveloped, refer tothe Activity and the

proposed field label,which will befinalized duringDesign.

Any additional requirements.For a New field, include validvalues if known.

Example: Not Null (This filedshould not be left blank)


32/40


List all requirements that have been added due to gaps in the requirements matrix. If there are no new requirements,enter None.

Assumptions and DependenciesList all other assumptions and dependencies. e.g. Dependencies on other groups, FSGs, or concurrent projects.

Illustrations

Each illustration should be numbered. If using an existing screen shot, the existing name and file date should also be noted. Modifications to screens can be annotated via drawing tools in Word.

Use Case Sign-Off

________________________ _________________________ Name: / Date: Name / DateFor Client - Technology For Client Business User

Page 32


33/40


13.Test Case Document

Test CaseIdentifier:

Heading to the TESTCASE (It can be the TC

Number and Name)

Borrower Name:

Co Borrower Name:

Loan Number (last threenumbers)

System Name:

Prepared By: Date:

Tested By: Date:

Retested By: Date:

Test Description: Please enter a description for the Test Case

Test Prerequisites: Pre-Conditions for this Test Case

Comments: Enter Comments If any

Scenario # & Name:

Page 33


34/40


35/40


14.Frequently Asked Questions

FAQ 1: What are your main responsibilities as Business analyst? What exactlythe business analysts do? What is the expertise of the Business analyst?

As a business analyst you have to have extensive experience in "Understanding theBusiness Process, Defining Scope of the Project and Understanding User Requirements and BUSINESS RULES and articulate them in to User andFunctional Requirement Specification. (It is most important skill because a singlemissed or miss communicated requirement may cost hours of software developmenteffort when introduced later on.)

As a business analyst one frequently interacts with User by interviewing them, by preparing questionnaire and getting feedback and recording sessions, Business Analystalso interact with System Analyst, Developers, Management, Deployment andSupport Staff and other Stake Holders and facilitate Communication between theClient and IT department thus developing excellent co-ordination, negotiation andinterpersonal skills.

Business Analyst also has the skills to work as a User\Customer Advocate and skills tonegotiate with user as well as with developers and management staff to resolve anyrequirement conflict. Setup a change requirement management system to track changing requirements of the projects.

Business Analyst is actively involved in gathering & converting User Requirementsinto business requirements and functional specification, create use case diagrams,

business flow diagrams, Activity/State Diagram and Sequence diagram so thedevelopers and other stake holders can understand the business process according totheir perspective with possible alternate scenarios. Business Analyst should have theskills to understand the business rules and effectively implementing them in toBusiness Process Flow.

As a Business Analyst one is required to conduct Joint Application Development(JAD) Sessions, conduct the Functional Requirement Specifications (FRS), User Requirement Specifications (URS), Use Cases (UC) reviews and walkthroughs withdesigners, developers and stakeholders, Responsibilities also include doing feasibilitystudy, adaptability study and risk analysis to identify the business critical or high-risk areas of business application from USER perspective.

Page 35


36/40


Business Analysts can also convey to the User or Client If requirements are notfeasible by using simple presentation to make them aware of the critical area of the

business application, so later there will no conflicts between User/Clients and thestakeholders and also suggest work around.

Business Analyst woks as a liaison between user and technical staff to resolve anyconflicts; A Business Analyst is a creative problem finder and a person who resolvesconflicts with excellent interpersonal and communication skill. Though a BusinessAnalyst is never involved in solving a problem but aides in many by forming a

platform between the user community and the technical community.

Page 36


37/40


FAQ 2: Briefly summarize a Business Analyst work experience.

An experienced Business Analyst (BA) should have extensive experience in the fieldof business analysis, risk analysis and software validation for client\server and, web

based applications.

Diverse projects spanning a wide range if industries like pharmaceutical, Financial,Insurance & Mortgage Companies to name a few; Responsibilities would includeactively involve in understanding different business processes, defining scopes of various projects, interacting with wide variety of users and dealing with varying

business environments.

FAQ 3: Who does the Business Analyst Interact with?

While working during different phases of variety of projects, BAs usually interactwith the following:

1. Senior Management2. Project Managers3. Key Stake holders4. Subject Mater Experts5. System Engineers6. System Architects7. Designers8. Developers

FAQ 4: What is the Pre requisite for a Business Analyst?

A good Business Analyst must poses the following

1. Excellent Communication2. People Skills3. Strong knowledge of the Business4. Pay Attention to Detail5. Document writing skills6. Professional Approach7. Organization Skills8. Very good Team player 9. Patience10. Perseverance

Page 37


38/40


FAQ 5: What is Business Modeling?

Business modeling is a technique to model business processes. Business models provide ways of expressing the business processes in terms of business activities andcollaborative behavior. Models are helpful to document and comprehend complexity.They are powerful for two main reasons:

They make communication easier,They allow the easy manipulation of solutions without affecting the thing beingmodeled.

This can be further explained with an example:Think about building a skyscraper. No one would dream of a major construction

project without thorough blueprints. Thats a blueprint, because its important to notonly have one plan of the skyscraper you need to have multiple plans. Theelectrician needs a view to show where the wiring goes. The plumber needs another

plan so he doesnt put a sink in the elevator. And the carpenters need to know where to put this expensive crown molding in the CEOs office. Different workers needdifferent views of what theyre trying to build. And thats what were doing withsoftware.

That different view is what we mean when we talk about the logical view, the usecase view, the component view, and the deployment view all the different views of the application under construction. Business modeling helps simplify and visualizethe business process.

FAQ 6: Define UML?

The UML is the standard language for specifying, visualizing, constructing, anddocumenting all the artifacts of a software system.

FAQ 7: What do you think is the primary use of activity diagrams and how doyou represent them? What is the purpose?

Primary use of activity diagram is to show Business Work Flow considering activitystate and action completed

Activity Diagrams are used mostly to show where each use case in an activity or howthings flow between Use CasesActivity diagram can be used to relate each use case with the set of activity, sotechnical team can understand that the different set of users who perform different

Page 38


39/40


activities with varying set of privileges to access the system and doing the specificactivity. This was very helpful tool when we have diverse set of users.

FAQ 8: When and in what phase and how do you use the use case diagram?

Use Case (UC) diagrams are drawn early in the Analysis Process.It is basically A Series of related transaction performed by an ACTORBefore we draw the UC Diagram we begin by asking questions like

Who are the users of the application?What exactly does the user want from the system?What value does application provide to the user?

Then the UC Diagram is drawn

FAQ 9: What is a Use CaseA use case is a technique used to capture the functional requirements of a system. Usecases describe the interaction between a primary actorthe initiator of the interaction

and the system itself, represented as a sequence of simple steps. Actors aresomething or someone which exist outside the system under study, and who (or which) take part in a sequence of activities in a dialogue with the system, to achievesome goal: they may be end users, other systems, or hardware devices. Each use caseis a complete series of events, from the point of view of the actor

FAQ 10: How do I work with Activity Diagram?Activity Diagram is used early in the analysis and design phase as it shows theBusiness Work Flow considering activity state and action completed. ActivityDiagrams illustrate how things flow between Use CasesActivity diagram is used to relate each use case with the set of activity, so technicalteam can understand that the different set of users doing different activity with varyingset of privileges to access the system. Since we have diverse set of users this was veryhelpful tool

FAQ 11: How can sequence diagrams help in the business understanding?Sequence diagram shows Objects interaction arranged in Time Sequence. It is a greattool for deriving requirements, and hence used during the process of requirementsgathering.Sequence diagrams give thee process flow in the system in sequence of time. Thishelps the Systems Analysts, Developers and Testers understand simple to complexscenarios in a better way, avoiding ambiguity of representation

Page 39


40/40


FAQ 12: We have diverse teams of user and group of researchers, how would oneapproach towards getting user requirement?The following approach need to be done in order to effectively elicit requirements.

Ask questions to Subject Matter Expert to fully understand the business process and project proposal, define the scope.Identify different set of user for the application.Understand the concern and the perspective of each set of user and toidentify

How exactly is each set of users want to use the application? What exactly the user want from the system? What value does application provide to the user? High Level Use case Model story boarding, SME, Users

Identify different privileges that each set of user will be assigned.Prepare different set of questions for different users and try to get as muchas information. This might be an iterative process.Set up meeting with different users. Conduct interviews or record thesession with the different set of users.

What do you want to change? Why do you want to change?How would you like to do it? Is there anything else that you do?Asking over and over to get more information.

Go to the user site and ask them for any documentation they might bemaintaining to fully understand what exactly they are looking from theapplication.Request each set of users to review the requirements and Sign-off thedocuments, to avoid conflicts at a later stage.Create the Business Model for better understanding and visualization of the

business process.Create the final FRS based in URS once finalized by the technical team.

FAQ 13: How exactly does one convey the understanding to the users?Make it as simple as possible. Create Power Point presentation or request the graphicdesigner or developer to create the prototype of the system and set up a meeting with

user and walkthrough the whole application, giving them clear picture of what exactlythe application will look like and also take the feed back from them. Also createtemplates for the user to submit any changes so they can effectively request thechange.

ba material

Documents