Business Analysis [1 ed.] 9789350432587, 9788184885064

Citation preview

BUSINESS ANALYSIS Amit Johri Director,

esc

Baroda

I.

First Edition: 2010

Hat GJIimalaya GpublishingGJIouse IIII11Al • NEW DELHI • NAGPUR • BENGALURU • HYDERABAD • CHENNAI • PUNE • LUCKNOW' AHJ(DABAD • ERNAlULAIi • BHUBANESWAR • INDORE

©

Author No part of this publication should be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording and/or otherwise without the prior written permission of the author and the publisher.

ISBN

: 978-81-84885-06-4

First Edition: 2010

Published by

Mrs. Meena Pandey for Himalaya Publishing House Pvt. Ltd., ·Ramdoot", Dr. Bhalerao Marg, Girgaon, Mumbai - 400 004. Phone: 2386 01 70/23863863, Fax: 022-2387 71 78 Email: [email protected] Website: www.himpub.com

Branch Offices: New Deihl

Nagpur

Bengaluru

Hyderabad

·Pooja Apartments", 4-B, Murari Lal Street, Ansari Road, Oarya Ganj, New Delhi -110 002. Phone:23270392, 23278631 Fax: 011-23256286 Kundanlal Chandak Industrial Estate, Ghat Road, Nagpur - 440018. Phone: 2738731, 3296733 Telefax: 0712-2721215 No. 16/1 (Old 12/1), 1st Floor, Next to Hotel Highlands, Madhava Nagar, Race Course Road, Bengaluru - 560 001. Phone: 22281541, 22385461, Telefax: 080-22286611 No. 3-4-184, Lingampally, Besides Raghavendra Swamy Matham,Kachiguda, Hyderabad - 500027. Phone: 040-27560041, 27550139. Mobile:- 09848130433

Chennai

No. 85/50, Bazullah Road, T. Nagar, Chennal - 600 017. Phone: 044-28144004/28144005

Pune

First Floor. "Laksha" Apartment. No. 527, Mehunpura. Shaniwarpeth (Near Prabhat Theatre). Pune - 411 030. Phone: 020-24496323/24496333

Lucknow

C-43, Sector - C, Ali Gunj, Lucknow - 226 024. Phone: 0522-2339329 114, ·SHAIL", 1st Floor, Opp. Madhu Sudan House, C.G.Road, Navrang Pura, Ahmedabad- 380 009. Phone: 079-26560126, Mobiles:- 09327324149.09314679413 39/104 A, Lakshmi Apartment, Karikkamuri Cross Rd., Ernakulam, Cochin - 622011, Kerala. Phone: 0484-2378012, 2378016, Mob.: 09344199799 5 Station Square, Bhubaneswar (Orissa) - 751 001. Mobile:- 9861046007, E-mail:- [email protected]

Ahmedabad

Ernakulam

Bhubaneswar Indore

OTPby Printed by

Kesardeep Avenue Extension, 73, Narayan Bagh, Flat No. 302, IIlrd Floor, Near Humpty Dumpty School, Narayan Bagh, Indore 452 007(M.P.) Mobile:- 09301386468 HPH, Editorial Office, Bhandup (Rajani B.) Esquire Press, Mumbai.

CONTENTS

•••••••••••••••••••••••••••••••••••••••••••••• 1.

Business Analysis for Business Design

2.

Enterprise Analysis

3.

Requirements Planning and Management

100 - 186

4.

Requirements Elicitation

187 - 217

5.

Requirements Analysis and Documentation

218 - 335

6.

Requirements Communication

336 - 366

7.

Solution Assessment and Validation

367 - 384

8.

Software Development Techniques

385 - 423

9.

Software Project Management

424 - 431

Annexure

432 - 438

1 - 28 29 - 99

"This page is Intentionally Left Blank"

Chapter

Objectives:

After reading this chapter, you will be able to: 1. Explain why Business Analysis is so essential in Business Design today. 2. Acquaint yourself with the Business Analysis principles, practices and the Business Analyst Profession. 3. Identity the core areas where there are set professional standards for those performing Business Analysis - Enterprise Analysis, Requirements Planning and Management, Requirements Elicitation, Requirements Communication, Requirements Analysis and Documentation, Solution Assessment and validation. 4. Describe the rela.tionship of Business Analysis to the solutions Life Cycle. 5. Understand the Business Analysis Life Cycle with its stages Analyse Business Needs, Define Business Solution, Test Business Solution. Structure:

1.1 Introduction 1.2 Business Analysis - The Profession 1.3 Defining Business Analysis Profession

CHAPTER-1

Business Analysis

1.4 The Business Analysis Principles in Context 1.5 Business Analyst 1.6 CASE: Soccer Stadium Season Tickets Resale System 1.7 CASE: Mobile Telecom Business Analysis 1.8 Business Analysis Life Cycle 1.9 Summary 1.10 Self Assessment Questions

1.1 INTRODUCTION • Before the 19th century no one systematically studied the effectiveness of the different approaches of Management. • Business Analysis - is a very recent profession. Due to the radical change in Information Management and Communication businesses needed a new way of analysis - hence, the profession came into play. • The profession came into existence during the Information Technology boom in 1980-1990. • When businesses created a new profession to serve the process that a System Analyst does in IT - the profession become the Business Analyst. • Though, nothing can guarantee success, understanding the core concepts of the Business Analysis area will help you to work more effectively as a Business Analyst. • Six knowledge areas of Business Analysis are:

1. Enterprise analysis: The environment of the organization at large. 2. Requirements planning and Management: Defines the resources and tasks associated with the planning and management of requirements gathering activities throughout the requirements process. 3. Requirements Elicitation: Defines standard techniques used to collect the requirements. 4. Requirement Analysis and Documentation: Describes how stakeholder needs are analysed, structured and specified for use

2

Business Analysis for Business Design

in the design and implementation of a solution. Defines and describes the characteristics of an acceptable solution to a business problem, so that the project team has a clear understanding of how to design and implement it.

5. Requirements Communication: Collection of activities and considerations for expressing the output of the Requirements Analysis and Documentation to a broad and diverse audience. It includes presenting, communicating, verifying and gaining approval of the requirements from the stakeholders and implementors of the project. 6. Solution Assessment and Validation: Ensures that the solution meets the stakeholders' objectives, is thoroughly tested, and is implemented smoothly. • Responsibilities of a Business Analyst 1. Identify Business problems and opportunities. 2. Eliciting, Analysing, Communicating, and Validating requirements for changes to Business processes. 3. Recommending solution to help businesses achieve goals. • The role of the Project Managers and Business Analysts may seem similar. Really, there are some overlapping areas such as identifying goals and requirements, risk analysis and finding strategies for project success. However, the Project Manager is responsible for the timely completion of the project within the budget. The Business Analyst ensures that the project is completed correctly with the defined requirements. • Skills in Business Analysis

1. Knowledge Skills: Analysis knowledge, Business Knowledge, IT Knowledge skill sets. 2. Collaboration Skills: Interpersonal Skills Collaboration skill set, Diplomacy Collaboration skill set, Organizational Development collaboration skill set. 3. Leadership Skills: Mentoring leadership skill set, Forwardthinking leadership skill set, Elicitation and Analysis leadership skill set, Designation leadership skill set.

3

CHAPTER-1

Business Analysis

1.2 BUSINESS ANALYSIS - THE PROFESSION The Business Analyst is a key to company's success. The Business Analysis profession is growing and evolving constantly

The Business Analysis Principles and Practices is the sum of knowledge within the profession of Business Analysis and reflects what is considered current and accepted. The Principles and Practices of Business Analysis describe areas of knowledge, their associated activities and tasks and the skills necessary to be effective in their execution. The Primary purpose of this book is to identify Business Analysis principles that are generally recognized and accepted as good practice. The book provides a general overview of each principle and the list of activities and tasks associated with each. This book provides a basic reference for anyone interested in the profession of Business Analysis. This includes, but is not limited to: • Senior Executives. • Managers of Business Analysis Professionals. • Business Analysis Professionals. • Project Managers. • Educators and Trainers teaching Business AnalYSis and related topics. • Consultants and other specialists in Business Analysis. • Students of Business Analysis

1.3 DEFINING BUSINESS ANALYSIS PROFESSION Business Analysts make important contributions to organizations every day.

Business Analysis is the set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change. Those performing business analysis are today known by a number of titles such as business analyst, business systems analyst, systems analyst and others. 4

Business Analysis for Business Design

Business analysis is distinct from financial analysis, project management, quality assurance, organizational development, testing, training and documentation development. However, depending on an organization, an individual Business Analyst may perform some or all of these related functions.

Core Concepts of Business Analysis This section covers the knowledge needed to make effective use of the material in the knowledge areas. Typically, this knowledge is required across all the knowledge areas.

Definition of the Business Analyst Role A business analyst works as a liaison among stakeholders in order to elicit, analyse, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

Definition of a Requirement A requirement is: (1) A condition or capability needed by a stakeholder to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2). Requirements serve as the foundation of systems or system components. A requirement can be thought of as something that is demanded or obligatory; a property that is essential for the system to perform its functions. Requirements vary in intent and in kinds of properties. They can be functions, constraints, or other elements that must be present to meet the needs of the intended stakeholders. Requirements can be ·described as a condition or capability a customer needs to solve a problem or achieve an objective. For clarification purposes, a descriptor should always precede requirements; for example, business requirements, user requirements, functional requirements.

5

CHAPTER-1

Business Analysis

Definition of Requirements Types The types of requirements that exist vary based on the problem domain and methodology that the Business Analyst works with. The following types of standard requirements types have been defined:

• Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. They describe such things as the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success. They are detailed further in the Enterprise Analysis chapter. • User Requirements are statements of the..needs of a particular stakeholder or class of stakeholders. They describe the needs that a. given stakeholder has and how that stakeholder will interact with a solution. User Requirements serve as a bridge between Business Requirements and the various classes of solution requirements. They are gathered from stakeholders as described in the Requirements Elicitation chapter and documented using the techniques described in the Requirements Analysis and Documentatiol1 chapter.

• Functional Requirements describe the behaviQur and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviours or operations - a specific system action or response. They are further described in the Requirements Analysis and Documentation chapter. • Quality of Service Requirements capture conditions that do not directly relate to the behaviour or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as non-functional or supplementary requirements. They are further described in the Requirements Analysis and Documentation chapter. • Assumptions and constraints identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution. They are further described in the Requirements Analysis and Documentation chapter. • Implementation requirements describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete. They are further described in the Solution Assessment and Validation chapter. 6

Business Analysis for Business Design

Effective Requirements Practices Through practical experience and study of system and software engineering practices, it is clear that the use of effective requirements definition and management practices leads to successful projects, satisfied customers and increased professionalism in the industry. Benefits include: • A clear understanding of the needs of users, customers and stakeholders. • A collaborative relationship between the users, customers and stakeholders and the technical team. • A strong commitment of the requirements development team members to project objectives. • Use of a repeatable requirements process that is continuously improved. • A system architecture that supports the users, customers and stakeholders current and planned needs. • The ability to accommodate changes in requirements as they are progressively elaborated. • High quality systems and products. • System development cost savings, accurate schedules, customer satisfaction.

Business Analysis in Summary There are six areas defined, that combined, cover the core areas where there are set professional standards for those performing business analysis: • Enterprise Analysis. • Requirements Planning and Management. • Requirements Elicitation. • Requirements Communication. • Requirements Analysis and Documentation. • Solution Assessment and Validation. Basic Skills - Analysis skills, Business/Domain Knowledge, IT ,Knowledge, Advanced Skills-Meeting Management, Presentation Skills, Decision-making Skills ...... Leadership Skills, Peripheral Skills round out the knowledge requirements for Business Analysts.

7

CHAPTER-1

Business Analysis

Enterprise Analysis

This area is the collection of pre-project or early project activities and approaches for capturing the necessary view of the business to provide context to requirements and functional design work for a given initiative and/ or for long-term planning. In some organizations this work is treated as an investigative, feasibility or business architecture initiative and treated as a project in itself. It is important for those in the Business Analysis profession to understand the organizational environment in which they are working. They should understand how the project, and their work in it, supports the entire enterprise. Typical Enterprise Analysis activities leading up to project selection guided by the Business Analyst include those listed below. While these activities appear to be sequential, they are often conducted concurrently and iteratively. • Creating and maintaining the Business Architecture. • Conducting feasibility studies to determine the optimum business solution. • Identifying new business opportunities • . Scoping and defining the new business opportunity • Preparing the Business Case • Conducting the initial Risk Assessment • Preparing the Decision Package. Enterprise Analysis is covered in Chapter 2. Requirements Planning and Management

The Requirements Planning and Management area defines the resources and tasks associated with the planning and management of requirements gathering activities throughout the requirements process. The Business Analyst must define the requirements activities that will be performed and how those activities will be performed on a project, in accordance with any existing standards in the organization. It includes identifying key roles, selecting requirements activities, managing the requirements scope and ongoing communication of the requirements gathering status. Proper planning and management of requirements gathering activities ensures the success of the requirements process and requirements deliverables. 8

Business Analysis for Business Design

Before initiating requirements activities and during the requirements process it is important to consider how the Business Analysis team is going about the requirements activities on a project. This is necessary to ensure: • the set of requirements activities undertaken are the most appropriate, given the unique circumstances of the project, • the requirements work effort is coordinated with the other work being done for the project, • the whole requirements team on a project has a common understanding of what activities they are undertaking, • business analysts are able to monitor and react to requirements challenges and slippage, • the tools, resources and requirements contributors are available as n~eded for the requirements activities, • and, changes are captured correctly and consistently. Requirements Planning and Management is covered in Chapter 3. Requirements Elicitation

EliCiting requirements is a key task in business analysis. Because the requirements serve as the foundation for the solution to the business needs it is essential that the requirements be complete, clear, correct and consistent. Leveraging proven means to elicit requirements will help meet these quality goals. The Requirements Elicitation area defines standard techniques used to collect the requirements of the system. This activity is also known in the industry as "eliciting" requirements. The system in question may be a business system, an automated system or both. The scope of the elicitation work may be a new system or an enhancement to an existing system. The business analysis professional selects the appropriate mean(s) to gather the needed requirements based on the applicability of a technique'S process, key features and strengths and weaknesses. Requirements Elicitation is covered in Chapter 4. Requirements Analysis and Documentation

This area describes how stakeholder needs are analysed, structured and specified for use in the design and implementation of a solution. The objective is to define and describe the characteristics of an acceptable solution to a

9

CHAPTER-1

Business Analysis

business problem, so that the project team has a clear understanding of how to design and implement it. Requirements analysis defines the methods, tools and techniques used to structure the raw data collected during Requirements Elicitation, identify gaps in the information and define the capabilities of the solution, which must be documented. Deliverables from this process will be used by the project team to develop estimates for the time, resources, and budget required to implement a solution or solutions that will fulfill the requirements. The documentation itself is only one of several techniques the Business Analyst will use to ensure that a consensus between all the stakeholders exists as to the behaviour of the solution. The primary focus of documentation activity is to refine the models based upon stakeholder feedback and iteratively ensure feasibility of the proposed requirements to support the business and user needs, goals and objectives. Requirements Analysis and Documentation is covered in Chapter 5.

Requirements Communication The Requirements Communication area is the collection of activities and considerations for expressing the output of the requirements analysis and documentation to a broad and diverse audience. Requirements communication is an ongoing, iterative activity that is done in parallel with Requirements Gathering and Requirements Analysis and Documentation. It includes presenting, communicating, verifying, and gaining approval of the requirements from the stakeholders and implementers of the project. An effective business analyst must be able to clearly present the requirements in a format and structure that is appropriate for its intended audience. Business Analysts must understand the options and select the appropriate communication formats for their project. Business Analysts must consider when and where communications need to take place, what communication approach is appropriate for each situation, and how each communication should be presented. Requirements must be "packaged," reviewed, and approved before the solution is implemented. Requirements Communication is covered in Chapter 6.

Solution Assessment and Validation This area covers the business analysis tasks necessary to ensure that the solution meets the stakeholder objectives, is thoroughly tested, and is implemented smoothly. 10

Business Analysis for Business Design

Once a solution design has been agreed upon. the Business Analyst assists the technology team with detailed design work including splitting a large project into phases. reviewing technical design deliverables, and helping to build usability into the application software. In the case of a purchased solution, they will assist with any package customization decisions that need to be made and with interface requirements. As the solution is built and available for testing, the Business Analyst role involves supporting the Quality Assurance activities. They may help business stakeholders with user acceptance testing, defect reporting and resolution. The Business Analyst is accountable for ensuring that the solution developed meets the defined needs and should assess project success after implementation. Solution Assessment and Validation is covered in Chapter 7. Chapter 8 details the various Software Development Techniques and Chapter 9 details Software Project Management, essential for a Business Analyst's work. Annexure 1. titled BA Fundamentals defines the collection of general competencies, skills, techniques and knowledge needed to effectively perform business analysis. Annexure 2. titled Glossary Contains details of Terms in each area.

1.4 THE BUSINESS ANALYSIS PRINCIPLES IN CONTEXT The BA principles define the activities, tasks and knowledge that a business analysis professional needs to know, it does not do so from the perspective of prescribing an order or sequence. Specifically, the areas do not define a business analysis methodology. They do define what t:,e BA needs to know to work within any analysis process or overall solutions development methodology. By looking at the following picture, however, we understand the relationships between the areas and the broader world that business analysis fits into.

11

CHAPTER-1

Business Analysis

Requirements Planning and Management

Solution Assessment and Validation

Requirements Communication

Underlying Concepts SA Fundamentals Glossary

The picture highlights a number of important points 1. The SA fundamentals and glossary are not activity or task driven. They outline the base knowledge needed for a business analysis professional to be successful. 2. Not all work that a business analysis professional does is for a defined project. It is not unusual for Enterprise Analysis activities to be considered either pre-project work or an early feasibility phase of a project, with the outputs of that analysis becoming input into the requirements planning for a project as well as the high-level requirements goals for further requirements Elicitation. 3. Requirements Planning and Management activities tend to span the duration of a project with planning input provided to each of the other areas and output provided back that allows for the requirements management activities and re-planning work to be done.

12

Business Analysis for Business Design

4. Communicating about requirements also tends to span the duration of a project with output from each other knowledge being those things that need to be communicated and results of the communication feeding back into the necessary area. 5. Theoretically, one gathers requirements then analyses and documents them, then uses them as input into the designs that lead to the final implementation of the gathered and documented requirements. In most situations, however, the business analysis professional faces significant concurrence and overlapping of these activities. It is normal to have requirements elicitation and requirements analysis and documentation work going on concurrently. It is also not unusual to have work being done on alterative solutions and technology options concurrently with elicitation and analysis work. It is not advisable to start Solution Assessment and Validation too early though, in order to avoid too early a focus on the solution without having a solid understanding of the need. 6. Information gathered during requirements elicitation or requirements analysis may lead to further work or refinement of the project feasibility. Also true, though not desirable is that work done during the implementation of the requirements also causes review and revision of project feasibility. Several methodologies are designed to reduce the risk of feasibility or requirements discovery during implementation work.

Relationship to The Solutions Life Cycle An individual Business Analyst must work with the project team and other stakeholders to determine which tasks and techniques defined for the Business Analysis are appropriate for their organization and for a given project. Different projects and methodologies may demand that requirements be produced in specific formats and in varying levels of detail. The Business Analysis principles will be compatible with small to large, simple to complex projects and all types of methodologies (e.g., iterative, agile, waterfall). This section shows how the Business Analysis areas relate to typical solutions and systems development life cycles and the project life cycle.

13

CHAPTER-1

Business Analysis

The Solutions Life Cycle Business Analyst

Business Analyst Enterprise Architect

IBusiness

Stakeholders

I

I Business

L-_E_n_d_U_se_r_s_....1

Stakeholders

I I Stakehold

End Users

I

Solutions Architect Project Manager Developers Information Architect

Inf. Architect Operations

Fig.1.1: General Timeline of stages and resources for a solution from strategic conception to final valuation Note: This is a non-proportional ordering of events in the timeline. The Figure reflects the current state of solutions today and is not optimal. The solutions architect, along with every other role in the solution, must adapt and exist in the imperfect world of solution delivery. This can be used to identify and communicate existing shortfalls to make better roles interaction a common goal. Key Point: Individuals in a solution often perceive their roles as crossing the boundaries. A solutions architect recognizes each of the roles and considers how best to work with the other participants throughout the solutions life cycle. Exercise: Consider a recent project that you were involved in. Draw a diagram that reflects the reality of the roles and timelines for your project. How does it differ from the Figure 1.1. 14

Business Analysis for Business Design

1.5 BUSINESS ANALYST A business analyst is generally a business domain expert who is well - versed in business processes to help business stakeholders identify and define the strategy behind the total solution. Business analysts may be experts in six sigma, lean manufacturing, the Capabilities Maturity Model Integration (CMMI), or other operational methodologies. They are generally technology aware but focus more on the business aspects in problem solving and resolution. These individuals may be internal or external to the organization.

Questions every Business Analyst should ask It does not matter what project you are going to undertake. It is not important what industry you are going to be assessing. What is important is you know what you are going to do. You must ask questions, you must find what it is the client wants. Presented is a list of obvious questions every good Business Analyst should know the answer to when starting a project. 1. What problem is this Business having that you hope to solve by developing this project? 2. What is the Business doing at present to alleviate or solve the issue? What has been tried in the past? 3. What inside resources will this project be utilizing? What outside resources will be necessary? 4. Have you determined a VISION for the project? 5. What risks do you foresee and are you willing to take them? 6. Are you under any type of time constraint? 7. What is the projected cost of the programme? What is the projected budget and can it be deviated from? 8. Who is the end-user? What Support will they have?

Key Point A business analyst will assist and direct the business stakeholder's vision and direction into actionable business plan. The solutions architect will engage strategy skills when working with the business analyst to effectively design and apply appropriate technology around the actionable business plan, and to make certain that the solution is technically achievable within the required time frame.

15

CHAPTER-1

Business Analysis

Exercise The business analyst often represents the "Voice of the customer". Many of the critical decisions of a solution architect require an understanding of the customer's needs. What can you do to make certain that you are obtaining the correct information that is the basis for your architectural decisions?

1.6 CASE: SOCCER STADIUM SEASON TICKETS RESALE SYSTEM A European Soccer team's ownership and executive management has been mining their extensive data around home game attendance and profits. From their research, they realized that on average, 20 per cent of their season ticket holder seats were unused at any particular home game.

Executive Management Viewpoint Season tickets are paid for at the beginning of the season, so there is no sales revenue loss if a season ticket holder does not attend. However, they also realized that every filled seat generates, on average • 25 in concessions and novelty sales. If they could fill the empty season ticket holder seats, they could create additional revenue from parking, concessions and licensing sales. They have developed a strategy where they will allow season ticket holders to resell tickets for games they cannot attend. Gaming regulators will allow the resale to occur only at face value of the ticket, no more, no less, and no service charges. The team's owners would like to create a greater fan sense of community around this opportunity where team members will share personal anecdotal stories with fans to encourage non-season ticket holders to sense the prestige of being a season ticket holder for a day. They want to create this sense of community by having season ticket holder register their tickets for resale (having the revenue credited to their account) and allowing fans to select and purchase available season tickets. Additionally, they want approved external ticket sales organizations and agencies to also broker available season tickets by allowing them to securely query into their systems to view available tickets and to make purchases on behalf of their patrons. The team's home schedule includes 12 regular games a season and their stadium seats 60,000 fans, 80 per cent (48,000 seats) of which are season tickets. On average, 20 per cent (9,600 seats) of the season ticket seats are empty losing € 240,000 in concessions revenue per game, or 16

Business Analysis for Business Design

approximately· 2.9 M each season. However, they do not expect to fill every vacant season ticket seat, so actual revenue recouped will be less.

Enterprise Architect and Business Analyst The enterprise architect for the team uses a slimmed down version of Zachman to get this system operational inside of the nine-months before the next season begins. The business analyst will work closely with the team's marketing department to promote a new programme where fans can become a "Season Ticket-Holder for a Day".

Solutions Architect Assignment Build a Business plan to implement the soccer stadium season tickets resale strategy integrating into existing systems where possible. The team has a web presence with a self-made ASP. NET portal. Two ticket agencies want to integrate with the idea of reselling unused season tickets for games. One is Java-based and the other is ASP (not ASP.NET) based. The systems that have been identified are,

Administrative The administrative system must allow season ticket holders to post individual tickets for games they do not plan to attend. This must supply the means to: • Register the tickets as available for resale. • After the tickets are sold, credit the season ticket holder's account • Nullify season ticket holder's ticket after those tickets are sold and new tickets are printed. • Allow season ticket holders to view their account activity and either cash in their account or apply it toward next year's purchase.

Community The community system must have an environment where fans can be made aware of season ticket resale opportunities. This includes providing the ability to: • Promote the idea, share experiences with season ticket resale . patrons; this can be facilitated through a blog-like interface. • See real time information about season tickets currently available, reserve the tickets, and purchase the tickets. The available seats should be displayed on a map of the stadium. 17

CHAPTER-1

Business Analysis

• Post requests to season ticket-holders for desired games for which fans are seeking tickets.

Integration The integration system must have an interface for secure external business to business access. This includes providing the ability to: • Keep track of the inventory of available season tickets available for resale. • Place a 2Q-minute hold on up to eight tickets being considered for purchase. • Purchase and reprint resold tickets • Perform electronic funds transfer (EFT) for appropriate accounts.

Cost Estimation and Justification What will this solution cost? Should it be built, purchased or both? Which methodologies and models would you use? What means will be used to justify the investment? What is the rationale you will give executive management that they should proceed and approve the funds you request?

1.7 MOBILE TELECOM BUSINESS ANALYSIS Business Challenges The main business challenge was to achieve optimum mobile telecom efficiency in a relatively small market in the presence of strong competition. Finding the performance bottlenecks, checking the compatibility between legacy and new systems, analysing the feasibility of new solutions and services. Identifying areas of improvement of Customer Care and Billing process, optimizing overall costs, and providing more flexible services.

Solution: A profound analysis of the key front-end and back-end telecom systems took place. All major systems, including Dealer management, communication BUS, Multimediation, Provisioning, Billing, CRM, ERP, Invoice Printing, Network elements, Archiving Solution, IVR and many others, were inspected and had their performance and interactions analysed. The requirements of new value added services within the existing 3G network were analysed and documented. 18

Business Analysis for Business Design

The possibilities for integration of IMS platform were analysed. Call Data Record generation and management was reviewed and modified in order to improve efficiency and scalability. Hardware analysis of back-end system was performed in order to improve billing and reporting time. Benefits • Reduced operating costs • Minimized efforts for daily operations • Reduced manual operations, leading to increased security • Optimized efficiency of the internal business processes • These results made possible the launch of new value added and IMS Services.

1.8 BUSINESS ANALYSIS LIFE CYCLE Analyse Business Needs

Analyse Business Problems Model and Analyse Business Processes Gather prioritized requirements Model Business Data

Define Business Solution

Evaluate potential solutions Develop quick fixes Engineer business processes Design Business Architecture

Test Business Solution

Plan testing activities Engineer Test Data Execute Tests

19

Business Analysis

CHAPTER-1

, " ""

I

,"

BusinessL. . " "Expe rt ....... _...- - - "'- ...

,, . ......... ... . ........ ..... ..

\, . . ., ... . . . . . . .... .... ,

"

,

\ ' " \

Business Environment Expertise

,,

"

, \

Business Constrai nts

I I

\

"" "", ",,, Business ,

,,

\

I I I W

\

~

,

I

\,

t

I \

-

Prioritized, Validated Requirements

\

, ,

J

\ \

Technological Constraints

\

\ Technological Environment Expertise

,

\

I I

/

/

I

I

J //

Information Technology Expert

/

/

I

I

/ System Components

I

,

I

/

Problem Reports

\

J

System / Design / Specifications I

\ \ \ \ \ \

,

I

~

\

t

I

/

\

\

/

/

I

/

Fig.1.2 : The Business Analysis Life Cycle

20

, \

I

" tI

,_

\

System fI"'-......;: