What It Means to Be a QBA: Quality Business Analyst Cody May, Business Analysis Practice Director © 2018 Key Learning Objectives

Home , Business analyst, Quality (business)

BA-CON Columbus, OH August 29, 2018

1. Learn how to recognize symptoms of inadequate Business Analysis / Requirements Engineering practices that result in low-quality systems

2. Learn tactics and techniques for maximizing quality and reducing errors in requirements for your projects and systems

3. Learn techniques for evaluating requirements quality in both iterative (Agile) and sequential (Waterfall) environments

Business Analysis Practice Director • Responsible for delivery of BA services in the U.S., inc’l employee onboarding / training, opportunity qualification, engagement oversight • Onsite in major Midwest markets, delivery center in Lexington, KY • BA Community of Practice (CoP) co-champion Principal Business Analyst • Experience in a variety of industries including Retail, Logistics, Insurance, Financial, Health & Fitness, Nonprofit, Pharmaceutical, Government, Manufacturing • Experience across a variety of project types, SDLC methodologies, and roles

IIBA Involvement since 2014 • Bluegrass (KY), Birmingham (AL), Chicago

Certifications • CBAP (2016) • CPRE-FL from IREB (2017)

Our mission SQS is Transforming the World Through Quality Our vision SQS is the global leader accelerating agility and performance through world class quality

• Industries: Auto & Manufacturing, BFSI, Retail, Healthcare, Aerospace & Defense, Energy & Utilities, Non-profits • In the U.S., 200 employees nationally with offices in Lexington (KY), Chicago, Milwaukee, Minneapolis • Three core focus areas: • Business Agility – The ability for organizations to respond and be adaptable to changing external conditions; Lean/Agile mindset & Org Effectiveness • Management Consulting – Focused on capabilities that drive high value strategic and operational improvements; including PM/PPM, Biz Arch, BA • Continuous Quality – Software quality and QA/QE, with a focus on quality strategy and management, test automation, predictive quality & testing

Rationale & Common Scenarios • Why do we need the QBA role?

Three Principles for a Quality Business Analyst • Suggested techniques & examples by BABOK Knowledge Area

An eye to the future

© 2018 Trissential LLC – An entity of SQS Group | 7 Quality starts with Requirements SQS Experience Typical Defect Distribution on project with no – 70% of errors are introduced formal Business Analysis presence 45 during the early analysis and 40% 40% 40 design phases, but typically only 35 30% 30% 30 25% 25% 10% are found and corrected at 25 20 that stage 15 10 5% 5% 5 – The cost of fixing an error in the 0 Analysis Design Imple- Testing/ Deployment mentation Acceptance final deployment phase is 90x Typical distribution of error sources the cost of fixing it in the Typical distribution of the discovered errors analysis phase, and 22x the cost Defects are introduced early... of fixing it in the design stage. but discovered late Source: SQS Empirical Data from 5.000 projects Prevent the defects early = save money & time

• Defects introduced at the requirements and design stages • Requirements signed-off by the business, but not enough detail for development and test teams – leads to ambiguity and rework • Requirements not signed-off by development and test teams • Offshore or outsourced projects rely on inadequate documentation • Defects not detected/removed until later stages in the SDLC: • System / Integration Testing • Acceptance Testing (UAT) • Project expends time/effort fixing issues or doing rework • Very rarely are requirements documents or solution designs subject to any rigorous process of review or testing • On an Agile/Scrum project, the team discovers a new status is needed: “Done Done”

A Quality Business Analyst (QBA) is someone who performs IIBA-defined business analysis activities with an extreme focus on: (1) injecting quality and (2) eliminating errors and waste, in the earliest possible stages.

What does this mean, practically speaking? Treat requirements as a product & apply same rigor to their creation

3 Principles 1. Requirements validation (ensuring the business need is being met) is paramount

2. Remember your audience when developing requirements

3. Objective measures of quality should serve as a Q-Gate prior to implementation

How can we reduce gaps between true customer needs and stated requirements to prevent guesswork and rework?

Requirement Faults

Relationship between two Single Requirement or more Requirements

• Missing Requirement

• Ambiguous Requirement • Inconsistent Requirements • Incorrect Requirement • Redundant Requirements • Incomplete Requirement

• Mistakable Requirement

Source: Oral Avci: Aus Fehlern in der Softwareentwicklung lernen. Anforderungsanalyse und Qualitätssicherung mit Fehleranalysen verbessern. Saarbrücken 2008.

Courtesy Christer Fröling

1) Kano Model for classifying and analyzing customer satisfaction • Serves as a tool for risk mitigation

2) Identifying and eliminating “language effects” present in stakeholder requirements • Hints from linguistics and psychology

3) Bring along QA stakeholders to elicitation sessions

Goal: eliminate ambiguity and errors at the source

© 2018 Trissential LLC – An entity of SQS Group | 15 QBA Principle 1: Early Validation The Kano Model: Customer Satisfaction vs Features Degree of very • Basic Factors are system satisfied characteristics that are implicitly Satisfaction expected and taken for granted (subconscious knowledge).

• Performance Factors are system characteristics that are explicitly Degree of requested (conscious knowledge). Fulfillment totally complete • Excitement Factors are system insufficient characteristics unknown to the stakeholders. They are discovered during usage as pleasant and Basic Factors useful surprises. (unconscious Performance Factors knowledge). Excitement Factors very dissatisfied

• Perceptional transformations occur because every person perceives reality differently and forms his or her own an individual picture. • Descriptional transformations occur as soon as a person puts personal knowledge (this picture) into words.

Personal Perception Personal Knowledge

Perception Description

Defects? Defects?

Reality Personal Knowledge put into Words

• A process is reduced to an event. Nominalization • Information relevant to the process is deleted.

• Vague nouns Nouns without reference index • Additional information is necessary. • Summarize a set of objects as a group Universal quantifiers • Make a statement about the behavior of the entire group

Incompletely specified • Conditional behavior: It remains unspecified conditions what should happen if a condition is not met.

Incompletely specified process • Some process words require more than a noun words to be completely specified.

Are all appropriate perspectives represented within the req’ts?

Business User System

Executive Stakeholders; End Users Technical SMEs Sponsors Vendor Application(s) App Owners Documents Existing

Sources QA, BSA Customers systems/products

Use Cases Functional Req’ts Business Requirements Non-Functional Req’ts User Stories BP/Value Flows Acceptance Criteria Cust journey maps Artifacts UML diagrams

1) Using a sentence templates and/or user personas to maximize clarity

2) Hybrid documentation: natural language & models / prototypes • Traditional shall statements or user stories • UML, SySML, or lightweight diagramming techniques to depict perspectives: o Functional o Data o Behavioral

Goal: eliminate gaps in requirements, identify conflicts early

IREB definition: • A sentence template is a construction plan for the syntactic structure of a single requirement (written in natural language / prose)

Step 3: • Independent system activity: System carries out the process independently. • User interaction: System provides the user with process functionality • Interface requirement: System performs the process subject to a third party waiting for an external event.

Step 5: insert conditional statement, if applicable • Temporal: “When” • Logical: “If”

Step 5: Temporal or Logical Condition

Stand-alone system activity with temporal condition: When a guest accepts the reservation via the mobile app, the system shall trigger the check-in process for the hotel room.

User interaction: The system shall provide the user the ability to set a wake-up alarm.

Interface requirement with logical condition: If a guest wants to charge the bill to his or her account, the system shall be able to receive confirmation data from the banking system.

What about Agile: User Stories? The same elements exist in user stories / acceptance criteria constructed using: As a I want , so that Given , when , then

Data Perspective Functional Behavioral (e.g., UML Class) Perspective (e.g., Perspective (e.g., UML Activity) Statechart)

Natural Language (Prose) Requirements to support all perspectives

Natural Language: “When a guest accepts the reservation via the mobile app, the system shall trigger the check-in process for the hotel room.”

Data Perspective: • Leverage ERD to show data type, attributes, entities and cardinality/relationships of the entities: Guest, Room, Reservation

Functional Perspective: • Construct use cases and UML activity diagrams to show detailed actions, conditions and options of a goal-oriented workflow: the hotel room check-in process (from a customer perspective and hotel employee perspective)

State Perspective: • UML State diagram will show how and when the system reacts to incoming stimuli, and the system or sub-system changes states (e.g., to “Checked In”)

Are the requirements of a sufficiently level of quality to move into development?

Requirements take many forms • Traditional “shall” statements written in natural language, à la IEEE 610 and IEEE 29148 • Ivar Jacobsonian Use Cases • Diagrams and Models, e.g., ERD, Data Flow, Fishbone, Class diagram, Activity diagram, BPMN • User stories, typically “as a I want to so that ”. • Acceptance criteria, which often accompany a user story, e.g., in the Gherkin format of “given , when , then ” • Test strategies, plans, and results • Defect or bug descriptions • Existing constraints, such as operational conditions, IT architecture and interfaces to adjacent systems; or even organizational constraints/mandates • Norms and standards from regulatory authorities such as HIPAA, SOX, FAR/DFARS, UL, GDPR etc. • An email, verbal conversation, or scratch paper/napkin • Public knowledge: annual reports, letters to shareholders, public opinion, legislation • Customer reports: Twitter DMs, App store reviews, emails, interviews • ….

1) Utilize standards/norms such as IEEE 830 (29148), ISO 25010, BABOK, DoR, etc… • Establish requirements quality baseline • Quality Gate

2) Adjust RM tool appropriately • Attribute definition: statusing, versioning • Traceability scheme

Goal: eliminate possibility for misinterpretation of requirements & establish a quality baseline

• Measure and certify that the requirements offer a sufficiently acceptable and complete description of the business needs • Certify the decision to proceed with system development activities. Best Practice for Requirements: The 8 IEEE and IIBA recommendations for • Completeness and consistency Software Requirements: • Conformance to IEEE 830 and 29148 1. Correct (Adequate) standards and IIBA BABOK 2. Unambiguous • No requirements conflicts 3. Complete • No technical errors 4. Consistent • Non-ambiguous requirements 5. Verifiable 6. Modifiable 7. Traceable 8. Prioritized

These 8 criteria can be weighted based on collaborative discussions with stakeholders, and can be augmented to include additional quality criteria based on product/industry.

Criterion Quality Score # Req'ts Defects Correctness 48.0% 13 Unambiguous 43.3% 17 Completeness 60.0% 6 Consistency 60.0% 6 Verifiability 40.0% 9 Modifiability 40.0% 3 Traceability 60.0% 6 Prioritized 80.0% 1

Requirements should cover Product Quality characteristics the following areas: • Efficiency (Performance) • Compatibility • Usability • Reliability • Security • Maintainability • Portability

Defining verifiable requirements • Quantify  Metrics • Operationalize  Derive functions

ISO 25010 PQ: static internal measures QIU: degree to which product Meets user needs/goals

Sound user stories comply with INVEST, while backlogs adhere to DEEP: I ndependent D etailed appropriately N egotiable E stimated V aluable E mergent E stimatable P rioritized S mall T estable

Definition of Ready (DoR) answers the question “when is a user story ready for a Sprint?” • Acceptance tests complete • Estimates for complexity / effort • Constraints & Dependencies defined • “Just Enough” models have been developed (e.g., mockup, prototype)

RM Tools can enable QBA principles via configuration • Attribute scheme, e.g., status • Traceability • Versioning & Configuration management • Audiencing (views)

Caveat: RM Tools don’t replace human beings! • People > Processes > Tools

Strategy Analysis • BA’s must have a systems perspective (see SAFe) • Know the context & culture of proposed change to reach a defined future state • Still a component of validation and verification

Solution Evaluation • Ask quality stakeholders! • Balance quantitative and qualitative measures of solution's performance

BA Planning and Monitoring • What is our Quality strategy? • How do we measure quality? e.g., customize RM tool for attribute scheme and use ISO 25010 for NFR capture • How does our organization define and mitigate risk?  requirements prioritization strategy

NASA: • On average projects invest 2% to 3% of their total cost (over the whole life cycle) in requirements phase. • Projects with less than 5% investment in requirements exceed their budget by 80% to 200%. • Projects investing between 8% and 14% do not exceed their budget by more than 60%

Source: Young, 2001

Three Principles (of many!) for QBA’s: • Early validation to sanitize incoming requirements • Represent all possible perspectives in analysis and documentation to eliminate gaps • Operationalize quality with a requirements baseline metric in order to certify implementation readiness

Digital trends underscore the importance of quality in analysis: • Increasing complexity and speed to market • Heightened customer expectations, ex. privacy concerns • Needs for regulation & compliance • Interconnectedness / IoT • Cloud, SaaS & additional integrations with partners / vendors

Digital User Open Experience Source

Cyber Smart Mobility

With a laser-focus Business on quality, we enable Regulation Agility our clients to manage & Compliance business and IT change with confidence.

Digital & Internet Intelligent of Things Automation

Continuous Integration/ Cloud Continuous Development

Omni Channel & Mobile

Cody May Business Analysis Practice Director Further Reading https://www.pmi.org/learning/library/poor-requirements-management-source-failed- projects-9341 https://www.informationweek.com/strategic-cio/enterprise-agility/how-to-avoid- technical-success-business-failure/a/d-id/1316409 https://www.microtool.de/en/knowledge-base/what-is-the-kano-model/ SOPHIST Requirements Engineering Primer document https://www.jamasoftware.com/resource/writing-high-quality-requirements/ http://www.ireb.org http://www.processimpact.com/articles/qualreqs.pdf https://www.nasa.gov/offices/oce/functions/lessons/index.html