be a business analyst

iRise Presentation for Neumont University

October 29, 2007

A rigorous 237½ step process for the systemic discovery and definition of non-functional requirements for safety-intensive systems

based on statistical methods and empirical observation

Neumont University

Why being a BA is Fun *and* Important…

Business Analysis for Fun and Profit

Neumont University

Developers are being off-shored, be a BA…


Neumont University

Business Analysis, Requirements and SimulationBusiness Analysis for Fun and Profit

Neumont University

The skills you need to displace stodgy old BAs already in the workforce…


Neumont University

Be a BA


Neumont University

Copyright © 2007 iRise, Inc. All Rights Reserved. www.irise.com

Tom HumbargerSenior Strategic Projects Manager

[ [email protected] ]


Introduction

• Why do we need Business Analysts?

• What do they do?

• Frameworks, processes and taxonomies

• Simulation


Objectives

• Provide you a glimpse into the world of a BA

• Introduce ideas that might lead you down some relevant personal research paths

• Introduce the concept of simulation as an enabler for application definition

• Whet your appetite…


How well you communicate is determined not by how well you say things but by how well you are understood.

Andrew S. GroveChairman, Intel (’97 – ‘05)


Different interpretations

Marketing Sales IT

FinanceManufacturingEngineering


What the customer needs


Defects cause challenges

Requirements56%

Code7% Other

10%

Design27%

- This data from James Martin

Over 50% of software defects are attributed to requirement errors


Code1% Other

4% Design13%

Requirements82%

- This data from Dean Leffingwell

Defects cause rework

Over 80% of rework effort is spent on requirements related defecOver 80% of rework effort is spent on requirements related defectsts


- This data from I. Hooks

0 5 10 15 20 25

200180160140120100806040200

Per

cent

age

of C

ost O

verru

n

Requirements Process Costs as Percentage of Total Project Cost

0- 5% on Requirements ProcessResults in 80-200% Overrun

8-14% on Requirements ProcessResults in 0- 60% Overrun

Value of Investment in Requirements Process

Development Project

Requirements Management Impact

Copyright © 2007 iRise, Inc. All Rights Reserved. www.irise.com- This data from Boehm: Software Engineering Economics

RequirementsRequirements

Analysis& Design

Coding

DevelopmentTesting Acceptance

Testing

ProductQuality

Production

What did Archimedes say?

Copyright © 2007 iRise, Inc. All Rights Reserved. www.irise.com- This data from Boehm: Software Engineering Economics

RequirementsRequirements

Analysis& Design

Coding

DevelopmentTesting Acceptance

Testing

ProductQuality

Production

40-100x

30-70x

15-40x

10x

3-6x

1x

The Quality Lever


Who is responsible for those requirements?


The Business Analysts


The User Experience Professionals


The Product Managers


The “Business Designers?”


What is a Business Analyst or BA?

It’s hard to say…

• BA = Business Analysis

• UX = Usability Experience

• IA = Information Architecture

• ID = Interaction Design

• SA = Systems Analysis

• WA = Workflow Architecture

• PM = Product Management or Project Manager

• DA = Data Analysis

• PA = Process Analysis

• QA = Quality AnalysisNote – These are disciplines, not roles


What does a business analyst do?

• Analyze & solve problems

• Understand the business

• Communicate effectively (write & speak)

• Manage client relationships

• Facilitate discussions

• Negotiate & build consensus

• Model data & processes

• Plan & manage activities

• Facilitate & develop business strategy

• Understand & manage organizational change


What Roles Does A BA Play?

• Analyst / Problem Solver

• Facilitator

• Negotiator

• Artist / Architect

• Planner

• Communicator

• Diplomat

• Expert / Consultant

• Strategist

• Revolutionary


WYSIWYG


WYSIWIS


DWIM


Business


IT


Business IT


Grokking


Can you grok it?

grok/, /grohk/ 1. To understand, usually in a global sense. Connotes intimate and exhaustive knowledge.

(From the novel "Stranger in a Strange Land", by Robert A. Heinlein, where it is a Martian word meaning

literally "to drink" and metaphorically "to be one with")


Grokking

Not a whole lot of grokking going on…


What causes this lack of grokking?

Ambiguity UncertaintyRap music

Creationism (aka BUFD)Timelines

Tooling/Support

Culture Creeping elegance

Banana problem

MisunderstandingUnclear Expectations

“That’s how it’s always been”


Requirements


What are requirements made of?


Words…


Words are little bombs…

“Words are little bombs, and they have a lot of energy inside them."

"I have this theory about words. There's a thousand ways to say `Pass the salt.’ It could mean, you know, `Can I have some salt?'; or it could mean, `I love you.'; It could mean `I'm very annoyed with you'; really, the list could go on and on.”

Christopher Walken


Where do words or requirements come from?


“Gathering” sounds easy, doesn’t it?


Here’s a prettyorange requirement.I’ll take it back toThe office.

Tim Lister - Keynote Agile

Development Conference 2004


I think I may have a requirements management

problem…


In reality, it means asking, digging, wrenching, pulling, cajoling,

extracting, wringing, bargaining, negotiating, begging, pleading…


…beseeching, demanding, imploring, entreating, bartering, dealing,

probing, querying, mining, sweet-talking, requesting, inquiring…


…searching, questioning, coaxing, appealing, enticing, arm-twisting,

trading, haggling, petitioning, wheedling…


…(whew!)...


Or the alternative…budgeting for goons


…from people who, in the end, don’t really know what they need…


…until they see it.


…until they see it…

That’s not *exactly* what

I had in mind…


IKIWISI


Or maybe…it’s not until they try it…


IKIWITI


The sooner the users try it the better…


The better the “try,” the more useful the feedback…


Requirements Processes


Wiegers’ Requirements Taxonomy (www.processimpact.com)


Volere Requirements Process (www.volere.co.uk)


BA BOK Knowledge Areas (www.iiba.com)

Requirements Planning & Management

RequirementsGathering

RequirementsImplementation

RequirementsAnalysis &

Documentation

RequirementsCommunications

EnterpriseAnalysis

Fundamentals


iRise G-A-V Framework (www.irise.com)

Application Definition Iterations

Business

Application Definition

RawRequirements

Implementation

Structured,Complete

Requirements

Intent, Vision,Goals, Rules

Analyst

IT

ConfirmationClarificationVision


RequirementsAnalysis

RequirementsValidation

Validated,Simulated

Requirements


iRise G-A-V Framework - Gathering

Application Definition Iterations

Business

Application Definition

RawRequirements

Implementation

Structured,Complete

Requirements

Intent, Vision,Goals, Rules

Analyst

IT

ConfirmationClarificationVision


RequirementsAnalysis

RequirementsValidation

Validated,Simulated

Requirements


RequirementsDocumentation


IEEE Standard-based sample structure

1. Introduction1.1 Purpose1.2 Document Conventions1.3 Intended Audience and

Reading Suggestions1.4 Product Scope1.5 References

2. Overall Description2.1 Product Perspective2.2 Product Functions2.3 User Classes and Characteristics2.4 Operating Environment2.5 Design & Implementation Constraints2.6 User Documentation2.7 Assumptions and Dependencies

3. External Interface Requirements 3.1 User Interfaces3.2 Hardware Interfaces3.3 Software Interfaces3.4 Communications Interfaces

4. System Features4.1 System Feature 1

4.1.1 Description and Priority4.1.2 Stimulus/Response Sequences4.1.3 Functional Requirements

4.x System Feature x

5. Other Nonfunctional Requirements5.1 Performance Requirements5.2 Safety Requirements5.3 Security Requirements5.4 Software Quality Attributes

6. Other Requirements

Appendix A: Glossary

Appendix B: Analysis Models

Appendix C: To Be Determined List

Copyright © Process Impact. Karl Wiegers. 2001. All rights reserved. In Search of Excellent Requirements0 02/2001

1-69

Software Requirements Specification


Volere-based sample structure

PROJECT DRIVERS1. The Purpose of the Project 2. Client, Customer and other

Stakeholders3. Users of the Product

PROJECT CONSTRAINTS4. Mandated Constraints5. Naming Conventions and Definitions6. Relevant Facts and Assumptions

FUNCTIONAL REQUIREMENTS7. The Scope of the Work8. The Scope of the Product9. Functional and Data Requirements

NON-FUNCTIONAL REQUIREMENTS10. Look and Feel Requirements 11. Usability and Humanity Requirements12. Performance Requirements13. Operational Requirements14. Maintainability and Support Requirements15. Security Requirements16. Cultural and Political Requirements17. Legal Requirements

PROJECT ISSUES18. Open Issues 19. Off-the-Shelf Solutions20. New Problems 21. Tasks 22. Cutover23. Risks24. Costs25. User Documentation and Training26. Waiting Room27. Ideas for Solutions

- Suzanne and James Robertson


Process Impact - sample structure

Table of Contents

Revision History

1. Introduction1.1 Purpose1.2 Project Scope and Product Features1.3 References

2. Overall Description2.1 Product Perspective2.2 User Classes and Characteristics2.3 Operating Environment2.4 Design and Implementation Constraints2.5 User Documentation2.6 Assumptions and Dependencies

3. System Features3.1 Order Meals3.2 Create, View, Modify, and Delete Meal

Subscriptions3.3 Register for Meal Payment Options3.4 Request Meal Delivery3.5 Create, View, Modify, and Delete Cafeteria

Menus

4. External Interface Requirements4.1 User Interfaces4.2 Hardware Interfaces4.3 Software Interfaces4.4 Communications Interfaces

5. Other Nonfunctional Requirements5.1 Performance Requirements5.2 Safety Requirements5.3 Security Requirements5.4 Software Quality Attributes

Appendix A: Data Dictionary and Data ModelAppendix B: Analysis Models

- Karl Wiegers


Words…

• Are a cumbersome way to communicate

• Lack precision

• Require mental translation


Density doesn’t equal fidelity.


Comprehension can’t be calculated in words per square inch.


Understanding isn’t measured in lbs. per feature.


Because it’s hard to “try” a document…


Have we automated the right things?

• Specification generation

• Analytics and drill-down reporting

• Traceability and impact analysis

• Requirement meta-data and auditing

• Use Cases, UML…

• State Transition Diagrams

• Specification languages (LOTOS, Z, Planguage…)

• Etc…


Are we thinking outside the box?


Visualize


Sharing a mental model isn’t easy…unless you make it easy for people to see the

what they mean.


What industries use visualization?


Architects visualize success


Boeing visualizes success


GM visualizes success


What is simulation?


Simulations are just models of reality


What if…


…non-developers could create interactive simulations of the software product before coding? Every time.


And they could create prototypes with both the speed and agility (roughly) of

paper prototyping…


…and imbue them with the richness possible in a coded prototype?


So, why not simulate software?


Viola - CAD for software!


How could we use simulation to facilitate the evaluation and feedback

loops necessary for a good design process?


Could we use simulation to generate excitement with both the users and the executive sponsors of a project?


Could we use simulation to ensure we’re building the right software?


Are we outside the box yet?


“iRise simulations let business people, end users and developers interact with critical

business systems before development. The visual representation of the application looks

and behaves like the real thing, including data interactions and business logic, so everyone

literally gets on the same page. “

iRise definition of simulation


Kinesthetic


Variable Fidelity


Immersive


Compelling


Very low fidelity…


Low fidelity


Medium fidelity

Drug DoseDrug ABCDrug DEF

100 mg200 mg

Route Freq Indication Last Dose Comment

Current Medication List

------------

------------

------------

------------

------------

Add Delete Modify Save No Change Cancel

Consistent function with other EMR design, e.g. allergy documentation

User will be able to make all changes then Save

Last Updated: Date/timeUpdated By: Name/Title

Show Brand (Generic) name

When possible.


High fidelity


Or the alternative…


Ultra-high fidelity


"Few things are harder to put up with than the annoyance of a good example.”

- Mark Twain


Finally…our new mission statement


Gather• Ask “Why” 5 times to get out of the weeds

• Use a variety of approaches to engage different kinds of stakeholders

• Begin with open-ended questions - use close-ended questions to drill down to specifics

• Use whatever methods are at your disposal to help stakeholders visualize the solution

Analyze• Checklists for requirements quality

• Capture Priority and some measure of cost/complexity to rank requirements

• Rank requirements!

• Use pivot tables to rank / group / drill down on requirements

Validate• Checklists for ambiguity reviews

• When someone gives you a requirement - ask how they’d test it, right up front

• Help stakeholders visualize the solution to make sure you’re on the right track

Manage / Process• Implement RM in a staged approach - 80/20 rule first

• Fine tune templates based on freely available templates (Use Google!)

• Provide visibility to get the most possible eyes on requirements

Some pretty good BA practices


Careerbuilder.com job openings stats

• “business analyst” – 4,748 job openings» CA – 420» NY – 324» TX – 348» IL – 306» UT – 17

• “software engineer” – 6,489 job openings» CA – 938» VA – 424» TX – 394» IL – 378» UT - 60

As of 10/26/07


Business Analyst from Salary.com

Business Systems Analyst IReviews, analyzes, and evaluates business systems and user needs. Formulates systems to parallel overall business strategies. May require an associate's degree in a related area and 0-2 years of experience in the field or in a related area. Has knowledge of commonly-used concepts, practices, and procedures within a particular field. Relies on instructions and pre-established guidelines to perform the functions of the job. Works under immediate supervision. Primary job functions do not typically require exercising independent judgment. Typically reports to a manager.


SW Engineer from Salary.com

Entry Level Software EngineerDesigns, modifies, develops, writes and implements software programming applications. Supports and/or installs software applications/operating systems. Participates in the testing process through test review and analysis, test witnessing and certification of software. Requires a bachelor's degree in a related area and 0-2 years of experience in the field or in a related area. Has knowledge of commonly-used concepts, practices, and procedures within a particular field. Relies on instructions and pre-established guidelines to perform the functions of the job. Works under immediate supervision. Primary job functions do not typically require exercising independent judgment. Typically reports to a manager.


Business Analyst Resources

• International Association of Business Analysts (IIBA)» www.theiiba.org

• Usability Professionals Association (UPA)» www.upassoc.org

• Project Reference» http://www.projectreference.com/

• Volere Requirements Resources» http://www.volere.co.uk/


www.mycatalyze.org


http://www.facebook.com/group.php?gid=18509427840


Other iRise Links

• iRise Website – www.irise.com• iRise Blog – www.irise.com/blog• Product Tour -

www.irise.com/products/2007_tours/index.php


In closing…always remember…

Quidquid latine dictum sit, altum sonatur.


In closing…always remember…

Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.


Business IT


Questions?

Tom [email protected]

[email protected]


Thank you!