Three Tips For Learning to Gather Requirements

The conversation

10 comments from 4 people, February 2 to February 4, 2016. Gloria replied 3 times.

1. February 2, 2016

   lemoene

   You might be over complicating things Gloria;-) Modern Agile methods rely much more on simple use cases and story telling. The lab writes up what the system is suppose to do for them in layman's language and iteratively expands from there as vendors ask questions until a golden 'common understanding' is reached.

   There is no need for anything more complicated to be mined from intimidating learning materials as long as all aspects are covered and unambiguity is maintained. Lab staff know their requirements better than anybody else and such documentation is for the vendor's analysts to interpret, not the other way round.

   The lab uses these docs, their own, they understand very well as quality management tool towards LIMS acquisition and eventual acceptance testing.

   The lab is also the client, not always right, but remains the client, with whom the buck stops and they therefore call the shots. The such arrived requirements documentation does not have to conform to any LIMS vendor's terminology or interpretation of lab workflows. The less so, the wider it can be used, at least 3 vendors should be involved in the acquisition process.

   'No plan is complete' and without doubt items will be overlooked, some analysts put it at as much as 10 percent. These are normally uncovered during customisations or implementation when users get familiar with the software and see new ways of assisting them in their work. It is important thus that formal change control procedures be in place to take proper care of a change in requirements, more so where the changes effect budgets and delivery dates.

   The above works particularly well in implementations with high configuration and customisation quotients which is often the case with Open Source software, where, with the program code freely available, 100% match with requirements is frequently achieved.

2. sepner

   Having done requirement studies for over 35 years (yes, I will show my age), one of the greatest opportunities overlooked by many is to ask vendors for more than you think they can do. Many have functions and features that are not advertised and if you do not ask, you will never find out that they exist.

   I suggest that everyone carry a small notebook with them during the requirements phase. Us it to jot down your observations as you ask yourself and your coworkers the following two questions (from Simplify Everything; Getting your team from do do to done done with one surefire method). 1 - what is the dumbest thing you did today? 2 - what is the hardest thing you did today?

   Both will lead you to opportunities to not just automate, but to improve processes. In many cases, just simplifying the routines will eliminate bottlenecks and headaches.

   So, have fun gathering requirements and it will not be such a chore.

3. Gloria MetrickAuthor

   One thing we should keep in-mind is that there are a LOT of experts out there. The customer is an expert at their own process. Additionally, many customers hire people who are big experts in our industry, so they do have a wide view of some of the opportunities out there.

   On the other hand, the software vendors do have a lot of experience with how to make the most of their own software product in an implementation. They know how to make it efficient for the users to use and to help keep it maintainable. Software vendors also hire top industry experts who know what many customers need.

   On top of all of that, the services vendors also have experience, experts, and etc...

   With all that considered, it's in all our best interests to work collaboratively and to listen to what each other have to say. Whether or not the other person is right isn't the issue as much as the fact that we might learn something along the way if we remain open to the fact that there are many experts.

   In the end, for those of us who are experts, we certainly shouldn't be going around beating our chests decrying ourselves the most expert-est (yes, I made that word up!). Instead, if we recognize that there are many experts to work with, we'll make the greatest impact by working together.

   While I'm on the subject, the least expert team members often have the most illuminating comments. So, just because they're not experts, when we don't listen to them, we lose a lot of candid observations that we might otherwise miss.

4. Thomas Vaughan

   The commenter should be told that insulting people or making inappropriate comments about their age is not a good way to gain acceptance of one's ideas.

   If the commenter had carefully read the original post they would see that Gloria's post was advice to the CLIENT person who got stuck with "requirements" task (I'm sorry "was given the opportunity").

   The suggestion that the person not bother with intimidating materials (e.g. SOPs) seems pretty bizarre in the the pharma industry. But Gloria's advice was to LEARN ABOUT ASKING QUESTIONS. Users of SOPs can be very siloized. We learn to follow the SOP while doing a task but often this obscures the flow. You need to keep digging till you understand the flow or you will be one of the 60% of software that has to be thrown out.

   Giving ambiguous "layman's language" to a vendor will get a resounding "Yes we can do that - sign here". Later you will find that works against you in the contract.

   The rest of the comment sounds like typical use case "hoopla".

5. Thomas Vaughan

   Why you should keep digging for requirements:
   A friend who develops financial systems told me this story:
   They were automating the catalog pricelist update, or something similar. They were interviewing the person who made the updates. Getting lots of info on the process. Back in those "olden days" they didn't know to call it "use cases". But my friend kept asking the update person "But how do decide what changes to make"? After asking the tenth time he gets the answer "Oh every Tuesday a list of changes arrives via inter-office mail." "Who decides the changes to put on the list?" "I don't know."
   Fortunately the latest list of changes was still in the inter-office mail envelope. They went to the previous addressee listed on the envelope - a different department, in a different building, in the next town over. That person was not involved, but by asking around with other people served by the same mailstop they found a whole sales/marketing strategy and pricing group ... Things run deeper than they appear.

6. Gloria MetrickAuthor

   Around the time these comments began, just by chance, I received an e-mail newsletter from Autoscribe where they mentioned their Gathering LIMS User Requirements. This was possibly being sent about the same time I made my post so there's no possibility it's meant as a response of any kind, in case anyone is wondering. I just found the coincidence the be rather funny, but also potentially useful to people.

7. lemoene

   Be more direct Tom and please don't speak on my behalf. An *unambiguous* document - i think you misread that - in layman's language by the lab client people, which they fully understand, is imnsho less work, easily mastered, more affordable and serves the process better than one in difficult to understand geek speak. Using simple language, there is nowhere for any of the counter parties to hide. Not my idea, user stories are widely accepted in Agile Scrum and Kanban requirements gathering techniques, and easily convert to test cases vendors can be held to. Calling it hoopla is obscuring the issue.

8. February 3, 2016

   Gloria MetrickAuthor

   Requirements aren't "geek speak." They're simple statements that tell what is required. We could spend a lot of time comparing different methods of gathering them but, bottom line, requirements gathering is usually the easiest way to go. It doesn't require special tools, either.

   Additionally, most readers of this blog aren't open source customers. People that I tend to know or make a connection with are usually COTS (Commercial Off-The-Shelf) product users because that's what I do and those are the people I tend to make contact with. So, everything else aside, having read this, actually known for some time what "open source" means (why do people think this is something new?), and having given this all some thought, I would still say what I said at the beginning, which is to give three tips for gathering requirements.

   I'm not telling users doing other things to stop but I AM saying that this is the easiest way to start this process.

   I should add that everyone TALKS about Agile but most of them aren't really doing it. If you press them with a difficult question, they'll respond with something like, "Oh, well, what I meant was that we're using MODIFIED Agile" and they run like the dickens. Basically, there are a LOT of people using the term form marketing purposes or because their boss told them they have to and it's not that easy to sort them out from the real Agile folks unless you know something about Agile.

9. John H. Jones

   This is a good discussion. Our industry seems to cover this topic at least once a year and I have not seen much by way of concrete advice on how to precisely gather those requirements.

   I will share this posting on LinkedIn and see if we can expand on the ideas.

10. February 4, 2016

    lemoene

    With all that Agile hoopla Gloria, I propose your tip 1, learning materials. I did not record metrics, but for an oldie with 32 years in software development, conversion probably improved my productivity by a third or more.

    Being both commercial and off the shelve, FOSS, Free and Open Source Software, is COTS too, but does offer the client many additional freedoms not available from proprietary systems. In the very very old days, most software was in fact open.

    That's beside the point here though, and we agree that requirements documentation should be in easy to understand language. And nothing can be easier for a lab person than Story Telling used in Agile requirement gathering.

Comments are closed. This conversation is from 2016. Ask us to remove a comment