{"id":146,"date":"2011-09-30T21:03:27","date_gmt":"2011-10-01T05:03:27","guid":{"rendered":"http:\/\/zuill.us\/WoodyZuill\/?p=146"},"modified":"2013-01-17T10:46:48","modified_gmt":"2013-01-17T18:46:48","slug":"requirements-hunting-and-gathering","status":"publish","type":"post","link":"https:\/\/zuill.us\/WoodyZuill\/2011\/09\/30\/requirements-hunting-and-gathering\/","title":{"rendered":"Requirements Hunting and Gathering"},"content":{"rendered":"

Requirements Gathering<\/h3>\n

In the traditional phased SDLC\u00a0approach, a phase for \u00a0“Requirements Gathering”\u00a0is done very early on in the process.\u00a0 We can argue about all\u00a0the issues with this some other time – I am just covering one issue here.<\/p>\n

My opinion of this “phase” is that it is pretty much worthless:\u00a0THERE IS NO WAY TO PROVE THAT THE REQUIREMENTS WE’VE GATHERED ARE COMPLETE AND CORRECT UNTIL\u00a0WE HAVE WORKING CODE<\/em>.\u00a0 Working code, in this sense, means code that is actually\u00a0being used to do real work for the real users.\u00a0Does that make sense?\u00a0 If not, you probably don’t want to read on, and probably shouldn’t bother reading anything I have ever\u00a0written or will someday write.\u00a0 Plain and simple.<\/p>\n

Requirements Hunting and Gathering<\/h3>\n

One issue is that requirements will rot if not used promptly after collecting them.<\/p>\n

Early humans\u00a0are thought to have used a subsistence strategy where they hunted and gathered (and scavenged and stole) their food\u00a0for immediate use.\u00a0 If the food was not eaten shortly after it was obtained, it would rot or otherwise become useless.\u00a0 The food needed to be put to work within minutes or hours, or at most a few days.\u00a0 Otherwise, the effort of hunting and gathering would go to waste.<\/p>\n

Just like the early hunter and gatherer folks, we have\u00a0no way to “preserve” the requirements we’ve gathered.\u00a0 We don’t even know if they are edible.\u00a0\u00a0And yet\u00a0we store them for a long time, and do a lot of work\u00a0with them during that time, and base a lot of decisions and work\u00a0on them\u00a0(like estimates, budgeting, designs, architectures, ramping-up efforts, coding, testing, marketing, and so on) and all the time the requirements\u00a0are rotting.<\/p>\n

It isn’t until the code becomes true working code that we can get real information about the correctness and completeness.\u00a0 Until then everything is just assumptions and guesses.\u00a0 Unfortunately,\u00a0by the time\u00a0we learn that the requirements have indeed\u00a0rotted it is too late.\u00a0\u00a0They have become toxic, wasting our money, time, and effort, and killing the usefulness of the project they are supposed to define.<\/p>\n

Early Humans understood this, and therefore rarely wrote software, and never ate mayonnaise that had not been “refrigerated after opening”.\u00a0 Fortunately for Late Humans (us, that is), someone\u00a0eventually figured out how to preserve foods so we could buy and eat them days, months, or\u00a0years and years after they\u00a0had been\u00a0plucked, prepared, and packaged.\u00a0\u00a0 However, to this day, I have seen\u00a0no way to preserve\u00a0requirements.<\/p>\n

Requirements MUST be used while fresh<\/h3>\n

So, my recommendation is: Eat your requirements as soon after you have picked them as possible.\u00a0 Between the garden and the kitchen they have already started to lose their sweetness.\u00a0 [Please imagine that there are\u00a0many other very funny food based metaphors here.\u00a0 I am not having trouble coming up with them as such, they just don’t seem all that meaningful, and they aren’t as funny as I thought they would be].<\/p>\n

How do you do this with software?\u00a0 You use a very short “discover, define,\u00a0code\/review\/re-discover, deliver, discover more, repeat” approach during which we are continually discovering what it is we really need to do:<\/p>\n

    \n
  1. Keep your requirements at\u00a0a very\u00a0high and general level until just before use.\u00a0 Details in the requirements are a smell of the rot.\u00a0 Pay attention to\u00a0that.\u00a0 Understanding the business need is important, details about how that translates into software is not.<\/li>\n
  2. Pinch off a small but useful bit of\u00a0one of the\u00a0high level requirements – preferably something of immediate and high value to the end user, but anything of value will do.\n
      \n
    • Find something\u00a0that you have a pretty good chance of turning into working code quickly – in a day or two if possible.<\/li>\n
    • Prune as you go as needed.<\/li>\n
    • Identifying small bits,\u00a0pruning as you go, and getting something of value quickly are\u00a0skills you must aquire.\u00a0 It\u00a0takes practice, dilligence, and close attention.<\/li>\n
    • You don’t have to understand the requirement\u00a0completely – you will discover the details and what is important as you code it up while partnering with the business experts\/users.<\/li>\n
    • Prioritizing is useful – you want to take\u00a0on features in a prioritized manner, but\u00a0don’t go\u00a0overboard on this –\u00a0close enough is close enough. \u00a0We’ll talk about this some day.<\/li>\n<\/ul>\n<\/li>\n
    • Code it up.\u00a0 The code-it-up process is not just coding – we must\u00a0work closely with the business people discovering the details as we go.\n
        \n
      • Code some tiny bit\u00a0the business expert can see and use (click a button, see a list, choose an option, whatever)<\/li>\n
      • Get her feedback, comments, and direction continuously – early on\u00a0and frequently – every 10 minutes to 2 hours.\u00a0 Every time you have something meaningful you can\u00a0show get it in front of the\u00a0business expert.<\/li>\n
      • Sitting side-by-side works well when appropriate, but if that isn’t practical at least be within shouting distance.<\/li>\n
      • \u00a0If you go longer than 4 hours without getting useful feedback you are wasting your time and need to learn how to work in smaller chunks.<\/li>\n
      • You might discover you have completed some small but deliverable bit of funcitonality that is just a part of what you had chosen to work on.\u00a0 If so, then deliver it, and go on to the next bit.<\/li>\n<\/ul>\n<\/li>\n
      • Deliver it.\u00a0 That is – put the code into actual use with actual users.\n
          \n
        • You’ll discover more things about it as the users use it.<\/li>\n
        • This will help expose the next thing to work on.\u00a0 The real next priority.<\/li>\n
        • If they don’t use it once delivered, you’ll have learned something else of value: It wasn’t of value. I’ll cover that some other day – but that is a magical and very valuable bit of knowledge to gain early.<\/li>\n<\/ul>\n<\/li>\n
        • Do it again tomorrow (or today, I suppose)\u00a0with another bite-size chunk of functionality.\n
            \n
          • You are now steering the project toward the best possible result given the abilities and knowledge you and your team have.<\/li>\n
          • Important things will become apparent and be added to the working code in a prioritized manner.<\/li>\n
          • Useless things will show themselves or be ignored and you’ll\u00a0waste as little time as possible on them.<\/li>\n
          • You’ll get better and better at it.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n

            Following this approach the requirements\u00a0will not\u00a0rot because you leave them “on the vine” until you are ready to eat and digest them.\u00a0 Of course, what comes out after the eating and digesting\u00a0is not covered in this article:\u00a0 At some point all analogies break down.<\/p>\n

            [NOTE: Everything I say in this post and on this blog is based on my experiences, study, and observations.\u00a0 It is MY OPINION. It is the way things seem to me.\u00a0 It might be useful to you, might not – I don’t really care.\u00a0 If you want to argue about it, that is fine.\u00a0 I am suggesting that there are better ways to do almost everything we do in software development, and that it is worth thinking about it and doing something about it. You might already have better ways to do things, and I want to hear about it.]<\/p>\n","protected":false},"excerpt":{"rendered":"

            Requirements Gathering In the traditional phased SDLC\u00a0approach, a phase for \u00a0“Requirements Gathering”\u00a0is done very early on in the process.\u00a0 We can argue about all\u00a0the issues with this some other time – I am just covering one issue here. My opinion of this “phase” is that it is pretty much worthless:\u00a0THERE IS NO WAY TO PROVE […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,21,1,22],"tags":[],"class_list":["post-146","post","type-post","status-publish","format-standard","hentry","category-agile-stuff","category-estimating","category-general-stuff","category-no-estimating"],"_links":{"self":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/146","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/comments?post=146"}],"version-history":[{"count":11,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/146\/revisions"}],"predecessor-version":[{"id":440,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/146\/revisions\/440"}],"wp:attachment":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/media?parent=146"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/categories?post=146"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/tags?post=146"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}