requirement engineering within an agile environment...• a scrum epic is a large user story....

© Digital Bananas Technology

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

Final

Wireframes

Keyscreens

Implement

Test

Release

HLR Workshop

Requirement Catalogue

Use Case


VersionRelease

UAT

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

1

2

3

4

5

6

7

8

Customer AcceptanceCriteria &

Expectations

Usability Validation

Usability Evaluation & GUI

FunctionalityCross Browser

TestingCross App Testing

Performance Testing

GUI TestingBrand Guidelines

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

UAT


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

What

Product

Service

Business Rules

How

Technology

Expertise

Relevance

Process

Where

Resource

In house

Off shore

Target Market

Online

Mobile

When

Timeframe

Tolerance

Deadline

Who

Merchant

Customer

Payment gateway

If


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


SMART

Specific Measurable Achievable RealisticTime

Bound


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

Facts

End User / Use Led

User Requirements

Need

Want

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

Time

Budget

Benefit

Resources

Customer Expectation

Time

budget

Benefit

Resources

Defines the scope of the project


Defining the Scope of the Project

Scope

Acceptance Criteria

Must

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

Could

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

Time

Cost

In Scope

Risks

Resources

Changes

QualityAcceptance

CriteriaQuality

Expectation


Gathering High Level RequirementsPrioritised Benefits

In Scope

Resources

Time

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

• 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

Facts

Use LedUser

Requirements

Need

Want

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