Requirement Engineering within an Agile Environment BY KEJI GIWA
HLR Workshop Requirement Catalogue Product Planning Sprint Planning Meeting Keyscreens Use Case / Epic Stories Implement Wireframes DBT Requirement User Stories Engineering Process Test Non Functional Req Mockups Release Functionalities / DFD Business Rules BDD / Gherkin Syntax
Collaborative Requirement Gathering Justify / Translate / Adjust Communicate Prioritise Translate
1. JUSTIFY, Translate & Adjust
Gathering High Level Requirements Everything is Beneficial Undefined Scope of Work
Stakeholder Analysis
Investigating Situation Three stages Qualitative investigation Interviewing Workshops Observation Quantitative investigation Documenting results
Requirement Gathering Agile Collaborative Requirement Workshops UAT Daily Scrum Meetings
Requirement Workshop key stakeholders including SME Requirement gathering Prioritising requirements Estimating & costing Review
From the Business Case Existing system Draw back of the existing system Other Options & Related Systems Proposed system Draw Backs & Reason for the proposed system Industry Research, Trends & Predictions Competitive Analysis SWOT Analysis GAP Analysis Recommendations & improvement CBA
User Led Questionnaires Why If What How Where When Who Product Technology Resource Target Market Timeframe Merchant Service Expertise In house Online Tolerance Customer Business Rules Relevance Off shore Mobile Deadline Payment gateway Process
Questioning Techniques Open Questions What, where, how, when, why Fact Finding Precisely, exactly, elaborate, expand Closed Questions Yes / No
Bottom line Bigger Picture Limited Time Limited Budget Limited Cost Limited resources Prioritise Must Should Could Won t
Using Spin to ask Qualifying Questions Situation 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? Problem What are the current drawbacks. What have you found challenging when identifying your core user needs and requirements Implication 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? Need Pay Off 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
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)?
Req id Requirement Priority Success Criteria Dependency
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 Streamline & prioritise client options Options Choices Then give them choices In Scope Not in Scope Customer Acceptance Criteria Quality Expectation Won t Have Business Critical Must Have Mid Term Should Have Long Term Could Have
Establishing Business Values based on: Immediate business critical requirements 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 Short term 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 Long 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
SMART Specific Measurable Achievable Realistic Time Bound
Using MOSCOW to Prioritise Requirements Based on Overall Business Value How much time, budget, resources do we have to achieve x?
Requirement Questionnaires Must Have Urgent & Important Business Critical Requirements in order to establish immediate business value based on allocated budget, timeframe and resources. Should 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. Could Have Nice to have s Business Requirements in order to establish long term business value based on allocated budget, timeline and resources. Won t Have Out of Scope! Not going to implement within the allocated budget, timeframe and resources available.
User Led & Value Based Development End user requirements based on business value (BV) Must / BV Should / BV Could / BV Won t / BV End User Needs End User Wants End User Don t Mind End User Don t Want
Prioritising Requirements using MOSCOW Bigger Picture Bottom Line Input Business Needs / Success Criteria Opinions Facts Business Value Need End User / Use Led User Requirements Want Don t Want Don t Mind
Needs Based Analysis using MOSCOW Must Have Important & Urgent Should Have Not Urgent But Important Urgent But Not Important Business Critical Requirements Time, Budget, Resources / Benefits Could Have Not Urgent / Not Important (Nice to Have) Won t Have Not in Scope
Quality Assurance Customer Acceptance Criteria Customer Expectation Time Time Budget budget Defines the scope of the project Benefit Benefit Resources Resources
Defining the Scope of the Project Acceptance Criteria Scope Quality Expectations Not In Scope Won t Must Should Could Will not be implemented within the scope of work Must be implemented within the allocated time, budget and resources 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
Project Management Benefit & Business Value Time In Scope Cost Risks Resources Changes Quality Acceptance Criteria Quality Expectation
Gathering High Level Requirements Prioritised Benefits In Scope Allocated Cost Quality & Risk Immediate Business Critical Needs Budget Business Value Time Phased release Development Resources
Phased Released Development Phase 1 Version 1: Immediate Business Critical Requirements Must Have s Core Functionalities Phase 2 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 3 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!
AGILE DEVELOPMENT PROCESS User Story 1 User Story 2 User Story 3 U S 1 Fi F2 F3 User Story 4 User Story 5 User Story 6 User Story 7 User Story 8 Deliverables 2 Deliverables 1
GUI Testing Brand Guidelines 3 Usability Evaluation & GUI User Journey (Wireframes, Key screens) 4 Customer Acceptance Criteria & Expectations 2 User Story Prioritisation Phase 1 Core Functionality Software Requirement Specification Test Plan Test Cases GUI Testing Brand Guidelines 5 1 Analysis Phase 2 Improved Functionality Back End Development Phase 3 Additional Functionality 8 Version Release QA (Components, Integration, System) 6 Usability Validation UAT 7 Functionality Cross Browser Testing Cross App Testing Performance Testing
3. TRANSLATE
Translation High 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
User-Led Requirement Gathering Story boarding User Stories
The User (Entities)
Thinking like a usability Expert
The User Individuals / Gorups Involved UI Influences Task Relation / Sequence Performance Issues
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?
Scrum & Agile Development
Requirement Specification User Story & User Journeys Functions / Features Proposition Risks and Mitigating Actions Tasks / Sub Tasks Task Descriptions Branding Illustrations / Guidelines
Requirement Catalogue key stakeholders including SME Requirement gathering Prioritising requirements Estimating & costing Review
Use Cases Visual representation of the interaction between the user and the system
User Centred Development
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 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 Usability is King! Adaptability Flexibility Environment 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
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 Criteria Acceptance Criteria Expected Results Actual Results
Story Boarding Development Process
Examples
Flow Chart Flow charts are from the top down Logical explanation of User Stories, functionalities Use cases and class diagrams
Entity Relationship Diagram
Functional Requirements Do you remember this?
Business Rules
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
Embracing Change within the Scope of Work. Project Issues Change Request FLEXIBLE Off Specification ADAPTABLE Concern
Resolving conflict & avoiding scope creep Bigger Picture Bottom Line Input Success Criteria Opinions Facts Business Value Need Use Led User Requirements Want Don t Want Don t Mind