Requirement Engineering within an Agile Environment BY KEJI GIWA. Digital Bananas Technology

Transcription

1 Requirement Engineering within an Agile Environment BY KEJI GIWA

2 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

3 Collaborative Requirement Gathering Justify / Translate / Adjust Communicate Prioritise Translate

4 1. JUSTIFY, Translate & Adjust

5 Gathering High Level Requirements Everything is Beneficial Undefined Scope of Work

6

7

8

9 Stakeholder Analysis

10 Investigating Situation Three stages Qualitative investigation Interviewing Workshops Observation Quantitative investigation Documenting results

11 Requirement Gathering Agile Collaborative Requirement Workshops UAT Daily Scrum Meetings

12 Requirement Workshop key stakeholders including SME Requirement gathering Prioritising requirements Estimating & costing Review

13 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

14 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

15 Questioning Techniques Open Questions What, where, how, when, why Fact Finding Precisely, exactly, elaborate, expand Closed Questions Yes / No

16 Bottom line Bigger Picture Limited Time Limited Budget Limited Cost Limited resources Prioritise Must Should Could Won t

17 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

18 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)?

19 Req id Requirement Priority Success Criteria Dependency

20 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

21 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

22 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

23 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

24 2. PRIORITISE

25 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

26 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

27 SMART Specific Measurable Achievable Realistic Time Bound

28 Using MOSCOW to Prioritise Requirements Based on Overall Business Value How much time, budget, resources do we have to achieve x?

29 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.

30 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

31 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

32 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

33 Quality Assurance Customer Acceptance Criteria Customer Expectation Time Time Budget budget Defines the scope of the project Benefit Benefit Resources Resources

34 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

35 Project Management Benefit & Business Value Time In Scope Cost Risks Resources Changes Quality Acceptance Criteria Quality Expectation

36 Gathering High Level Requirements Prioritised Benefits In Scope Allocated Cost Quality & Risk Immediate Business Critical Needs Budget Business Value Time Phased release Development Resources

37 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!

38 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

39 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

40 3. TRANSLATE

41 Translation High Level Requirement Gathering

42 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

43 User-Led Requirement Gathering Story boarding User Stories

44 The User (Entities)

45 Thinking like a usability Expert

46 The User Individuals / Gorups Involved UI Influences Task Relation / Sequence Performance Issues

47 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?

48 Scrum & Agile Development

49 Requirement Specification User Story & User Journeys Functions / Features Proposition Risks and Mitigating Actions Tasks / Sub Tasks Task Descriptions Branding Illustrations / Guidelines

50 Requirement Catalogue key stakeholders including SME Requirement gathering Prioritising requirements Estimating & costing Review

51 Use Cases Visual representation of the interaction between the user and the system

52 User Centred Development

53 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.

54 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

55 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

56 User-Led Requirement Gathering Story boarding User Stories

57 User-Led Requirement Gathering

58 Examples

59 Examples

60 Let s elaborate more

61 User-Led Requirement Gathering

62 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

63 Gherkin Syntax Given that... Have forgiven me When... I call you Then... You should pick up my calls

64 Data Validation & Verification

65 System Messages User Actions

66 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

67 Success Criteria Acceptance Criteria Expected Results Actual Results

68 Story Boarding Development Process

69 Examples

70 Flow Chart Flow charts are from the top down Logical explanation of User Stories, functionalities Use cases and class diagrams

71 Entity Relationship Diagram

72 Functional Requirements Do you remember this?

73 Business Rules

74 Non Functional Requirements Things you don t physically see but needs to be in place to conveniently and safely use the application

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

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

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

78 4. COMMUNITCATE & ADJUST

79 Embracing Change Within a Controlled Environment Business Benefit / Business Case

80 Embracing Change within the Scope of Work. Project Issues Change Request FLEXIBLE Off Specification ADAPTABLE Concern

81 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

82