Analyst or Stenographer? Alec Sharp - UKIIBA Meeting March 2010

Get Started. It's Free
or sign up with your email address
Analyst or Stenographer? Alec Sharp - UKIIBA Meeting March 2010 by Mind Map: Analyst or Stenographer? Alec Sharp - UKIIBA Meeting March 2010

1. Current State of Business Analysis

1.1. Implementation Techniques Swimming Upstream

1.1.1. Relational Database Design

1.1.2. OOAD

1.1.3. UML

1.1.4. BPMN

1.2. What's Your Method Emphasis?

1.2.1. COTS

1.2.2. Custom

1.3. Emphasis on Writing Effective Requirements

1.3.1. Synthesise Requirements into a Solution

1.3.2. Failed Projects = Large No. Requirements

1.3.3. Requirements myth - business knows it's requirements

1.3.4. Common Approaches Requirements Management Course Produce Managed list of Requirements Analyst/Developer Gap Analysis takes Modelling Course Analyst Build Rigorous set of Models Overly Complex Models Analyst/Client Gap

1.3.5. Who Loves These? Auditors Fixed price contracters Testers Managers Lawyers Contract Administrators

1.3.6. MYTHS They are known by client in advance They are not ... They emerge or are refined in context Emergent Adaptive Context The best form is written Each requirement must be managed A good requirement contains no design elements Once requirements are collected the analysts job is done

2. Analysis as Design

2.1. More in common with design (architecture)

2.1.1. Why not be called business architects or designers?

2.1.2. Not managers

2.1.3. Analysts ... business intelligence and analytics

2.2. Yay!

2.3. Goal

2.3.1. Unify Client, Analyst and Developer Client: Understand and Verify Analyst: Simple techniques doable in timeframes Developer: Requests they can do something with

2.4. Context

2.5. Analysis as User Centered Design

2.5.1. Personas

3. Key Skills

3.1. Analysis = Decomposition: Breaking down into parts

3.2. Representation: Depiction

3.3. Analogy: Telling Stories

3.4. Synthesis: Assembling of parts into a whole

3.4.1. Alignment?

3.4.2. Alternate Visions of a Future that Doesn't Exist My Mission Statement: Build Worlds; Tell Stories; Deliver Value; Delight Users

4. Techniques

4.1. User Stories?

4.2. Use Interrogatives

4.2.1. Who

4.2.2. What

4.2.3. Why

4.2.4. When

4.2.5. Where

4.2.6. How

4.3. Use Cases

4.3.1. Confusing

4.3.2. Too big

4.3.3. Mean different things to different people

4.3.4. About design and construction of software

4.3.5. Ok when used appropriately

4.3.6. Use for Who and How (use interaction) External User Interface

4.4. Process Model

4.5. Data Models

4.5.1. A picture of the things the business cares avout

4.5.2. Not used enough

4.6. Service Specification

4.6.1. User for describing What the application does

5. Alec's Framework

5.1. Levels of Detail

5.1.1. Scope Business Plan

5.1.2. Concept Analyst Can go into Agile Understand

5.1.3. Detail Experts Takes 80% of effort Specify

5.2. Steps

5.2.1. Business Objectives Business Events

5.2.2. Business Process

5.2.3. Presentation Services

5.2.4. Business Services

5.2.5. Data Services Example looks like a simple UML class model!! Ontology not a ERD I would call this a fact model to avoid confusion with ERD

6. Questions

6.1. Requirements as Incremental/Iterative - Agile Requirements?

6.1.1. Yes

6.1.2. Go to concept level

6.1.3. Just enough requirements just in time

6.2. How does it fit with traditional requirement types

6.2.1. Pure what of functional

6.2.2. Focus on a discrete business event

6.3. What are high level requirements?

6.3.1. Customer's Wishlist

6.3.2. Needs and Wants

6.4. Relationship to architecture and capabilityies

6.4.1. A whole other presentation