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
1.3.4.1. Requirements Management Course
1.3.4.2. Produce Managed list of Requirements
1.3.4.3. Analyst/Developer Gap
1.3.4.4. Analysis takes Modelling Course
1.3.4.5. Analyst Build Rigorous set of Models
1.3.4.5.1. Overly Complex Models
1.3.4.6. Analyst/Client Gap
1.3.5. Who Loves These?
1.3.5.1. Auditors
1.3.5.2. Fixed price contracters
1.3.5.3. Testers
1.3.5.4. Managers
1.3.5.5. Lawyers
1.3.5.6. Contract Administrators
1.3.6. MYTHS
1.3.6.1. They are known by client in advance
1.3.6.1.1. They are not ... They emerge or are refined in context
1.3.6.1.2. Emergent
1.3.6.1.3. Adaptive
1.3.6.1.4. Context
1.3.6.2. The best form is written
1.3.6.3. Each requirement must be managed
1.3.6.4. A good requirement contains no design elements
1.3.6.5. 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
2.3.1.1. Client: Understand and Verify
2.3.1.2. Analyst: Simple techniques doable in timeframes
2.3.1.3. 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
3.4.2.1. 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)
4.3.6.1. External
4.3.6.2. 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
5.1.1.1. Business
5.1.1.2. Plan
5.1.2. Concept
5.1.2.1. Analyst
5.1.2.2. Can go into Agile
5.1.2.3. Understand
5.1.3. Detail
5.1.3.1. Experts
5.1.3.2. Takes 80% of effort
5.1.3.3. Specify
5.2. Steps
5.2.1. Business Objectives
5.2.1.1. Business Events
5.2.2. Business Process
5.2.3. Presentation Services
5.2.4. Business Services
5.2.5. Data Services
5.2.5.1. Example looks like a simple UML class model!!
5.2.5.2. Ontology not a ERD
5.2.5.3. 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