Business Requirements Analysis ITEC-455 Spring 2010

Business Requirements Analysis ITEC-455 Spring 2010
Introduction, Requirements Analysis & Business Process Modeling Prof. J. Alberto Espinosa

My Background Started as New faculty at AU in Fall’02
Previously at Carnegie Mellon University PhD and MS in IS from Carnegie Mellon Also, BS Mech Engineering & MBA Over 18 years of working experience Mostly implementing and managing systems And in management Specialty: systems implementation and database Mostly in international/global contexts Teach: Intro to IT, web programming, business analysis, database Research focus: IT support for global & geographically distributed collaboration Most recently: team coordination across time zones

Class Web Site Current versions of syllabus, class schedule, lecture notes, and homework assignments will be posted on the Blackboard class web site. Course Syllabus also available at: Class Schedule also available at: All homework assignments, lecture slides, and other class materials will be available via the Class Schedule link above, and also via Blackboard Class announcements and grades will be available via Blackboard only

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)

What is requirements analysis?
Requirements are conditions that a product, system or component must meet and/or capabilities it must have to solve a business problem, satisfy a contract, or meet a standard, specification or other formally imposed documents - IEEE Requirements analysis is one of several business analysis practices, concerned with identifying requirements for a business application implementation.

ITEC 455: Business Requirements Analysis
Course Roadmap Business application development Business analysis overview Introduction to requirements analysis Business process analysis Requirements analysis and use cases Data/information analysis Interface analysis Project analysis

The Context of Business Analysis: “Business Application Development”

Information Technology (IT) and Business
ITEC 455 Information Technology (IT) and Business Business World Transactions Transaction Processing Information Decision Support Distributed Collaboration Enterprise Collaboration Financial Management etc. ERP, SCM, CRM, etc. Microcomputers Business Applications IT Infrastructure Client Appl Server Appl Client/Server Computing Distributed Computing DB (Local/Wide area) Networks Database Mainframes Ubiquitous Computing Security, Firewalls Inter-Networking (Internet, Intranets) Virtual Private Networks Routers “The Cloud & Web 2.0”

What is Information Technology (IT) for Business?
= IT Infrastructure: the hardware, system software, telecommunications/networks and data storage supporting all business applications + Business Applications: software used to manage particular business functions or processes (e.g., accounting, supply chain management)

What is an Information System (IS) for Business?
An arrangement of people, business functions, processes, and IT which interact to collect, store and process, and store data to provide information to support business activities and decisions It is much more than just IT!!

Information Systems IT for Business
People, Processes & Business Functions IT Infrastructure (HW, System SW, database, telecom) Business Applications (ERP, CRM, SCM, Financial Appl, etc.) + + Information System = Business Value !!

Requirements for a Cool House: (first meeting with the client: a very high level description of the house) 3 bedrooms, dinning room, living room, kitchen, laundry room, 2-1/2 bathrooms Back patio, access from the kitchen 2-floors + basement 2-car attached garage w/extra room on top & driveway Landscaped front yard & small trees in the backyard 2 windows, one on each side of front door 2 windows on 2nd floor above with 1st floor windows 2 small windows above garage on extra room

A Cool House: A Sketch (a visual representation to discuss w/client)

A Cool House: A Scale Drawing (a more detailed representation to discuss w/client)

A Cool House: The Blueprints (very specific dimensions to discuss w/client and then give to builders for construction: i.e., communicating client requirements)

SYSTEM DEVELOPMENT ITEC 455 All the activities that go into
producing and IS solution: 0. Vision Analysis Design Implementation Testing Conversion Production & Maintenance Degree of ceremony or formality? Depends on size, risk, etc. ITEC 455

1. Analysis A communication exercise between system users and system developers An analysis of the “problems” to be solved by an information system Developing an understanding of “the work” that the system needs to perform Developing an understanding of “what” the system needs to do Implication: Understanding the business problem is critical before offering solutions

2. Design An analysis of the “solutions” to the problems identified during systems analysis Developing and understanding of “how” the system needs to do what was identified during systems analysis, per the “requirements specification” Implication: Can’t design a solution until you’ve analyzed the problem

3. Implementation Selection, acquisition, production and assembly/integration of the necessary components of the system For systems that require software development, translating the conceptual design into specific software instructions to accomplish the work. Implications: Can’t purchase off-the-shelf software until you’ve until you’ve analyzed the requirements Can’t build an application until you’ve designed

4. Testing Implication: Test Types:
UNIT TESTING: each part of the system works well individually SYSTEM TESTING: all the parts of the system work well together REGRESSION TESTING: new parts of the system work well with the existing system ACCEPTANCE (USER) TESTING: By users and/or clients BLACK BOX TESTING: Testing if the system does what is supposed to, per requirements specifications, without inspecting the internals of the system CLEAR BOX TESTING: Inspecting and testing the internals (e.g., code inspections) of the system (opening the black box) Implication: Analysis artifacts (e.g., use cases) can be used for testing (e.g., acceptance and black box testing with “test cases”)

5. Conversion (i.e., Installation)
Important Conversion Issues: CONVERSION PLAN: Schedule for conversion DOCUMENTATION: Description of how system works USER TRAINING Conversion Methods: PARALLEL: Old & new run simultaneously DIRECT CUTOVER: Risky conversion to new system PILOT: Introduce first in one area, domain, location PHASED: Implement the system in stages Implication: Analysis artifacts (e.g., use cases) can be used to develop user manuals and other system documentation

6. Production & Maintenance
PRODUCTION: Review by users & operators User support MAINTENANCE: Upgrades Bug fixes Implication: Requirements are not static, they evolve over time Features are always added and discontinued

EFFORT DISTRIBUTION Systems Analysis & Design Maintenance
Testing & Integration Implementation

Systems Development Models
Linear Sequential Models System development progresses in a straight line fashion Evolutionary Models System development is done in iterations

System Development Life Cycle (SDLC) or the “Waterfall” Model (Linear Sequential)
Analysis True Waterfall Design Implementation Testing and Conversion Production & Maintenance In reality

SDLC (“Waterfall”) Model Pros & Cons
Oldest and most widely used model Life cycle concept is very useful OK when requirements are certain and stable Cons: Early errors detected late are very costly Not very useful when requirements are uncertain Many real projects rarely follow a sequential flow Often difficult to know all requirements early on Programmers have to wait until the whole design is finished

The Incremental Model (Linear Sequential)
Core Product Analysis Design Programming Increment 1 (new feature) Analysis Testing, etc. Design Programming Integration + Regression Testing Increment 2 (new feature) Analysis Testing, etc. Design Etc. Programming Testing, etc. The Incremental Model (Linear Sequential)

Incremental Model Pros & Cons
Core functionality can be provided quickly Increments can be planned to manage technical risks (e.g., increment, evaluate, increment, evaluate, etc.) Cons: Takes a long time to finish entire system Later increments may never get done

The Spiral Model (Bohem) (Evolutionary)
Construction (Implementation) Testing & Release (Conversion) Engineering (Analysis & Design) Customer Communication & Evaluation (Business Requirements) Risk Analysis Planning

The Spiral Model Pros: Cons:
Each loop allows the team to assess risks and adjust the plan More realistic approach for large projects Conceptually sound idea Cons: Not many – the basic concept is widely adopted Is the foundation for the Unified Process (UP)

Object-Oriented (OO) Analysis
Most prevalent software system development paradigm today In which a system is conceptualized by discovering physical objects that the system needs to represent – e.g., customers, locations, students, classrooms, invoices, etc.) And discovering their attributes (i.e., data elements – e.g., name, SSN, etc.) and behaviors (i.e., programs – e.g., place an order) More on OO later in the course

Standards Standards are necessary when many people are involved in a system development effort. There are many types of standards, but two important ones are standards about: (1) notations and (2) processes A notation (i.e., a language) is necessary to describe the system. Standard notations describe the symbols to use in models and other analysis artifacts. We will use the UML (Unified Modeling Language) A process is necessary to define the sequence of activities that will be undertaken to gather requirements and then design and implement the system: We will use the UP (Unified Process)

Unified Modeling Language (UML)
UML a standard for notations and methods to express OO A/D UML is the most widely adopted standard diagramming notation to describe systems today Proposed by Booch, Jacobson & Rambaugh (the “Three Amigos”) to unify their individual (most widely used) notations See Object Mgt Group site: Main purpose of the UML: communication!! It is intended for OO Analysis and Design (OO A/D) You can do OO A/D without UML using other notations Similarly, you can use aspects of UML for non OO A/D UML is up to version 2.0, textbook UML 1.3, MS Visio UML 1.2 For more info on UML and versions, see:

Important UML Models/Artifacts
To be covered in class: Use Cases – a set of scenarios of system uses, each tied together by a common user goal – all use cases collectively describe the functionality of the system – each use case describes a discrete aspect of that functionality Use Case Diagrams – a visual model that shows how all actors (i.e., users and external systems) interact with all use cases of a system Activity Diagrams – diagrams that explain use case workflows (sometimes useful, but use case text is often preferred) Class Diagrams – describes the types of objects in a system and the static relationships among them Other important UML models/artifacts not covered in this class: Domain models, interaction diagrams, class-responsibility-collaboration (CRC) cards, state diagrams, etc.

The Unified [System Development] Process (UP)
A system development process defines the activities undertaken to build, deploy, and maintain systems UP: a popular SW development process used with OO methods – a derivative of the spiral method UP was also developed by the “Three Amigos” UML and UP are independent – you can use UML without UP, or UP without UML, but they were both conceptualize to work together Rational UP (RUP): a refinement of the UP formulated by the “Rational Corporation” now owned by IBM, widely adopted today. See:

Key Aspects of the UP Iterations: “timeboxed” – i.e., of fixed time length of 2-6 or more weeks – date slippage is discouraged – removing tasks or requirements from the iteration is preferred Workshops: each iteration begins with at 1-2 day workshop to discuss the scope of the iteration and plan accordingly. 4 Phases: inception, elaboration, construction and transition – this course deals with the inception and elaboration phases Disciplines (originally called “workflows” until 2001): a set of related system development activities (e.g., analysis, design, etc. – note: these are considered “phases” in the Waterfall model) Artifacts: working products such as code, database schemas, text documents, diagrams, models, etc. Development Case: articulates upfront which artifacts (not all artifacts need to be employed) will be used in the particular development project

Iterations, Disciplines & Workflows in the UP
Incep Elab 1 Elab etc. Source: Larman book ch.2, p.21

Development Case Not every artifact is used in every project. The development case articulates the specific artifacts that will be used on a specific project. This is the development case we will follow for your projects – marked in bold red: Discipline UP Artifact Inception I1 Elaboration E1..En Construction C1..Cn Transition T1..Tn Business Modeling Domain Model S Analysis Vision R Use Case Model Supplementary Spec Glossary Design Design Model SW Architecture Doc Data Model Implementation Implementation Model SW Development Plan Testing Test Model Dev Environment Development Case S – Start; R – Refine UP Phases

Important Things to Keep in Mind
Ceremony or Formality: High ceremony: lots of formal deliverables, meetings, etc. How much? it depends The right process? it varies for each company Requirements and Design = communication exercises No need to use all diagrams or artifacts No need to note everything, only what is noteworthy Avoid overdoing requirements (i.e., analysis paralysis): keep it simple, but accurate Let’s look at the Class Schedule once again Let’s look at the Final Project

First, the big picture: Enterprise Analysis

Information Systems and Application “Silos”: The Old Way
Silos or Stovepipes

The New Way: Focus on Business Processes
A process: Manner in which work is organized and coordinated to produce a product or service Some business processes take place within a function Some others cut across multiple business functions Concrete work flows of material, information, and knowledge Unique ways to coordinate work, information, and knowledge Example: processing a customer order

A Process May Cut Across Multiple Departments

Enterprise Architecture and Business Process Orientation: The New Way
Business Domain Business Application ITEC 455 Business Process Model Information Model Organization Goals Application Model Technology Model Enterprise Model

EA Process (Armour et al 1999, TOGAF):
EA Maturity (Ross et al 2006) Business Silos (i.e., stovepipes) Standardized Technology Optimized Core Business Modularity Baseline EA Transition from Baseline to Target EA -Can’t always architect from the ground up A very dynamic process -Change is difficult Target EA Individual System Implementations

Business Analysis

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)

About the Business Analysis Profession
Business analysts used to be called “systems analysts” Business analyst is the preferred title today in recognition of the fact that business strategies and system implementations need to be tightly aligned, so the analyst needs to thoroughly understand business goals, functions and processes, more than systems per se (CIO Magazine) A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems (iiBA) 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 (iiBA)

Business Analysis Skills
Ability to develop a thorough understanding of: the requirements to solve a business problem, often with a system implementation how the proposed system or solution will interoperate or integrate with the existing systems and technology in which the new system will operate. how the proposed system or solution fits the existing enterprise architecture and business strategies the business problem from multiple perspectives: business, user, functional, quality of service, implementation, etc.

Business Analysis Body of Knowledge (BABoK)
See iiBA (BABoK is available for a fee (selected sections on Blackboard Business analysis planning and monitoring Requirements elicitation Requirements management and communication Enterprise analysis Requirements analysis Solution assessment and validation Underlying competencies

Requirements Planning and Monitoring
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 Management and Communication
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.

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

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)

Underlying Competencies
Behaviors, characteristics, knowledge and personal qualities that support the practice of business analysis, including: Analytical Thinking and Problem Solving: creative thinking, decision making, learning, problem solving, systems thinking Behavioral Characteristics: ethics, personal organization, trustworthiness Business Knowledge: business principles and practices, industry knowledge, organization knowledge, solution knowledge Communication Skills: oral communications, teaching, written communications Interaction Skills: facilitation and negotiation, leadership and influencing, teamwork Software Applications: general purpose applications, specialized applications

Introduction to Requirements Analysis

Why are accurate requirements so important?
The cost of fixing and error in requirements is: Times larger If discovered during 5 Design 10 Implementation 20 Testing 100 Operations Bohem, Barry R Software engineering economics. Englewood Cliffs, N.J.: Prentice-Hall.

Errors Propagate and Grow
problem correct requirements wrong correct design design based on wrong requirements wrong code based on wrong designs correct code wrong wrong requirements

Requirements Analysis is Key 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 Requirements is 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

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

“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

Volere Requirement Shell

Requirements Defined 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 Non-functional Requirements (non-behavioral) The qualities of the system (e.g., speed, reliability, capacity) Other Requirements Project requirements, risk, costs, deliverables, deadlines, etc. Prepared using a “System Requirements Process” Articulated in a “System Requirements Specification”

Functional Requirements
Are descriptions of “the work” the system needs to do Articulated with text and/or models/diagrams When you think of functional requirements think of verbs The functional requirements define the “functional scope” of the application – i.e., where its responsibility begins and ends We will use “use case” analysis to define the functional scope of applications in this course Your articulation of functional requirements becomes your “demonstrated understanding” of the business processes your system needs to automate – Eric Bristow, Deloitte Consulting Generally, functional requirements will take the largest share of time to gather – you must understand quite well what the system needs to do.

Non-Functional Requirements
Are “the properties that your product must have … they are not part of the fundamental reason for the product’s existence, but are needed to make the product perform in the desired manner … they describe the experience that the user has while doing the work” – Robertson & Robertson Functional requirements  think of verbs Non-functional requirements  think of adjectives Non-functional requirements generally are better known by clients and will not take as long to determine – but have huge implications on system cost.

Examples of Non-Functional Requirements
Look and Feel – interface, style Usability – ease of use/learning, personalization, access considerations, interface features Performance – speed, latency, reliability, availability, capacity, scalability, etc. Operational – technical/physical environment Maintainability and Portability – ability to fix, support, and port the system Security – access, integrity, privacy, etc. Cultural and Political Legal

Non-Functional Requirements Conclusion
Critical to successful development of the system Misunderstanding of these requirements can significantly impact cost and feasibility of system Difficult to represent in object models and use cases. Typically represented using some form of text in the requirements, then realized in the architecture. Can be hard to validate, unless they are quantified – i.e., fit criteria

General Qualities of Good Requirements
Correct Unambiguous Complete Verifiable (i.e., fit criteria) Consistent Understandable Modifiable Traceable Design independent Concise Organized Prioritized

Other Requirements Issues
Mandated constraints: are indistinguishable from design decisions, except that they are requirements mandated by the client – e.g. use Oracle platform for all databases; develop a web based application Facts: are conditions about the system’s external environment (e.g., actors, systems, organizations) known to be true – they are different than mandated constraints in that they are about the application context, but not mandated by the client the system– e.g., visually and hearing impaired users will need to use Assumptions: are conditions about the system’s external environment (e.g., actors, systems, organizations) believed, but not confirmed to be true – e.g., all users speak English

The Requirements Specifications Robertson & Robertson’s “Volere Specifications Template (on Blackboard)” 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: we use an adaptation (simplified version) of the Volere Template

Business Process Modeling

A (simplified) Deloitte BPM Example

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 or map (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

BPM Symbols Terminator: start and end points in a process – it only has one input or one output, not both. Process step: a specific step in the process – it MUST have one input and one or more outputs Pre-defined process: like a process steps but it actually incorporates multiple steps. They are useful to simplify the diagramming of complex processes Decision: a question or a branching in the process flow it MUST have one input and one output for each possible decision outcome Process flow: a directed arrow that specifies the process sequence Functional bands or swim lanes: show which departments, units or functional roles are associated with different parts of the process Phase or separators: use to differentiate different phases of the process

BPM Symbols (Cont’d.) Parallel Processing: use these to branch out into multiple parallel flows or to merge them into a single flow. Off-Page Reference: use it to link to another page On-Page Reference: use it to link to other parts of the diagram within the page to avoid line crossings and complex flows These are older legacy symbols frequently used in flowcharts, which you can also use in BPM’s, but I suggest adding notations for these symbols for a non-technical or younger audience : More BPM symbols:

“Cross Functional Flowchart” (non-UML) BPM Symbols

Some Guidelines for Good BPM Modeling
Process steps: Can have more than one 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 Must have at least one input and one output – unconnected process step boxes without input and output are incorrect Pre-Defined Process: Same as process steps, but can have more than one output In their detail diagrams, use connector symbols to show where the pre-defined process connects to other sub-processes. 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 Process flows: Must connect two symbols (process box, decision, start, end, etc.) – unconnected flows are incorrect. You can add other symbols to add clarity (e.g., page references, connectors, database, printout, etc.); label these symbols as needed for clarity

Some BPM Guidelines BPMs are used to document business processes, NOT systems actions – focus on understanding and documenting what people do and what the key processes are, rather than what the system solution will do. In other words, you need to understand the business processes before you can suggest a solution. It often helps to distinguish the baseline BPM (what the client does) from the target BPM (what the client wants or your proposed solution). You can add notations and other symbols to distinguish baseline from target processes It may also help to distinguish processes that are carried out manually from those that are handled by applications More importantly, this is NOT hard science – if you can do anything to add descriptive clarity to your BPM, by all means

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:

BPM Example - Current Cross-Functional Flowchart

More Guidelines (see vehicle prior rental example)
If there is a process already in place (i.e., baseline) and you are proposing process improvements (i.e., target) Differentiate the two in your diagram or have two separate diagrams If your solution includes building a system but there are process steps that will not be handled by the system, your diagram(s) should distinguish the manual steps from those to be handled by the system It is important to number or label all the process steps (P1, P2, etc.) and the decision steps (D1, D2, etc.) to: Facilitate reference to specific parts of the process To cross reference with other models  using “transitional artifacts” (more on this later)

BPM Example – Proposed

Some BPM Diagramming Guidelines for Complex BPMs
If the BPM is complex and there are two or more distinct sub-processes, it is recommended to break up the BPM into two sub-models, and then: Prepare a high level or master diagram that shows all the sub-processes using pre-defined process symbols Prepare a separate detail diagram for each sub-process

Master BPM Example Each Pre-Defined Sub-Process Box Has its Own BPM Diagram

BPM Example – Proposed Vehicle Prep Paperwork Vehicle Delivery

BPM Example – High Level Diagram

BPM Example: Defined Process Details
Connector

Business Requirements Analysis ITEC-455 Spring 2010

Similar presentations

Presentation on theme: "Business Requirements Analysis ITEC-455 Spring 2010"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Business Requirements Analysis ITEC-455 Spring 2010

Similar presentations

Presentation on theme: "Business Requirements Analysis ITEC-455 Spring 2010"— Presentation transcript:

Similar presentations

About project

Feedback