Business Analysis Tutorial

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 .............................................................................................16 Extreme 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

Business Analysis Tutorial

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 project implementation issues. Conduct analysis at a sufficient level of detail to determine the essential functionality of the application expressed as use cases or user stories (shall deal with these later)

Capture information flows and determine general data storage and retrieval requirements. Efficiently transfer the high-level analysis products, use cases and process diagrams, to the development team. Assist clients with transition planning, data migration, administrative process redesign 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

Business Analysis Tutorial

2. Pre Requisites:
Communication Skills: Business Analysis is all about communication, both Oral and written. Besides any thing a Business Analyst interacts with various stakeholders and does documentation extensively. Therefore to excel as a Business Analyst, Written and Oral Communication Skills are very vital. Software Industry: General Over view of Software Industry like: Client Server Applications: Examples: Visual Basic, PowerBuilder. Web based Applications: Examples: Html, Xml Programming languages: Examples: Java, C++, ASP, .Net. Databases: Examples: Oracle, Sal Server, Sybase, DB2, Sybase, Access. o Technologies: IBM Websphere, BEA Weblogic, Microsoft .Net, ATG Dynamo. o o o o Other Stakeholders: within the project and their responsibilities namely: o o o o o o Project Manager Technical Architect Programmers Database developers Database Administrators Quality Assurance Analysts

Page 4

Business Analysis Tutorial

3. Role & Responsibilities of a Business Analyst

A Business Analyst is the key behind the development of a system, where he is the interface between the stakeholders from who he gets out what exactly they want and communicate to the Development team, so that they build the system accordingly. In IT (software) Industry typically a Business Analyst would gather the requirements for a developing software system. Requirements could be classified into the following types. Functional Requirements: Functional requirements are associated with specific functions, tasks or behaviours the system must support. In terms of the ISO quality characteristics for evaluation, the functional requirements address the quality characteristic of functionality Non Functional Requirements (Supplementary requirements): Non Functional Requirements are also called the 'ilities' because they are most simply expressed like this: Usability Reliability Interoperability Scalability Security Time to market Cost Speed RAM Secondary storage Non-functional requirements are adverbially related to tasks or functional requirements: how fast, how efficiently, how safely, etc., is a particular task carried out by a particular system. Graphical User Interface (GUI) Requirements Graphical User Interface Requirements involve developing prototypes; designing mock ups for a system. This also involves defining the various parameters, screen

Page 5

Business Analysis Tutorial

controls (e.g. Text Box, Radio Button, Check Box, Label, Combo Box etc), various types of validations on a User Interface screen.

Page 6

Business Analysis Tutorial

Example of the tasks performed by a Business Analyst Let us try to understand the role of a Business Analyst at a greater detail taking an example. Consider that yahoo email does not yet exist. The owners of Yahoo.com came up with 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 Business Analyst apart from various other people in the responsibility of Project Manager, Technical Architect, Programmers, and Database developers/Administrators, Quality Analysts 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 they could develop (program) to build the system. Identify the requirements at a high level Every user is required to register on to yahoo before being able to email Every user is required to sign on to their site before being able to email Yahoo email has search capability Yahoo email has calendar features. Now think of other features of yahoo, which could be categorized into High-level requirements. 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 Name 2. Last Name 3. 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 and If the information correct then redirect the user to the Inbox page Else Redirect the user back to the sign on page.

Page 7

Business Analysis Tutorial

GUI Requirements: Come up with the Graphical User Interface Prototypes for various screens.

New to Yahoo? . . 100MB of email storage Keep more of what's important to you Powerful spam protection Read only the mail you really want Get your mail anywhere All you need is a web connection. Learn More Sign Up

Yahoo Id Password Submit

Now think of how to come up with the GUI requirements for other screens as well. Non-Functional Requirements Yahoo mail should support the load of more than 100, 000 users logging on the site at a time. Yahoo mail login should used to link to other yahoo features like groups. Yahoo.com, Briefcase.yahoo.com etc Yahoo mail should be able to generate revenue of $ 2.5 billion /yr.

Page 8

Business Analysis Tutorial

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 these issues. Ambiguities, incompleteness, and inconsistencies that can be resolved in the requirements phase typically cost orders of magnitude less to correct than when these same issues are found in later stages of product development. Requirements analysis strives to address these issues. There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they 1. Take a long time to produce 2. Begin to limit the implementation options available 3. Are costly to produce

Writing Requirements Requirements are written in such a way that they direct the creation/modification of a system according to the business rules appropriate to the domain in which the system will be used. Systems should normally conform to the business domain of operation. The general form of a requirement looks like.. "who shall what". Example: "The contractor 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 requirements are altered before the system is complete. This characteristic of requirements has led to requirements management studies and practices. Disputes regarding the necessity of rigor in software requirements Some modern software engineering methodologies like extreme programming question the need for rigorously describing software requirements, which they consider a moving target. Instead, they describe requirements informally using user stories (short summaries fitting on an index card explaining one aspect of what the system should do), and compose a series of acceptance test cases for this user story.

Page 9

Business Analysis Tutorial

5. Gathering Effective Requirements

To develop software projects on time and budget there is nothing more important than gathering and clearly defining the requirements. In defining requirements, you are not specifying how the software will be built, but exactly what you need your software to do. According to Steve McConnell in Software Project Survival Guide, "The most difficult part of requirements gathering is not documenting what the users 'want'; it is the effort of helping users figure out what they 'need' that can be successfully provided within 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 to develop a new or modified system or capability and describes the system to be developed. The next step is to gather the stated requirements of the customers and users of the new capability. An effective requirements practice distinguishes stated requirements from real requirements. Industry experience has shown that customers and system developers should jointly evaluate stated requirements to ensure that each is a verified need. 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. It is also beneficial to focus on product benefits, not features. Benefits refer to the necessary requirements. Adding unnecessary features adds design constraints and increases costs. It is estimated that 85 percent of the defects in developed software originate in the requirements. Once defects are embedded in the requirements, they tend to resist removal. They are especially difficult to find via testing. Therefore it is crucial that training be required for requirements analysts and engineers that explain how to reduce 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 a more accurate requirements specification and higher customer satisfaction. One of our most common problems is attempting to exceed requirements rather than addressing the minimum requirements to meet real needs. Thus, meeting minimum requirements is in the customers best interests. It helps avoid the problems of late deliveries, budget overrun, low moral, and poor quality.

Page 10

Business Analysis Tutorial

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 acceptable to and used by customers/users and the developers, and a list of acronyms to facilitate effective communication. Evolve the real requirements via a "joint" customer/user and developer effort. Focus on product benefits (necessary requirements), not features. Address the minimum and highest priority requirements needed to meet real customer and user 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 requirements working with customers and users, not to invent requirements independently or to "gold plate." o How to write good requirements? o The types of requirements errors and how these can be reduced o The value of investing more in the requirements process o The organization's requirements process o 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 new requirements. Prioritize the real requirements to determine those that should be met in the first 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 some of the requirements are "unknowable" until customers and users start using the system. 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

Business Analysis Tutorial

Use requirements gathering techniques that are known, familiar, and proven in the organization such as requirements workshops, prototyping, and storyboards. Provide members of the project team (including requirements analysts) who are 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 as working groups to share information and "best practices" among projects. Establish a continuous improvement ethic, teamwork approach, and a quality culture. Involve customers and users throughout the development effort. Perform requirements validation and verification activities in the requirements gathering process to ensure that each requirement is testable.

Page 12

Business Analysis Tutorial

7. Preferred Requirements Gathering Techniques

Following are a set of recommended requirements elicitation techniques. Interviews: Interviews are used to gather information. The use of context-free questions by the interviewer helps avoid prejudiced and biased response of the person being interviewed. A context-free question is a question that does not suggest a particular response. Document Analysis: All effective requirements elicitation involves some level of document analysis such as business plans, market studies, contracts, requests for proposals, statements of work, existing guidelines, analyses of existing systems, and procedures. Brainstorming: Brainstorming involves both idea generation and idea reduction. The goal of the former is to identify as many ideas as possible, while the latter ranks the ideas into those considered most useful by the group. Brainstorming is a powerful technique because the most creative or effective ideas often result from combining seemingly unrelated ideas. Requirements Workshops: Requirements workshops are designed to encourage consensus concerning the requirements of a particular capability. They are best facilitated by an outside expert and are usually for a few days. Benefits of requirements workshops are lower costs, gives a structure to the requirement process, dynamic, interactive, help to identify and prioritize needs. Joint Application Development (JAD): is a special category of requirements workshop. JAD is a method for developing requirements through which customers, user representatives, and developers work together with a facilitator to produce a requirements specification that both sides support. This is an effective way to define user needs early. Prototyping. Prototyping is a technique for building a quick and rough version of a desired system or parts of that system. The prototype illustrates the capabilities of the system to users and designers. It serves as a communications mechanism to allow reviewers to understand interactions with the system. Use Cases: A use case is a picture of actions a system performs, depicting the actors. It should be accompanied by a textual description and not be used in isolation of other requirements gathering techniques. Use cases should always be supplemented with

Page 13

Business Analysis Tutorial

quality attributes and other information such as interface characteristics. Many developers believe that use cases and scenarios (descriptions of sequences of events) facilitate team communication. They provide a context for the requirements by expressing sequences of events and a common language for end users and the technical team. Storyboards: A storyboard is a set of drawings depicting a set of user activities that occur in an existing or envisioned system or capability. Storyboards are a kind of paper prototyping. Customers, users, or developers start by drawing pictures of the screens, dialogs, toolbars, and other elements they believe the software should provide. The group continues to evolve these until real requirements and details are worked out and agreed upon. Storyboards are inexpensive and eliminate risks and higher costs of prototyping. Interfaces Analysis: Missing or incorrect interfaces are often a major cause of cost overruns and product failures. Identifying external interfaces early clarifies product scope, aids risk assessment, reduces product development costs, and improves customer satisfaction. The steps of identifying, simplifying, controlling, documenting, communicating, and monitoring interfaces help to reduce the risk of problems related to interfaces. Modeling: A model is a representation of reality that is intended to facilitate understanding. The core requirements tool has behavioral modeling capabilities. Behavior is allocated to physical components of the planned system. Use of prototypes and models helped eliminate ambiguities and inconsistencies and correlated with the most successful projects.

Page 14

Business Analysis Tutorial

8. Requirement Gathering Methodologies

Waterfall Model
The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. W. W. Royce often cites the origin of the term waterfall, ironically though; although Royce advocated an iterative approach to software development he did not use the term "waterfall."

Rational Unified Process

Rational Unified Process (RUP) is a software development approach that is iterative, architecture-centric, and use-case driven. it is a well-defined and well-structured software engineering process. It defines who is responsible for what, how things are done, when to do them. RUP also defines the structure for the lifecycle of a project, pointing out the essential milestones and decision points. Above all RUP is a process product that provides you with customizable process framework for software engineering. Requirements are expressed as use cases and features. It is an approach that covers all activity. It is a product of IBM. The most important thing to note is that RUP is not a project management tool or a substitute for first class developers. ARCHITECHTURE OF RUP IS

Page 15

Business Analysis Tutorial

THERE ARE DIFFERENT PHASES INVOLVED AND AT THE END OF EACH PHASE CERTAI MILESTONES IS REACHED. The very first phase is the inception phase. The basic goal in the inception phase is to understand the cope of the entire project, building the business cases and to get the stakeholders approval to proceed with the next phase. Once the inception phase is reached we would have the stakeholders agreement the estimation of the cost ad schedule and the most important part of prioritizing the requirements. Once we have reached the elaboration phase the major goal is to reduce the technical risk and basically understand what it takes to build the system. Once all the relevant considerations have been studied we would have an estimate of the architecture as to how 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 the technical 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 to satisfy the user requirements and have achieved that without going above the estimated cost. The various rational tools that are involved are a. Test manager: to manually manage the software testing process. b. Rational rose: object modeling tool c. 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 developing software 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 a small set of critical artifacts. If there is any doubt about a particular artifact the process is to skip it.

Page 16

Business Analysis Tutorial

The project will be carried out by basically a group of 10 developers over period of 18 months and the issues such as delivering the product to the market is of extreme importance 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. Iterations should 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 carried out 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 phase there are 1 to 2 iterations, elaboration phase has 2 to 4 iterations, construction phase has 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 in iteration planning. to track the progress there are people assigned to manage the iterations .during the course of the project there would be one meeting per week for a couple 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 list of system features, description of important use cases, risk analysis. The typical effort involved 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 the inception phase we would have the first version of the list of requirements, features identified and use cases implemented. At the end of elaboration 80% of features and use cases briefly should have been described. The architecture of the agile project will basically have 4+1 views involved 1. 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 sync automatically.

Page 17

Business Analysis Tutorial

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 is more responsive to customer needs ("agile") than traditional methods, while creating software of better quality. Proponents of XP and agile methodologies in general regard ongoing changes to requirements 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 all requirements at the beginning of a project and then expending effort to control changes to the requirements.

Page 18

Business Analysis Tutorial

9. Requirement Gathering Tools

Requisite Pro Rational RequisitePro solution is a requirements and use case management tool for project teams who want to improve the communication of project goals, enhance collaborative development, reduce project risk and increase the quality of applications before deployment. 1. 2. 3. 4. 5. Uses advanced integration with Microsoft Word to provide a familiar environment for activities such as requirements definition and organization Incorporates a powerful database infrastructure with real-time Word document synchronization to facilitate requirements organization, integration and analysis Enables detailed attribute customization and filtering to maximize informative value of each requirement Provides detailed traceability views that display parent/child relationships and show requirements that may be affected by upstream or downstream change. Performs project-to-project comparisons using exportable XML-based project baselines

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

Page 19

Business Analysis Tutorial

10. Unified Modeling Language

In the field of software engineering, the Unified Modeling Language (UML) is a standardized specification language for object modeling. UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model. UML is officially defined at the Object Management Group (OMG) by the UML metamodel, a Meta-Object Facility metamodel (MOF). Like other MOF-based specifications, the UML metamodel and UML models may be serialized in XMI. UML was designed to specify, visualize, construct, and document software-intensive systems. UML is not restricted to modeling software. UML is also used for business process modeling, systems engineering modeling, and representing organizational structures. The Systems Modeling Language (SysML) is a Domain-Specific Modeling language for systems engineering that is defined as a UML 2.0 profile. UML has been a catalyst for the evolution of model-driven technologies, which include Model Driven Development (MDD), Model Driven Engineering (MDE), and Model Driven Architecture (MDA). By establishing an industry consensus on a graphic notation to represent common concepts like classes, components, generalization, aggregation, and behaviors, UML has allowed software developers to concentrate more on design and architecture. UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages, supported by the OMG. UML is extensible, offering the following mechanisms for customization: profiles and stereotype. The semantics of extension by profiles have been improved with the UML 2.0 major revision.

Page 20

Business Analysis Tutorial

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) and below the heading will automatically be set to body text].

Revision History Date Version <mm/dd/yyyy> <v.x>

Description <details>

Author <name>

Page 21

Business Analysis Tutorial

Business Requirements Document Introduction The introduction of the Business Requirements Document (BRD) provides an overview of the entire BRD. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the BRD. Note: The BRD document captures the complete software requirements for the system, or a portion of the system. Following is a typical BRD outline for a project using only traditional, natural-language style requirementswith no use-case modeling. Purpose Specify the purpose of this BRD. The BRD fully describes the external behavior of the application or subsystem identified. It also describes nonfunctional requirements, design constraints, and other factors necessary to provide a complete and comprehensive description of the requirements for the software. Scope A brief description of the software application that the BRD applies to, the feature or other subsystem grouping, what Use-Case model(s) it is associated with, and anything else that is affected or influenced by this document. Definition and Acronyms This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the BRD. This information may be provided by reference to the projects Glossary. Definitions Acronyms References This subsection provides a complete list of all documents referenced elsewhere in the BRD. Identify each document by title, report number if applicable, date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document. Overview This subsection describes what the rest of the BRD contains and explains how the document is organized.

Page 22

Business Analysis Tutorial

Overview Description This section of the BRD describes the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in Section 3, and makes them easier to understand. Include such items as: Product perspective Product functions User characteristics Constraints Assumptions and dependencies Requirements subsets Specific Requirements This section of the BRD contains all software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. When using use-case modeling, these requirements are captured in the Use Cases and the applicable supplementary 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 those requirements 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 the organization of this section. This section is typically organized by feature, but alternative organization methods may also be appropriate; for example, organization by user or organization by subsystem. Functional requirements may include feature sets, capabilities, and security. Where application development tools, such as requirements tools, modeling tools, and the like, are employed to capture the functionality, this section of the document would refer to the availability of that data, indicating the location and name of the tool used to capture the data. <Functional Requirement One> The requirement description goes here

Page 23

Business Analysis Tutorial

Usability This section includes all those requirements that affect usability. For example, specify the 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 new systems usability requirements on other systems that the users know and like specify requirement to conform to common usability standards, such as IBMs CUA standards Microsofts GUI standards <Usability Requirement One> The requirement description goes here. Reliability Requirements for reliability of the system should be specified here. Some suggestions follow: 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 it could 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 thousand lines of code (bugs/KLOC) or bugs per function-point (bugs/function-point). Bugs or Defect Ratecategorized in terms of minor, significant, and critical bugs: the requirement(s) must define what is meant by a critical bug; for example, complete loss of data or a complete inability to use certain parts of the systems functionality. <Reliability Requirement One> The requirement description goes here. Performance The systems performance characteristics are outlined in this section. Include specific response times. Where applicable, reference related Use Cases by name. Response time for a transaction (average, maximum) Throughput, for example, transactions per second Capacity, for example, the number of customers or transactions the system can accommodate

Page 24

Business Analysis Tutorial

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. <Performance Requirement One> The requirement description goes here. Supportability This section indicates any requirements that will enhance the supportability or maintainability of the system being built, including coding standards, naming conventions, class libraries, maintenance access, and maintenance utilities. <Supportability Requirement One> The requirement description goes here. Design Constraints This section indicates any design constraints on the system being built. Design constraints represent design decisions that have been mandated and must be adhered to. Examples include software languages, software process requirements, prescribed use of developmental tools, architectural and design constraints, purchased components, class libraries, and so on. <Design Constraint One> The requirement description goes here. On-line User Documentation and Help System Requirements Describes the requirements, if any, for o-line user documentation, help systems, help about notices, and so forth. Purchased Components This section describes any purchased components to be used with the system, any applicable licensing or usage restrictions, and any associated compatibility and interoperability or interface standards.

Page 25

Business Analysis Tutorial

Interfaces This section defines the interfaces that must be supported by the application. It should contain adequate specificity, protocols, ports and logical addresses, and the like, so that the software can be developed and verified against the interface requirements. User Interfaces Describe the user interfaces that are to be implemented by the software. Hardware Interfaces This section defines any hardware interfaces that are to be supported by the software, including logical structure, physical addresses, expected behavior, and so on. Software Interfaces This section describes software interfaces to other components of the software system. These may be purchased components, components reused from another application or components being developed for subsystems outside of the scope of this BRD but with which this software application must interact. Communications Interfaces Describe any communications interfaces to other systems or devices such as local area networks, remote serial devices, and so forth. Licensing Requirements Defines any licensing enforcement requirements or other usage restriction requirements that are to be exhibited by the software. Legal, Copyright, and Other Notices This section describes any necessary legal disclaimers, warranties, copyright notices, patent notices, word mark, trademark, or logo compliance issues for the software. Applicable Standards This section describes by reference any applicable standard and the specific sections of any such standards, which apply to the system being described. For example, this

Page 26

Business Analysis Tutorial

could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, and so forth. Supporting Information The supporting information makes the BRD easier to use. It includes: Table of contents Index Appendices These may include use-case storyboards or user-interface prototypes. When appendices are included, the BRD should explicitly state whether or not the appendices are to be considered part of the requirements.

Page 27

Business Analysis Tutorial

12. Use Case Document

Version 1 2 Description Initial Draft (Each document will have the first row description of Initial Draft). 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 Author Writers name Date Completion Date (or publish data)

Note: Each time a document is delivered for review to anyone, the next version delivered should have a different version number. Reviewers would modify the name of the document by adding their initials to the name as delivered by the writer and should NOT change the version number. Only the document owner should change the version number. General Information Summary 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, PreAny activity that must have occurred for the first step to execute. e.g. User has successfully logged in to the system Conditions Trigger Brief description of event(s) required for execution of the use case. This is particularly relevant to Use Cases that address only system actions. E.g. if the use case defines the system actions to order and receive a credit report , there may 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 (New Role)

Page 28

Business Analysis Tutorial

Requirements List 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 example link or reference to the section of the use case where it is addressed. If it is determined that all or part of the requirement has been deferred or is no longer a requirement, highlight in yellow. Req # Req. Title Description Other Comment Gap Comment How Addressed

Use Case Steps In a use case, the possible actors are user and system only. If a user needs specific security to access the defined section of the system, that information should be listed as a Pre-condition above. Main Flow Step User Action Number 1 A user action may or may not be required. If no user action is required to begin a use case, this field should contain None. No field in this table should be left blank. If there is no relevant information required for a field, enter N/A or None

Step Number 2

(System) Reaction System reaction be sure to include any error messages that may result from a user action. If the next step has two possible paths, select one for the main flow and reference the alternate flow for the other(s)

Notes Include Comments/clari fications/ Links to any section or Illustrations None

Page 29

Business Analysis Tutorial

Exception # Name Each exception has a unique number and name. Name should give context of what is accomplished in the extension or why it is required. Step Number 1 User Action Each step in an alternate flow should have a unique number Step Number 2 (System) Reaction Point in Main Flow where this alternate flow initiates should be included at the beginning of this first step. Notes None

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 case should be named in the appropriate location in the use case table above as well as listed in this section.

Page 30

Business Analysis Tutorial

Data Elements This section references data elements discussed in the use case and any new fields being added to screens. Any new fields that are required must be listed in the table. Business Name The business name for the field, as referenced in the use case Description Business Description of the field Data Type / Length The Screen on which the field appears, and the Field Label. If the field appears on multiple screens, indicate the one most pertinent to the use case. Note: If the screen has not yet been developed, refer to the Activity and the proposed field label, which will be finalized during Design. Gap Analysis Requirements that have been deferred List all requirements that are in the functional specification group that have been deferred. If no requirements have been deferred, enter None New Requirements Comments / Values Any additional requirements. For a New field, include valid values if known. Validation Rules Example: Not Null (This filed should not be left blank)

Page 31

Business Analysis Tutorial

List all requirements that have been added due to gaps in the requirements matrix. If there are no new requirements, enter None. Assumptions and Dependencies List 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: For Client - Technology

_________________________ Name / Date For Client Business User

Page 32

Business Analysis Tutorial

13.Test Case Document

Test Case Identifier: Heading to the TEST Borrower Name: CASE (It can be the TC Co Borrower Name: Number and Name) Loan Number (last three numbers)

System Name: Prepared By: Tested By: Retested By: Date: Date: Date:

Test Description: Test Prerequisites: Comments: Scenario # & Name:

Please enter a description for the Test Case Pre-Conditions for this Test Case Enter Comments If any

Page 33

Business Analysis Tutorial

Step Number

Detailed Execution Procedures

Expected Results

Actual Result (Enter any error messages)

Status (Pass/Fail)

Enter the execution steps (this will be similar to the steps under user action in the Use Case)

Enter what is expected out of the system in response to the previous action (this is similar to the steps under System reaction in the Use Case)

This is to be entered by the tester on execution of the test case

This is to be entered by the tester on execution of the test case

Scenario # & Name: (There can be multiple scenarios / flows within a test case All these scenarios should be documented as separate flows) Step Detailed Execution Procedures Expected Results Actual Result Status Number (Enter any error messages) (Pass/Fail)

Page 34

Business Analysis Tutorial

14.Frequently Asked Questions

FAQ 1: What are your main responsibilities as Business analyst? What exactly the business analysts do? What is the expertise of the Business analyst? As a business analyst you have to have extensive experience in "Understanding the Business Process, Defining Scope of the Project and Understanding User Requirements and BUSINESS RULES and articulate them in to User and Functional Requirement Specification. (It is most important skill because a single missed or miss communicated requirement may cost hours of software development effort 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 Analyst also interact with System Analyst, Developers, Management, Deployment and Support Staff and other Stake Holders and facilitate Communication between the Client and IT department thus developing excellent co-ordination, negotiation and interpersonal skills. Business Analyst also has the skills to work as a User\Customer Advocate and skills to negotiate with user as well as with developers and management staff to resolve any requirement conflict. Setup a change requirement management system to track changing requirements of the projects. Business Analyst is actively involved in gathering & converting User Requirements into business requirements and functional specification, create use case diagrams, business flow diagrams, Activity/State Diagram and Sequence diagram so the developers and other stake holders can understand the business process according to their perspective with possible alternate scenarios. Business Analyst should have the skills to understand the business rules and effectively implementing them in to Business 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 with designers, developers and stakeholders, Responsibilities also include doing feasibility study, adaptability study and risk analysis to identify the business critical or high-risk areas of business application from USER perspective.

Page 35

Business Analysis Tutorial

Business Analysts can also convey to the User or Client If requirements are not feasible 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 the stakeholders and also suggest work around. Business Analyst woks as a liaison between user and technical staff to resolve any conflicts; A Business Analyst is a creative problem finder and a person who resolves conflicts with excellent interpersonal and communication skill. Though a Business Analyst 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

Business Analysis Tutorial

FAQ 2: Briefly summarize a Business Analyst work experience. An experienced Business Analyst (BA) should have extensive experience in the field of 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 include actively 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 interact with the following: 1. Senior Management 2. Project Managers 3. Key Stake holders 4. Subject Mater Experts 5. System Engineers 6. System Architects 7. Designers 8. Developers FAQ 4: What is the Pre requisite for a Business Analyst? A good Business Analyst must poses the following 1. Excellent Communication 2. People Skills 3. Strong knowledge of the Business 4. Pay Attention to Detail 5. Document writing skills 6. Professional Approach 7. Organization Skills 8. Very good Team player 9. Patience 10. Perseverance

Page 37

Business Analysis Tutorial

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 and collaborative 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 being modeled. 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 not only have one plan of the skyscraper you need to have multiple plans. The electrician 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 need different views of what theyre trying to build. And thats what were doing with software. That different view is what we mean when we talk about the logical view, the use case view, the component view, and the deployment view all the different views of the application under construction. Business modeling helps simplify and visualize the business process. FAQ 6: Define UML? The UML is the standard language for specifying, visualizing, constructing, and documenting all the artifacts of a software system. FAQ 7: What do you think is the primary use of activity diagrams and how do you represent them? What is the purpose? Primary use of activity diagram is to show Business Work Flow considering activity state and action completed Activity Diagrams are used mostly to show where each use case in an activity or how things flow between Use Cases Activity diagram can be used to relate each use case with the set of activity, so technical team can understand that the different set of users who perform different

Page 38

Business Analysis Tutorial

activities with varying set of privileges to access the system and doing the specific activity. 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 ACTOR Before 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 Case A use case is a technique used to capture the functional requirements of a system. Use cases describe the interaction between a primary actorthe initiator of the interaction and the system itself, represented as a sequence of simple steps. Actors are something 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 achieve some goal: they may be end users, other systems, or hardware devices. Each use case is 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 the Business Work Flow considering activity state and action completed. Activity Diagrams illustrate how things flow between Use Cases Activity diagram is used to relate each use case with the set of activity, so technical team can understand that the different set of users doing different activity with varying set of privileges to access the system. Since we have diverse set of users this was very helpful tool FAQ 11: How can sequence diagrams help in the business understanding? Sequence diagram shows Objects interaction arranged in Time Sequence. It is a great tool for deriving requirements, and hence used during the process of requirements gathering. Sequence diagrams give thee process flow in the system in sequence of time. This helps the Systems Analysts, Developers and Testers understand simple to complex scenarios in a better way, avoiding ambiguity of representation

Page 39

Business Analysis Tutorial

FAQ 12: We have diverse teams of user and group of researchers, how would one approach 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 to identify 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 much as information. This might be an iterative process. Set up meeting with different users. Conduct interviews or record the session 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 be maintaining to fully understand what exactly they are looking from the application. Request each set of users to review the requirements and Sign-off the documents, 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 graphic designer 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 exactly the application will look like and also take the feed back from them. Also create templates for the user to submit any changes so they can effectively request the change.

Page 40