Requirement Engineering within an Agile Environment...• A Scrum epic is a large user story....

Requirement Engineering within an Agile EnvironmentBY KEJI GIWA

DBT Requirement Engineering Process

Epic / User Stories – Product Planning

Sprint

Planning

Initial User Journey & Mockups

BDD / Gherkin Syntax

Business Rules

Logical Process Flow

Functionalities

Non Functional Requirements

Wireframes

Keyscreens

Implement

Release

HLR Workshop

Requirement Catalogue

Use Case

VersionRelease

QA(Components,

Integration, System)

Back End Development

Software RequirementSpecification

User Story

User Journey

(Wireframes, Key screens)

Phase 1Core Functionality

Phase 2

Improved Functionality

Phase 3Additional Functionality

Prioritisation

Analysis

Test PlanTest Cases

Customer AcceptanceCriteria &

Expectations

Usability Validation

Usability Evaluation & GUI

FunctionalityCross Browser

TestingCross App Testing

Performance Testing

GUI TestingBrand Guidelines

Scrum & Agile Development

U S 1FiF2F3

AGILE DEVELOPMENT PROCESS

User Story 8

User Story 7

User Story 6

User Story 5

User Story 4

User Story 3

User Story 2

User Story 1

Deliverables 1

Deliverables 2

Collaborative Requirement Gathering

Justify / Translate /

Adjust

Prioritise

Translate

Communicate

1. JUSTIFY, Translate & Adjust

Gathering High Level RequirementsEverything is

BeneficialUndefined

Scope of Work

Stakeholder Analysis

Investigating Situation

• Three stages– Qualitative investigation

• Interviewing

• Workshops

• Observation

– Quantitative investigation

– Documenting results

Requirement Gathering – Agile

Collaborative Requirement Workshops

Daily Scrum Meetings

Requirement Workshop

• key stakeholders including SME

• Requirement gathering

• Prioritising requirements

• Estimating & costing

• Review

From the Business Case• Deliverables

– Must

– Should

– Could

– Out of Scope

– Business rules

User Led Questionnaires Why

Product

Service

Business Rules

Technology

Expertise

Relevance

Process

Resource

In house

Off shore

Target Market

Online

Mobile

Timeframe

Tolerance

Deadline

Merchant

Customer

Payment gateway

Questioning Techniques

• Open Questions

– What, where, how, when, why

• Fact Finding

– Precisely, exactly, elaborate, expand

• Closed Questions

– Yes / No

Bottom Line

Limited Time

Limited Budget

Limited Cost

Limited resources

Prioritise Must - IBVShould - MBVCould - LBVWon’t - NBV

Bigger Picture

Using Spin to ask Qualifying Questions

•Why have you chosen this platform

•What made you decide to invest in…

•Where did the inspiration come from and what are you trying to achieve?

•What’s your overall budget and timeline for this project?

Situation

•What are the current drawbacks….

•What have you found challenging when identifying your core user needs and requirements…

Problem

•In an event that x does not happen what impact will that have on the overall business value?

•If we are unable to complete x and y by this date what implications would it have?

Implication

•If we could deliver a fully functional system and meet the overall business value while avoiding the challenges mentioned and certainly avoiding the possible implications, how will that make you feel?

•What are the key requirements that we need to implement and by what date to avoid ……

Need Pay Off

Focus Groups

• Focus groups helps us identify our target market and establish usability requirements, user experience and potential prototyping– What would you use the system for?– How would you like to use the system?– How would you like to relate with the system?– What functionalities do you expect from the system

(must, should, could, doesn’t matter)?

Target Audience• Mobile users (iphone / adroid)• Use smartphones• Users native apps

– Needs• Convenience• Short burst activities / on the go tasks• Busy lifestyles

– Want– Don’t Mind– Don’t Want

• Blackberry• Windows • Not web based

Target Audience - Enquirers• What are the kind of things I used my mobile phone for?

– Communication– Search for information (both local and global)– Social networking

• What are the apps I use the most• Why do I use those apps• What are the apps I don’t use often

– Why

• What are the apps I don’t use at all– Why

• When I do use any of the above– What do I use them for– How long do I spend using them– What are my expectations when using such apps

Target Audience - Enquirers

• If you had a magic wand, what are the 5 apps you would want and what would you use them for

• How often would you use them– Need– Want– Don’t mind

• What are the best apps you use for interacting and socialising with friends / phone contacts– Why– Needs– Wants– Don’t mind

Target Audience - Enquirers

• Would you use an enquiry based app and Why– Need– Want– Don’t mind– Don’t want

• Would you consider an enquiry based app connected to your phone contacts– Need– Want– Don’t mind– Don’t want

2. PRIORITISE

Getting it right the first time!Quality

In Scope

Customer Acceptance

Criteria

Business

Critical – Must Have

Quality Expectation

Mid Term –Should Have

Long Term – Could Have

Not in Scope

Won’t Have

Options ChoicesStreamline & prioritise client options

Then give them choices

Establishing Business Values based on:• What are the immediate (important and urgent) business

critical requirements based on allocated time, budget and resources – This defines the must have criteria for the scope of the project

Immediate business critical requirements

• What are the short term (not important but urgent or urgent but not important) business requirements based on allocated time, budget and resources – This defines the should have criteria for the scope of the project

Short term business critical requirements

• What are the long term (nice to have’s not important and not urgent) business requirements based on allocated time, budget and resources – This defines the could have criteria for the scope of the project

Long term business critical requirements

Specific Measurable Achievable RealisticTime

Using MOSCOW to Prioritise Requirements

Based on Overall Business Value

How much time, budget, resources do we have to achieve x?

Requirement Questionnaires

•Urgent & Important – Business Critical Requirements in order to establish immediate business value based on allocated budget, timeframe and resources.

Must Have

•Not Urgent & But Important or Urgent but Not Important –Business Requirements in order to establish short term business value based on allocated budget, timeframe and resources.

Should Have

•Nice to have’s– Business Requirements in order to establish long term business value based on allocated budget, timeline and resources.

Could Have

•Out of Scope! Not going to implement within the allocated budget, timeframe and resources available.Won’t Have

Must / BV

End User Needs

Should / BV

End User Wants

Could / BV

End User Don’t Mind

Won’t / BV

End User Don’t Want

User Led & Value Based DevelopmentEnd user requirements based on business value (BV)

Prioritising Requirements using MOSCOW

InputBottom

LineBigger Picture

Business Value

Business Needs / Success Criteria

Opinions

End User / Use Led

User Requirements

Don’t Want

Don’t Mind

Needs Based Analysis using MOSCOW

Must HaveImportant & Urgent

Should Have

Not Urgent But Important

Urgent But Not Important

Could HaveNot Urgent / Not Important

(Nice to Have)

Won’t HaveNot in Scope

Business Critical Requirements

Time, Budget, Resources / Benefits

Quality AssuranceCustomer

Acceptance Criteria

Budget

Benefit

Resources

Customer Expectation

budget

Benefit

Resources

Defines the scope of the project

Defining the Scope of the Project

Acceptance Criteria

Must be implemented within the allocated time,

budget and resources

Quality Expectations

Should

Only to be implemented if there is spare time,

budget or resources from allocation

Only to be implemented if allocated time, budget or

resources can be extended

Not In Scope

Won’t

Will not be implemented within

the scope of work

Project Management

Benefit & Business Value

In Scope

Resources

Changes

QualityAcceptance

CriteriaQuality

Expectation

Gathering High Level RequirementsPrioritised Benefits

In Scope

Resources

Budget

Quality & Risk

Phased release Development

Business Value

Immediate Business Critical Needs

Allocated Cost

Phased Released Development•Version 1: Immediate Business Critical Requirements

•Must Have’s

•Core Functionalities Phase 1

•Version 2: Mid Term Business Critical Requirements

•Important But Not Urgent / Urgent But Not Important

•Improve on Existing Functionalities / Add Should / Could Have’s Phase 2

•Version 3: Long Term Business Critical Requirements

•Nice to have’s

•Additional Functionalities – Must Be Pushed Out of Scope Based for Phase 1and Phase 2!

Phase 3

3. TRANSLATE

TranslationHigh Level

Requirement Gathering

Translation Process

Analysis

• Use Case, ERD, Logical Process Flow

• Breakdown Structure

• User Stories > User Journey > Requirement Specification

Design

• Wireframes

• Key screens

Implement

• Sprint Planning Process

• Sprints

• Test Plan

• Test Case

Requirement Specification

User Story & User Journeys

Functions / Features

Tasks / Sub Tasks Task Descriptions

Proposition Risks and Mitigating

Actions

Branding Illustrations /

Guidelines

Business Rules

• key stakeholders including SME

• Requirement gathering

• Prioritising requirements

• Estimating & costing

• Review

Req id Requirement Priority Success Criteria Dependency

Use Cases

• Visual representation of the interaction between the user and the system

Epic Stories

• A collection of user stories.

• A Scrum epic is a large user story. There's no magic threshold at which we call a particular story an epic. It just means “big user story.”

• Epic – The Movie – Animated –action packed adventure for the family.

User Centred Development…

User-Led Requirement Gathering• Story boarding

• User Stories

The User (Entities)

Thinking like a usability Expert

The User

Performance Issues

Individuals / GorupsInvolved

Task Relation / Sequence

UI Influences

Thought Pattern

• How does the user know what to do next?

• How will the user connect the description of the action to he/she is trying to do?

• On the basis of the system response – will the user know if he has made the wrong or right choice?

User Stories

• A user story is simply what a user wants.

• The story of how the user will perform a particular action to get an expected result

User Centred Design within an Agile Environment• Usability is King!

• Adaptability

• Flexibility

• Embracing change within controlled environment

• Involving the users and the client

• Cross functional team

• Constant collaboration

• Developing and deploying applications on an iterative and incremental basis

User-Led Requirement Gathering• Story boarding

• User Stories

User-Led Requirement Gathering

Examples

Let’s elaborate more…

User-Led Requirement Gathering

User stories and Gherkin

• The type of user (or role) and the goal are mandatory. The reason field is optional if the reason is indeed obvious.

• To create a useful user story, one of the best practices is to ensure that it will consider the INVEST principles.

• A user story should:– be Independent– be Negotiable– be Valuable– be Estimable– be Small– have Tests

Gherkin Syntax

• Given that.... Have forgiven me

• When... I call you

• Then... You should pick up my calls

Data Validation & Verification

System Messages – User Actions

User-Led Requirement Gathering• As a (role) I want to (activity) so that I

can (reason)

– Conditions

– Events

– Outcome

Functionalities

– Tasks 1

1. Task 2

» Sub Tasks

Success CriteriaAcceptance

Criteria

Expected Results

Actual Results

Flow Chart

Flow charts are from the top downLogical explanation ofUser Stories, functionalitiesUse cases and class diagrams

Entity Relationship Diagram

Story Boarding – Development Process

Examples

Functional Requirements

• Do you remember this?

Non Functional Requirements

• Things you don’t physically see but needs to be in place to conveniently and safely use the application

Wireframes

• Visual sketch of how what the application will look like – buttons, tabs, icons, images etc

Wireframes

page schematic or screen blueprint. Visual guide that represents the skeletal framework of a website

Keyscreens

• Actual key design templates that all other pages / screens will be built on

4. COMMUNITCATE & ADJUST

Embracing Change Within a Controlled Environment

Business Benefit / Business Case

Project Issues

Change Request

Off Specification

Concern

Embracing Change within the Scope of Work.

FLEXIBLE

ADAPTABLE

InputBottom

LineBigger Picture

Business Value

Success Criteria

Opinions

Use LedUser

Requirements

Don’t Want

Don’t Mind

Resolving conflict & avoiding scope creep

Requirement Engineering within an Agile Environment...• A Scrum epic is a large user story....

Documents

Transcript of Requirement Engineering within an Agile Environment...• A Scrum epic is a large user story....

The Epic Enterprise DevOps Story

Adbusters #107 - The Epic Story of Humanity (PREVIEW)

The Beginning of English Literature A Heroic Epic Epic- a quest story on a grand scale Heroic Epic Poetry - narrative poems that stress the battle between.

The Odyssey an Epic By: Homer. Characteristics of an Epic An epic is a long narrative poem presenting characters of high importance; adventure story;

The Roman World: An Epic Story

Degrelle, Léon - The Epic Story of the Waffen SS

The Epic of Gilgamesh The oldest story ever recorded.

The epic story of Skyscanner's service desk

If the Plane Doesn't Crash There's No Story

THE MOST EPIC STORY EVER TOLD MARK 1

Introduction: The Bible as Epic Drama (Grand Story)

The Babylonian Story of the Deluge and the Epic of Gilgamish

Ever Told! Most Epic Story The

Beowulf The Epic. What is Beowulf? Epic: a long poem telling a story about a hero and his exploits. Components of an epic: legendary figure actions on.

epic story - wisesloth.files.wordpress.com

EPIC AND EPIC HEROES - Wilson's English I Websitecshswilson.weebly.com/uploads/8/6/5/8/86588250/epic... · 2018. 9. 5. · A long story in poem form An epic has a hero. The epic is

NetApp Epic Story: Orange Business Services

ENVIRONMENT story STORYTELLING telling | ENVIRONMENTjourneyoc.com/.../HomeFront_Monthly_Storytelling_.pdf · STORYTELLING God’s story is epic. It encompasses all of history and

Babylonian Story of the Deluge and the Epic of Gilgamish

Where there's community, there's home