Eliciting and Elaborating Requirements with Developers in Mind. TODAY S MOTTO: If you wanted it yesterday, why didn t you wait until tomorrow to ask?

Transcription

1 Eliciting and Elaborating Requirements with Developers in Mind TODAY S MOTTO: If you wanted it yesterday, why didn t you wait until tomorrow to ask?

2 in advance Thank you for your participation! David De Witt, IT Leadership Practice Director NueVista Group Oak Brook IL

3 Today s Objectives Review how the requirements package feeds the developer s work process. Describe how to expand the elicitation process to constructively include developers. Introduce some factoring techniques that will improve the requirements detail level for developers.

4 Requirements Factoring Themes User Functional Solution Constraints Other Problem Decomposition Actionable problem statement(s) Functions Processes Affected Systems Affected Roles Data Stakeholder needs Solution Boundaries Deadlines Controls Cost limits Interim or permanent Evolution or big bang Local, regional, or global Process synchronization points Problem Context Business impacts Acceptable trade offs Potential changes for problem definition Influences Priority Audiences 4

5 Today s Agenda Introduction MindTuning Two Customers for the Requirements Package It isn t just the document Actionable requirements are essential Wrap Up and Questions

6

7 Has this happened to you? The project is delivered on time and within budget All requirements have been gathered The software has been designed, built, tested, and implemented based on requirements Sign offs were received at each point in the project IS says the project is a success But, the business doesn t agree!? How does IS (or the package vendor) often respond?

8 It works as designed. JoePhoto

9 How does everyone react? Why wasn t this caught in testing? We didn t have time to do it right. It wasn t in the signed off Requirements Document. What am I paying for if it won t do this? But we found a workaround!?

10 The Business - IS Challenge Business Too slow and expensive Don t understand what the business needs No sense of customer service Too bureaucratic Inflexible in their delivery process Speaks in tongues IS Wants everything for nothing, immediately Requirements are always changing Won t give us enough information Doesn t appreciate what IS takes; never satisfied Always wants the latest thing

11

12 12

13 How can we bridge this gap?

14 Today s Agenda Introduction MindTuning Two Customers for the Requirements Package It isn t just the document Actionable requirements are essential Wrap Up and Questions

15 MINDTUNING: The Eye Chart

16

17 reddit, ,acerbic_lemon

18

19

20

21 Investigation: What did you hear? For the next 5 minutes Walk around the room Ask as many other folks as you can: What [in your shop] is missing from Requirements from the Developer s Point of View? Then let s report back on what you heard

22 Biz - BA Developer Collaboration Challenge Business Stakeholder Business Analyst Developer Official US Navy Imagery

23 Today s Agenda Introduction MindTuning Two Customers for the Requirements Package It isn t just the document Actionable requirements are essential Wrap Up and Questions

24 Two main customers for Requirements Credit: boltron- 24

25 Relationships between Knowledge Areas Business Analysis Planning and Monitoring Elicitation Enterprise Analysis Solution Assessment and Validation Requirements Management and Communication Requirements Analysis Underlying Competencies BABOK Guide, Version 2.0, page 7

26 What is in your requirements package? Work Flows / Business Procedures Functional Decomposition Impact Analysis Security Rules Business Rules Field Edit Rules User Interface restrictions Non-functional requirements Wireframes User Stories Use Cases

27 Application Delivery Work Flow 27

28

29 Agile

30 Iterative

31 A Work Request Life Cycle Write up Work Request Create ballpark estimate Submit for *prioritization* More hurried! Work Queue T I M E P A S S E S T H I N G S C H A N G E Prepare design Code, test, accept Implement Where are requirements? H U R R Y!

32 Another Work Request Life Cycle Write up Work Request Initial Requirements Elaboration Develop Conceptual Design & Estimate(s) Submit for *prioritization* Work Queue T I M E P A S S E S T H I N G S C H A N G E Revisit Business Case Detailed Requirements Elaboration Prepare design Code, test, accept Implement H U R R Y!

33 Big Picture for the Business Credit: Liza

34 Big Picture for the Business What they said What they think they said What they meant What the requirements are when viewed as an enterprise capability What the requirement consequences could be NOT What it might take to do 34

35 Bite sized Pieces for Solution Provider 35

36 Chain Saw Context is worth 20 IQ points

37 Bite sized Pieces for Solution Provider Don t give the solution provider business requirements without making them actionable focus the problem statement But, avoid doing detailed design yet Functional requirements Functional specifications (aka DESIGN) 37

38 Don t Forget Non-Functional Requirements User Requirements aa Solution Constraints Imgur

39 How is your requirements package seen by your Developers? ThirdLegReviews naughty architect

40 Today s Agenda Introduction MindTuning Two Customers for the Requirements Package It isn t just the document Actionable requirements are essential Wrap Up and Questions

41 GO! A QUICK CONSIDERATION OF HOW TO INCLUDE DEVELOPERS IN REQUIREMENTS WORK WITHOUT CREATING CHAOS

42 Go! Background and Context 1. Developers want to BUILD solutions. They are good because they do that. They are also dangerous because they do that.

43 Go! Two Concerns Developers Have 1. Scope will not be defined sufficiently for design or scope will creep or scope will be technically impossible [given ] 2. Developers will be blamed for any unsatisfactory outcome

44 Go! Three Caveats for Earlier Inclusion 1. Developers start solutions [too] early because they always need more time. 2. Developers usually understand the business from application use only. Help Desk support is not the same as working in the field with the system. 3. Developers typically only receive bad news about the design and deployment.

45 Go! Four Opportunities for Inclusion 1. Include Developers during the AS IS discussion and expectation setting 2. Ask them what information they would like to have during the ballpark estimation phase 3. Ask Developers to help you prepare for Requirements Elicitation 4. Review normalized requirements with Developers for clarity and sanity

46 Go! What other inclusion opportunities do you see?

47 Today s Agenda Introduction MindTuning Two Customers for the Requirements Package It isn t just the document Actionable requirements are essential Wrap Up and Questions

48 Requirements Factoring David s Definition: The Process of refining requirements from high-level to detail-level is called Factoring. 48

49 Remember factoring in math?

50 Requirements Factoring Sometimes, you are adding details not present in the initial statement Sometimes you are clarifying at a detail level Sometimes you get rid of detail because it doesn t matter to the project. 50

51 Requirements Factoring Comparison: Functional Decomposition And Requirements Factoring 51

52 Factoring Example: By Stakeholder POV Must be user friendly The system will prompt user through all business steps supported by the system, including exceptions The system will work like the Google Advanced Search page The system will allow undo at each step during the process The system will be learnable after 2 hours of training 52

53 Requirements Factoring Focus the re-composition of requirements by looking at the following: Stakeholders Business priorities Areas that could produce the most critical errors Areas most likely to produce highly visible errors Areas most / least understood by you Most often used areas of an application system Areas hardest to repair when there is a problem Areas that require complex algorithms to build 53

54 Requirements Factoring Themes User Functional Solution Constraints Other Problem Decomposition Actionable problem statement(s) Functions Processes Affected Systems Affected Roles Data Stakeholder needs Solution Boundaries Deadlines Controls Cost limits Interim or permanent Evolution or big bang Local, regional, or global Process synchronization points Problem Context Business impacts Acceptable trade offs Potential changes for problem definition Influences Priority Audiences 54

55 Factoring Example The system will allow the user to skip steps in the order process that don t matter to a given order during entry. For example allow the user to skip a review of product families that aren t going to be included in the order. Factor by: Business Process Steps 55

56 Factoring Example Factoring: Allow user to choose relevant Product Families instead of forcing them to view all Product Family Lists. Allow user to skip credit check if they are removing line items. Allow the user to choose to prepopulate order with most frequently ordered items based on last three months of customer activity. 56

57 Factoring Example: Don t implement this project during a busy season for the business. Factoring Themes: By country By product family When IT is upgrading operating systems During another application roll out 57

58 Other FACTORING Factors? dlofink

59 What factors can we use with Developers in mind? Solution Constraints Other Non- Functional Requirements Clarifying the Context of Use from a system perspective Others?

60 Measure Definition Questions to Ask Quality Measures Cheat Sheet Complete All conditions of use or action are specified. Requirement as stated can be understood on its own. 1. What are the conditions for this requirement to apply? 2. What exceptions are there? Consistent Does not contradict other requirements or itself. 1. Is this in opposition to other requirements? 2. Does this overlap or restate other requirements? Correct As stated accurately states the business need. 1. As stated, does this reflect the business need in the business case? 2. Have the business rules been confirmed by the correct SME? Modifiable Prioritized / categorized Stated so that there changes to scope or applicability can be made completely and consistently without changes to other requirements Stakeholder has identified where this requirement ranks based on a category scheme 1. Is the requirement stated to stand on its own? 2. Is the scope of the requirement defined? Sample categories: 1.Mandatory or optional 2.Order of delivery: ASAP, first, second., by x, 30 days later 3.Interim solution needed; only a temporary solution needed 4.Connection with other requirements Verifiable Traceable Objective criteria provided to state when requirement has been satisfied. Requirement is sufficiently unique that it can be identified and traced 1. Do the requirements rely on subjective judgment? 2. Are the criteria specified for all conditions of occurrence or use? 1. Is there a unique id? 2. Are related requirements identified? Parent / child / dependent Unambiguous Clearly stated with no ambiguity or vagueness 1. Are there multiple meanings for the statement? 2. Is the requirement too general, applying in too many cases? Necessary A need for the business to achieve the goals of the business case 1. Is this requirement met in the current situation? If so, does the solution need to be changed? Feasible Requirement can be satisfied or has been satisfied 1. Has any other organization met this requirement? 2. Can our organization deliver a solution? 3. Can any organization deliver a solution? Understandable Requirement does not contain specialized or obscure language that is unfamiliar to stakeholders and is stated directly and simply. 1. Can you phrase the requirement for an executive? 2. Can you phrase the requirement for an accountant? 3. Can you phrase the requirement for the customer service department? 4. Can you phrase the requirement for a developer?

61 Let s try FACTORING together GraceFamily

62 Introducing the WIMPS app... Wedding Information Management and Planning System Counselman Collection

63 Who are the Users / Personas? Bride Mother of the Bride Bride s Prospective Mother-in-Law Groom Father of the Bride Wedding Planner Banker

64 WIMPS USER STORIES As the Groom I want a thank you note generator that will reduce the amount of time I have to spend writing thank you notes because I have better things to do. As the Father of the Bride I want to be able to veto guests that are on the invitation list provided by the other family because I am not made of money.

65 What Outcomes should WIMPS produce? 1. Lists of gifts for registry upload 2. Thank You Note Templates 3. Gift Tracking 4. RSVP Tracking 5. Preferences, lots of preferences 6. Seating Problem Resolver 7. Dress Guidelines 8. Template letters to warn those who might bring their small children

66 Let s Factor by... And, by Developer Needs

67 Today s Agenda Introduction MindTuning Two Customers for the Requirements Package It isn t just the document Actionable requirements are essential Wrap Up and Questions

68 Questions?

69 Requirements Factoring Themes User Functional Solution Constraints Other Problem Decomposition Actionable problem statement(s) Functions Processes Affected Systems Affected Roles Data Stakeholder needs Solution Boundaries Deadlines Controls Cost limits Interim or permanent Evolution or big bang Local, regional, or global Process synchronization points Problem Context Business impacts Acceptable trade offs Potential changes for problem definition Influences Priority Audiences 69

70 Today s Objectives Review how the requirements package feeds the developer s work process. Describe how to expand the elicitation process to constructively include developers. Introduce some factoring techniques that will improve the requirements detail level for developers.

71 Thank you for your participation! David De Witt, IT Leadership Practice Director NueVista Group Oak Brook IL