Download
1 / 32
320 likes | 326 Views
Delve into business analysis processes, requirements planning, enterprise architecture, and communication strategies. Explore essential methods for requirements elicitation, analysis, and effective documentation. Understand the critical role of enterprise analysis in aligning technology with business needs.
E N D
Business Analysis & Data DesignITEC-630 Fall 2008 Business Analysis, Requirements & Business Process Modeling Prof. J. Alberto Espinosa
Objectives • Describe the body of knowledge of business analysis • Describe the requirements process • Introduction to business process modeling
What is business analysis? “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.” Source: International Institute of Business Analysis (iiBA)
Business AnalysisBody of Knowledge (BoK) • See iiBA: http://download.theiiba.org/default.asp?fileid=26&categoryid=3 • Enterprise analysis • Requirements planning and management • Requirements elicitation • Requirements analysis • Communication and documentation • Solution assessment and validation
Enterprise Analysis • Enterprise architecture: • “The explicit description and documentation of the current and desired relationships among business and management processes and information technology.” – U.S. Office of Management and Budget, Circular A-130 • “The blueprint for creating enterprise-wide systems in alignment with business needs” • It involves preparing all diagram, models and descriptions of: all business processes, functions, information and technology infrastructure • It often involves analyzing the current architecture, conducting gap analysis and developing a target architecture along with a transition plan • The business analyst needs to understand the enterprise strategies, which provides “the context” in which enterprise analysis is conducted • In modern, complex, dynamic and fast-paced business environments, the enterprise strategy and information technology are tightly aligned, but the strategy evolves rapidly, presenting substantial challenges for business analysts. • In large complex organizations, senior business analysts are key participants in the strategic planning process.
Requirements Planning and Management It involves: • Identifying team roles: project manager, business analysts, developers, quality assurance analysts, trainers, application architects, data modeler, database analyst, infrastructure analyst, information architect, subject matter (functional) experts, etc. • Identifying stakeholders (who will provide requirements information): executive sponsor, solution owner (client), end users, functional managers, investors, etc. • Distribute responsibilities amongst business analysts and other team members and define coordination, team communication and knowledge sharing mechanisms and processes • Define risk monitoring and management approach for each identified risk • Define the requirements and system development method (e.g., traditional, object oriented, unified modeling language—UML, etc.) • Define the requirements and system development process (e.g., system development life cycle, iterative, unified process—UP) • Manage requirements change and scope: requirements creep is a big problem • Define and collect project metrics and reporting mechanisms • Other project planning and project management activities
Requirements Elicitation A “key” BA task – it provides the foundation for solutions to business needs – it helps develop a thorough understanding of the business process that will be automated and the essential needs of the system. It involves: • Eliciting the these essential needs from stakeholders – dependent on the knowledge and willingness of stakeholders to share information • “Trawl” for knowledge: business processes, baseline system, target system • Methods: interviews, surveys, focus groups, requirements workshops, observations, prototyping, written documents, etc. • Analyze all interfaces – human and external systems • Document (i.e., record) all requirements identified (and the source) – requirements notes, cards, etc. • Establish priorities and verification (measurement) parameters • Beware of “scope creep”
Requirements Analysis “The objective is to define and describe 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” (iiBA) It involves: • Developing analysis models and artifacts • Can be textual or diagrams – beware of over-diagramming • And “transitional artifacts” that connect the multiple models – e.g. CRUD and other matrices • Methods: business process analysis, object-oriented (OO) analysis, structured analysis • Requirements: functional, non-functional, project, assumptions, constraints, etc.
Communication and Documentation The objective is to develop an accurate understanding of the business problem and clearly articulate the solution. It involves: • Communication skills are critical – two ways: not only clearly articulating things verbally and in writing, but also listening effectively • Selecting the appropriate models, artifacts and other requirements documents formats. • Describing models and text artifacts clearly, accurately and concisely • Key deliverable: “requirements specification” representing the BA’s “demonstrated understanding” of the business and processes that need to be handled by the system and its necessary capabilities. • These specs will serve as the foundation for: effort estimation, budgeting, resource allocation, contractual terms, and implementation planning, etc. • Preparing effective presentations for clients and stakeholders.
Solution Assessment & Validation Two key aspects: (1) evaluation if the proposed solution meets business needs (and the architecture analysis) and (2) if the solution was implemented correctly (per requirements) Evaluate proposed solution, it involves: • Requirements reviews to evaluate if they are accurate, complete, clear, non-redundant, consistent (with architecture and business needs), feasible, correctly prioritized, etc. • Obtaining signoff from clients and stakeholders – helps buy in and reduce “feature churn” Evaluate correct implementation, it involves: • Working with Quality Assurance teams • Mapping analysis artifacts to design artifacts • Mapping implemented system features to requirements artifacts • Black box testing of the system implemented – e.g., using test cases • Evaluating non-functional requirements and technologies used • Evaluating usability and interfaces (human and system)
Requirements • In simple terms, requirements are things the product needs to do (i.e., useful functionality for its user) and the capabilities and qualities that it must have (i.e., non-functional) • IEEE definition: • A condition or capability needed by a user to solve a problem or achieve an objective • 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 • A documented representation of a condition or capability as in (1) or (2)
Requirements Analysis Find, understand, record and communicate: • Functional Requirements (behavioral) • What the system needs to do: “The work” • Your articulation of functional requirements becomes is your “demonstrated understanding” of the business processes your system needs to automate – Eric Bristow, Deloitte Consulting • Non-functional Requirements (non-behavioral) – the qualities of the system (e.g., speed, reliability, capacity) • Project Requirements– costs, deliverables, deadlines, etc. • Prepared using a “System Requirements Process” • Articulated in a “System RequirementsSpecification”
Requirements Analysis isKey to Successful Development • Several studies have documented that requirements errors cost the most and that poor requirements are the main cause of software failure GAO’92; Faulk’92; Bohem’81; Curtis’88 “The hardest single part of building a software system is deciding what to build. ...No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”Fred Brooks (1987)No Silver Bullet: Essence and Accidents of SW Engineering
Sources of Requirements • Users, Customers, other Stakeholders (e.g., employees, management, selected customers) • Standards (e.g., GAAP) • Policy/Legal (e.g. government regulations) • System Documentation (e.g. current system being replaced, could be manual) • Business Process Documentation (e.g. current business memos, manuals, practices) • Subject Matter Experts(e.g. experts on the business domain)
Role That Good Requirements Play • For clients: requirements describe what will be developed and perhaps provide a contractual basis for the development • For project manager: provide a basis for project planning and measuring progress • For the developers: provide the functionality to be designed and coded • For testers: provide the basis on which test • For users: documentation and training
Capturing Requirementsis Difficult Need to: • Find out what is required by/from the system • Understand these requirements and their implications • Communicate (text and models) this understanding to users, customers, designers and other stakeholders • Manage them – i.e., record them in a traceable manner and ensure that as requirements change, they are updated and the impact of the change is understood • Quality and fit – i.e., ensure that system meets the requirements
“Trawling” for Knowledge: Eliciting Requirements • “Running a net through the organization to catch every possible requirement source” (Robertson & Robertson) • With experience, you learn where to fish to find what you want • Start with documents from the project “blastoff” meeting with your client • Elicit further requirements through: interviews, requirements workshops, questionnaires, observations, job protocol analysis, prototyping, review of existing documents • Systematically “catch” and record all requirements • Document anything that sounds like a requirement using an organized form or template like: the Volere Requirement Shell
Interviews • Interviews should be carefully planned • Interview Process model • Determine who to be interviewed • Prepare for, plan & schedule each interview • Open the interview: introduction, purpose, permissions (to tape, etc.) • Conduct the interview: semi-structured, open ended questions, mail questions in advance, let users digress, don’t agree or disagree on anything (just capture) • Close the interview: summarize things, confirm facts • Follow up: resolve conflicts; close-ended questions
Requirements Workshops • Approx 2 days before each UP iteration • Multiple stakeholders participate: multiple perspectives of the system • It fosters clear communications between Requirement Analysts, users and other stakeholders • Fosters sense of participation and project ownership • Helps accelerate requirements elicitation process • Facilitators are often used • Need a scribe to document the discussion • Need rules for participation and problem resolution • Need a process that fosters preparation • Pre-specify expected deliverables • Use artifacts that foster communication with the client:A Business Process Model(or Map) is an excellent tool for this
Business Process Model • The system you are gathering requirements for will automate one or more business processes • Therefore, it is very important that the requirements analysts and clients develop common ground on what these business processes are • The best way to achieve this is to develop a business process model and get the client to sign off on it • The idea is to develop a vision of “the work” that needs to be done, looking ONLY at the business aspects of the process • A business process model (BPM) fosters communication between the requirements team and the client; and within the team • It provides an excellent starting base to begin to articulate the system requirements
Some BPM Diagramming Rules • All BPM diagrams have one start and one end symbols. • If there are two or more distinct sub-processes, it is OK to break up the BPM into two sub-models, but each must have a start and end symbols. • If you have many sub-processes you can create one master BPM that includes “Pre-Defined Process” symbols and then create a separate BPMs for each of these pre-defined sub-processes. • You can include many symbols in the diagram to add clarity to your process descriptions. Some symbols just add clarity (e.g., comment, database store, printout), whereas others have very specific rules on how to use them. • More BPM guidelines: http://www.edrawsoft.com/flowchart-symbols.php
Some BPM Guidelines • BPMs are used to document business processes, NOTsystems actions – focus on understanding and documenting what people do and what the key processes are, rather than what the system solution will do. • That is, you need to understand the business processes before you can suggest a solution. • However, it often helps to distinguish the baseline BPM (what the client does) from the target BPM (what the client wants). You can add notations and other symbols to distinguish baseline from target processes • Similarly, it sometimes helps to distinguish processes that are carried out manually from those that are handled by applications. So, you can also add notations and other symbols to distinguish manual from system driven processes • More importantly, this is NOT hard science – if you can do anything to add descriptive clarity to your BPM, by all means
Some Rules for BPM Symbols • Process Step (box): can have more thanone input but only have one output; if you think you need two outputs you probably need a decision symbol that evaluates which output path to follow; the input and output lines must connect to another symbol (process box, decision, start, end, etc.); NEVER leave process steps alone—they must have input(s) and output. • Pre-Defined Process(box with double vertical borders): use this symbol to indicate complex process steps that need to be further explained in more detail—it is not a bad idea to put a page reference next to these symbols that connect the diagram to BPM that diagrams the sub-process • Decision(diamond): have one input and at least two possible outcomes; it may have more than two outcomes but this may point to more complex process steps that are better described in a “pre-defined process”; all outcomes must be labeled (e.g., “yes”, “no”, “option 1”)—NEVER leave decision outcomes unlabeled • Functional bands or swim lanes: show which functions, departments or roles are associated with a symbol; when flowcharts have functional bands the diagram becomes a “cross-functional flowchart” • Page connector: use this symbol when your diagram spans more than one page; ALWAYS label the symbol with a page number that matches the actual page where the related diagram is • You can add other symbols to add clarity (e.g., database, printout, etc.); Label these symbols as needed for clarity
Master BPM ExampleEach Pre-Defined Sub-Process Box Has its Own BPM Diagram
The Requirements SpecificationRobertson & Robertson’s “Volere Template” • Project Drivers: purpose, stakeholders, actors • Project Constraints: constraints, glossary, assumptions • Functional Requirements: use cases, class diagrams • Non-functional Requirements: “ilities” & other qualities • Project Issues: off-the-shelf, costs, risks, etc.Template for this course’s project: an adaptation of the Volere Template
