Beyond Gathering, Eliciting and Trawling for Requirements

Author: Adriana Beal

In my last article, I explained why I don’t see any benefit in moving beyond the term “requirements” when describing the key activities performed by a business analyst. My point was that business requirements and solution requirements represent the logical progression toward establishing a solution for an identified business need. This article from Practical Analyst illustrates with a diagram such progression from problem definition to solution definition, in which the business analyst takes an active role focused on moving from an ambiguous description of a problem to establishing the scope and the requirements of its optimal solution.

Today I’m heading to the opposite direction, discussing terms frequently used in the literature I don’t particularly like to use to describe the BA work: requirements gathering, capture, elicitation, and trawling.

For a period, “requirements gathering” was the term commonly used to describe the task of identifying requirements. Arguing that defining requirements is more than simply assembling them together, many authors opted to use the expression “requirements elicitation” instead. “Elicitation” is also the term adopted by the BABOK, which provides the following definitions for the verb elicit:

1. to draw forth or bring out (something latent or potential)
2. to call forth or draw out (as information or a response)

It’s common to see specialists disagreeing with the use of words like gather, capture and elicit to describe the process of looking for requirements, claiming that these words assume that the requirements already exist, even if in a concealed or latent manner, and simply need to be exposed. Robertson and Robertson, the authors of Mastering the Requirements Process, proposed the term “trawling”, using the analogy of fishing, “running a net” through the organization to “trap” as many requirements as possible.

Even though now favored by writers such as Mike Cohn, author of User Stories Applied: For Agile Software Requirements, to me the verb “trawl” is even less ideal than “elicit”, as it suffers from the same problem associated with “gather”: it presumes that the requirements are out there, in the solution space, waiting to be captured.

Admittedly, the words elicit and trawl have positive attributes. The former has the advantage of highlighting the need to actively engage the stakeholders in defining requirements. The latter provides a useful metaphor that emphasizes the fact that skill is an important factor in identifying requirements (like a person who fishes by trawling, an unskilled requirements trawler may waste time and miss requirements looking for them in the wrong places, or using the wrong techniques).

Both become unsatisfactory, though, when we think in terms of conscious, unconscious and undreamed of requirements.

Conscious requirements are those which one or more stakeholders are aware of, and probably part of the reason for building the solution in the first place. There are other requirements, however, referred to as unconscious and/or undreamed of requirements, that may remain forgotten, overlooked, or simply unimagined until stakeholders start to use the system and experience the need–unless a skilled business analyst is successful in identifying them during the requirements process.

Which term, then, would be more appropriate to describe the tasks performed by business analysts to define requirements? What we are looking for is a term that can be used to describe the process of not only eliciting conscious requirements, but also figuring out the unconscious and undreamed of ones.

“Requirements elicitation” is a term that could fit the bill, if interpreted in the sense that some requirements being elicited may be, indeed, “something potential”, as mentioned in the definition of the word elicit. It seems to me that the dislike for the expression “requirements elicitation” comes from the fact it is not easily associated with devising requirements that are possible but not yet in existence–the unconscious or undreamed of requirements.

I would be interested in the suggestions others may have, but the word I have been favoring recently is discover, for which the Webster Dictionary has the following definitions:

1. to make known or visible
2. to obtain sight or knowledge of for the first time

While the first description is similar to the ones associated with word elicit, the second, “to obtain sight or knowledge of for the first time”, helps clarify an important dimension of the requirements definition process: identifying requirements that may need to be invented, formed in the mind by new combinations or applications of ideas or principles, or devised through the use of investigation, imagination or ingenuous thinking. Seen in this light, the word discovery presents a more comprehensive view of the requirements process, emphasizing how such process typically demands from the analyst more than simply “bringing out”, “making known”, or “capturing” requirements.

 

>>Learn More About Discovering Requirements

Here are 53 Tips for Discovering All the Requirements

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more

Comments

  1. Hi Adriana:

    Thanks for yet another great post. I am comfortable with requirements elicitation, as that is the closest identifier of what really occurs. Even those reqs that don’t yet exist are “discovered” as a result of the elicitation of feedback from stakeholders. If the analyst is creating requirements that are not directly traced to elicited feedback from stakeholders, that would be requirements invention, not discovery…..and is a problem.

    That being said, I do use the term Requirements Discovery, as well. It is also very fitting to what occurs, but remember that discovery is only a result of elicitation….IMHO

    Doug

  2. Thanks, Doug! I would be comfortable with requirements elicitation too, if it weren’t for so many authors complaining about it due to the limiting interpretation the word “elicit” seems to have acquired.

    One example: the book “User Stories Applied” mentioned in my article has a section titled “Elicitation and Capture Should Be Illicit”. The author says, “Terms like these imply requirements are out there somewhere and all we need to do is have them explained to us and then we can lock them in a cage”). If that’s the typical interpretation of elicit, I’d rather use a different term ;-).

    You also said: “If the analyst is creating requirements that are not directly traced to elicited feedback from stakeholders, that would be requirements invention, not discovery…..and is a problem. ”

    I think we are interpreting “requirements invention” differently here.
    “Inventing requirements” can be a great thing, particularly when stakeholders don’t have a very precise idea of the business needs. In this case, using his analytical skills, a BA can go deeper into the business opportunity or problem, and figure out requirements that were previously “undreamed of”, but become extremely relevant for a solution.

    That is the essential point here: I’m talking about “invented requirement” that are received by the stakeholders as something crucial, or at least highly desirable, for the solution. I’m definitely not talking about gold plating or adding unnecessary features or requirements that wind up contributing more to the cost of a product than to its usefulness, which I think is what you mean by requirements invention being a problem.

  3. Yes we were a bit disparate on invention, but your crack analysis skills have pulled us together. I don’t like the example definition of elicitation either, as you mentioned….and would definitely opt for another term as you did. I view the elicitation process as very broad and open though, so I think that might be why it appeals to me.

    Even as I read your paragraph about proffering invented crucial requirements, in my mind I’m still thinking that this occurs only after an analyst elicits the primary need from the stakeholder.

    So I think I’m going to stick with elicit. There. I said it. Final answer. 🙂

  4. Hee. One vote for elicit, then.
    We are on the same page– “invented requirements” definitely need to occur only after an analyst elicits the primary need from stakeholders, as you said.

  5. I was reading thru the post and about to jump down to the comments when you hit on the best word: discover. I and my colleagues use a process created by IAG Consulting, literally called “The Requirements Discovery Process (RDP)” It is an overall process, from initiation and scoping thru to definition of Functional and Information Requirements, and on to Requirements Management.

    We define those requirements based on what the business does or wants to do to be successful, and the Information they need to do it. So, there are no “undiscovered” requirements. There can be as yet unknown business opportunities, but the business has to discover them before requirements can be defined.

    Long before using the RDP, I took a copy of a map of Africa circa 1820, when all that was mapped was the coast and the final few miles of the rivers; the rest of the map was blank, so in the middle of that blank space I wrote “Here be the Requirements.”

  6. Jenny Nunemacher says:

    Hi Adriana,

    First a bit of levity: This nitpicking over words and sematics is why we are all analysts. It’s what we love to do! To capture the “real meaning” of the words being used.

    More seriously, I initially though of requirements discovery as it has somewhat of a positive connotation. However, I think the argument can be made that it too could suggest that “Requirements Land” is out there just waiting for the right person in a boat to come along. Also, as Doug said, discovery really should come after the process of elicitation — the planning and execution of the process to discover.

    What about requirements synthesis? Consider:

    Analysis: the process as a method of studying the nature of something or of determining its essential features and their relations

    Synthesis: the combining of the constituent elements of separate material or abstract entities into a single or unified entity.

    So, we first perform business analysis to understand the business, its motives, relationships, rules, etc. and then we perform requirements synthesis based on that analysis.

    It is satisfying to me to think of pulling together all the concrete and abstract ideas, needs, and wants to essentially synthesize them into something that is more meaningful than what existed before I started.

  7. David: I like the name you gave to your process, “The Requirements Discovery Process (RDP)”. From what you describe it does seem like an effective methodology for surfacing the “unconscious” and “undreamed of” requirements in addition to the “conscious” ones. Your story of the map of Africa is really great. It should be in a book if it isn’t yet :-).

    Jenny: I agree that it is very satisfying to pull together all ideas and synthesize them into something more meaningful, as you wrote – nice way of putting it. By the way, I was waiting for someone to mention the “nitpicking over words”, but if we think about it, words and semantics does affect a lot how we look at things. I feel that the way we describe the BA work can seriously affect how managers see the role, and even how much a professional gets paid, so it is important to select the words well whenever we have a chance to do so (which is great, since many of us BAs do enjoy defining terms and discussing the real meaning of words, as you pointed out :-).

    When you say, “However, I think the argument can be made that it too could suggest that “Requirements Land” is out there just waiting for the right person in a boat to come along”, I feel that in the second definition of “discover”, “to obtain sight or *knowledge* of for the first time”, the word “knowledge” does help give the requirements definition process a bigger connotation than simply capturing things ready to be collected.

    I understand Doug’s and your logic when you say that discovery really should come after the process of elicitation, but I was proposing the term using a broader meaning, which I think is how David and IAG uses it too. I used the word “discovery” to represent the entire process that is referred to in the BABOK as “requirements elicitation” – to quote,

    “Elicitation (Chapter 3) describes how business analysts work with stakeholders to identify and understand their needs and concerns, and understand the environment in which they work. The purpose of elicitation is to ensure that a stakeholder’s actual underlying needs are understood, rather than their stated or superficial desires.”

    My suggestion was to use “discovery” instead of “elicitation” in this context, as a means to help reinforce the idea of going beyond the “stated or superficial desires” in the process of understanding the business needs. In this sense, “elicitation” and “discovery” would be interchangeable words.

  8. I like to think of it as “requirements development.” Although “development” is used to describe the coding phase of the Software Development Life Cycle, it also denotes growth, change, and cyclical progression.

    Requirements, which begin from the seeds of ideas, require expert analysis, prioritization, pruning, and grooming in order to maximize their production.

  9. Linda, I really like your suggestion, “Requirements Development”, exactly for the reasons you mention. Thank you for the contribution!

  10. David Morris says:

    Requirements Development sounds good, as it suggests more the active involvement of the BA — that we are contributing more than just coming upon them (discovering) and looking at them for a while (analysing).

    To be frank, no one term would be adequate as there are so many aspects to what we do — but then as Jenny Nunemacher says, don’t we just love this type of discussion.

  11. David, we love it because we’re so good at it. We’re so good at it because we have BA DNA. Look out, world!! : – )

  12. I had to send an updated resume to a former client, and noticed that “requirements development” worked very well to succinctly describe the work I’ve done in past assignments. Again, it shows that Linda was spot on with her suggestion!

    But since we all agree that we love to discuss words, I would just add that in my view “requirements development” would be one hierarchy above of what I’m talking about in this article. Requirements development would refer to the entire process of producing unambiguous, correct and complete requirements, whereas “requirements elicitation”, or “requirements discovery”, as I suggested, represents a “subprocess” that has the purpose of uncovering the conscious, unconscious and undreamed of requirements that need to be part of a solution. To successfully complete the “requirements development” process, we need to have other subprocesses in place, such as requirements validation, communication, prioritizing, etc. I wonder if anyone here disagrees with the distinction I just made between these terms?

  13. Adriana,
    The way you describe this really resonates with me. I also would see “requirements development” include the analysis, specification, and management aspects of developing requirements.
    Laura

  14. Yes, Laura, we are on the same page here. The examples I have to illustrate some aspects that would be outside the scope of requirements discovery actually map to what you listed: prioritizing goes into Requirements Analysis, and communication into Requirements Management and Communication–tasks that are part of the requirements development process but are separate from the requirements elicitation / discovery task.

  15. Adriana, I’m delighted to know that you actually used the language “requirements development” on your resume.

    I have been giving the last several comments by you and Laura quite a lot of thought. I’ve also been re-reading my copy of “The Software Requirements Memory Jogger,” which, incidentally, I received after I left my original comment about “requirements development.”

    The “What is requirements engineering?” section of Chapter One discusses Requirements Development and Requirements Management. The illustration in this section shows an outside ring titled Requirements Management, an inner ring titled Requirements Development, and a center circle divided into four equal quadrants titled Validate, Elicit, Specify, and Analyze.

    I believe the illustration denotes that Requirements Development is a part of the Requirements Management process. However, don’t know that there is a correct way to express which process is a part of or a child of which other process.

    For me language has to work in the moment and for the moment that it is expressed, whether it is spoken or written language. As long as we describe concepts in such a way that the stakeholders who are consuming our language understand what we are saying, I believe we are “in scope.”

    In addition, I do not believe “requirements development” actually ceases until the systems and/or processes that depend on those requirements cease to be changed or utilized because the development of the next generation of requirements is based on the results of the previous generation of requirements.

    Just more food for thought!

  16. Linda, thank you for your thoughtful addition to the discussion.

    “I believe the illustration denotes that Requirements Development is a part of the Requirements Management process. However, don’t know that there is a correct way to express which process is a part of or a child of which other process.”

    I agree with you that trying to fit these aspects into a child-parent relationship probably isn’t the best idea. In regard to the illustration you described, if I had to put one inside the other, requirements development would be the outer ring, with requirements management being treated as a subset of what is done to get requirements development accomplished. This is because requirements management is used to plan and control requirements development, but requirements development includes other aspects that have nothing to do with requirements management (such as requirements analysis, used to progressively elaborate stakeholder and solution requirements), so to me it doesn’t make sense to put requirements development inside requirements management.

    “In addition, I do not believe “requirements development” actually ceases until the systems and/or processes that depend on those requirements cease to be changed or utilized because the development of the next generation of requirements is based on the results of the previous generation of requirements.”

    I see your point, and would only argue that it is possible to see it in a different light if you treat “requirements development” as a group of tasks that has as the output a set of approved requirements that can then be used by a different person or group to implement a solution. If business processes change, or enhancements are needed for the solution afterwards, you might need to go through the requirements development cycle again, reusing the results from the previous cycle as you mention.

    This is why it’s so important to use terminology in the right context, as you said so well: “As long as we describe concepts in such a way that the stakeholders who are consuming our language understand what we are saying, I believe we are “in scope.”.

  17. Ignacio says:

    I think requirements must not be captured, we have to let them “emerge”

  18. Ignacio — in the software projects I have experience with, if you waited for requirements to “emerge”, you would probably never get to a final product :-).

  19. yeah, “emerge”, that’s a good one, like how the iceberg emerged out of the night right in front of the Titanic.

    Not looking at all the posts from 2009, I would say that Requirements need to be Discovered, “emerge” sounds like waiting for something to happen.

  20. @David: indeed, “emerge” does sound like waiting for something to happen, rather than being proactive and going through the necessary discovery process to ensure that the problem has been correctly identified and the team has developed a comprehensive understanding of the needed capabilities.

  21. Hey Laura,

    Can you tell me what are the value add can Business Analyst provide from offshore to his/her clients???

    Thanks,
    Sid

  22. Ron Werda says:

    As a 2013 avid follower of Bridge the Gap, I find this post yet another terrific exploration of an important facet. Late to the party as I may be arriving, I would like to propose the following.

    While I have no discomfort with “elicitation”, I also see the applicably of both “discovery” and “development”. Having an advantage of bringing years of experience in the professions of investigation and law, I can contribute from this wellspring. In law, the practice of “discoveries” is the elicitation and more probing drawing out of information. In both discoveries in legal practice more intensely and comprehensively executed, and in investigative interviews and interrogations that employ proven principles in psychology, factual information is “drawn out” from even the sub-conscious (“unconscious” is an incorrect term, often confused for ‘sub-conscious’) mind.

    I agree with Doug’s caution about ‘requirements discovery’ slipping into unilateral requirements invention, but if discipline could stave off this slippery slope, the (quasi-)scientific discovery of unimagined (referent to creativity and synergy between BA & stakeholder(s) / among BA team members, etc.) requirements – still subject to validation and verification- is a noble, creative effort and objective.

    To make more clear, on careful contemplation, if we view the process we are examining here as taking place anywhere across a continuum, then consider (1) the entire continuum ‘requirements development’, (2) ‘elicitation’ applying to conscious/lucid/aware mindsets as well as those residing in the lighter/shallower spectrum of the sub-conscious, and (3) ‘discovery’ applying to the deeper spectrum of the sub-conscious and the unimagined end of the said continuum (i.e. beyond or outside the sub-conscious).

    I devised a graphic to illustrate what I am conveying here, but this post does not support the pasting/insertion of graphics (as far as I can tell).

    Cheers

  23. Hi, Ron!

    This is precisely the reason why I like to keep comments open in my old posts here — sometimes we get a “gem” like your comment here, long after the publication date :-). Thank you for posting.

    Since the time I wrote this article, I’ve been “forcing” myself to stay away from “elicitation” and have been using “requirements discovery” instead, to describe the overall requirements development process, just for the convenience of using one term that potentially will offer a more comprehensive view of the requirements process (instead of two). However, I do like the logic you applied to create the distinction between elicitation vs. discovery (a distinction I can see being useful under some circumstances).

    Unfortunately you are right; it’s not possible to attach images to comments here, but it doesn’t mean we can share your graphic: you could either upload it somewhere (a website, or Google Docs, for example, using the “share” option to change the permissions to public) and post the link here, or forward the image to me (adriana [at] bealprojects dot com) and I’ll share it for you, including the appropriate credits.

    Thanks also for pointing out that “unconscious” is not the right word (I’m not changing my article because it links to the original work that uses this term — fortunately, online dictionaries present “unconscious” as a synonym for “subconscious” , so I guess we can live with that ;-)).

  24. Ron Werda says:

    Hi Adriana!

    Off the top, I enjoy reading your comments across the many posts. The learning curve for all ought never end. I also appreciated your contribution to the Requirements component of the MyBusinessAnalysisCareer “Discovery” course.

    With respect to the latter, I noted that you resisted temptation to delve into this post’s examination of the requirements elicitation/discovery/development debate.

    “Discovery” and “development” are such dynamic terms given the broad array of connotations arising out of the diverse range of human endeavour.

    I do have to beg to differ on the treatment of the terms “unconscious” and “subconscious”. I realize that in layman’s terms, the two have become (mistakingly) synonymous. A thesaurus, that purports that the two actually are synonymous, is flawed. The state of being “unconscious” is a completely different, lower level cognitive state, than the enigmatic, higher level cognitive state that the “subconscious” is. The prefixes alone are instructive enough: from the highest level down, there is consciousness, subconsciousness- which operates in a parallel dimension to consciousness (which arguably frequently suppresses or overrides the subconscious), and then there is unconsciousness (operating at a much lower physiological level).

    Making the distinction between “unconscious” and “subconscious”, and giving the latter its due and consideration, breathes new life and enhances your examination of what is at play per the topic of this post.

    Thank you for the image posting tips. For ease and to fit it into my schedule, I will on this occasion follow your invitation to send my graphic to you via your website, for your consideration. I would be most humbled and flattered if you chose to disseminate it further for the benefit of the rest of us attentive to ongoing professional development.

    Again, thank you very much for paying forward your mentorship in all respects.

    Sincerely,

    Ron Werda

  25. Hi again, Ron!

    First, let me share here the link to your diagram: http://bealprojects.com/BA/wp-content/uploads/2013/05/Requirements-Development-Continuum-R.-Werda.png

    Thanks for sharing it! I’ll definitely add the graphic to a future article as well, so more people can have access to it.

    “I noted that you resisted temptation to delve into this post’s examination of the requirements elicitation/discovery/development debate.”

    Indeed! The main reason is that I didn’t want my previous comment to run too long. But since you are interested in my opinion, here it is. I think what you previously wrote settles it:

    “While I have no discomfort with “elicitation”, I also see the applicably of both “discovery” and “development”. (…) In law, the practice of “discoveries” is the elicitation and more probing drawing out of information.”

    I agree with the notion of “development” being considered the overarching process. If “discovery” can encompass elicitation + more probing to go beyond the stated problem to get to the “hidden problem” that most needs solving, I think it’s easier to call the whole thing “requirements discovery” than make any distinction between “requirement elicitation” and “requirement discovery”. In situations when the distinction is truly important (say, you are planning the requirements work, and want to justify giving it more time than usual because there is plenty of “hidden needs” to uncover in a particular project), then I can see your separation being useful to convey the idea.

    “I do have to beg to differ on the treatment of the terms “unconscious” and “subconscious”. I realize that in layman’s terms, the two have become (mistakingly) synonymous. ”

    You know what? In the past I used to be similarly strict with how words are used, but nowadays I’m more relaxed. I’ll give you an example that will probably make you cringe :-). Some people take issue with the misuse of the word “literally”, as in “he was literally my right hand” (no, he wasn’t — your right hand is literally your right hand, heh).

    But in my opinion, using “literally” as a hyperbole strengthening a metaphor can be an effective way of communicating, so even though I don’t use it (yet), I’m entirely forgiving of the people who do, because the idea they want to communicate is still very clear. I would bet that many people who already adopted the expression know very well the true meaning of “literally”, but because there is no ambiguity of it being used with this new meaning, they just don’t see the harm of using it in this context.

    Same with “unconscious” as “subconscious”. So many people use the terms interchangeable in business, that I don’t really see the point of being picky there (if we were discussing psychology, for instance, I might have a different opinion, and if I was not referencing prior work I’d probably have used “subconscious” myself).

    I’m always happy to learn different views, though, as this is how we all learn and develop new ideas. It’s fine if we have to agree to disagree in some aspects ;-).

  26. Ron Werda says:

    Hi Adrianna,

    I am enjoying this discussion (and learning more your mindset).

    First, to add nuance to my graphic or schema, the connotation of elicitation that I rely on is that endeavour of inquiry that draws primarily from the conscious, lucid mind, as well as that shallow portion of the subconscious. It becomes discovery, to my connotation, when like a scientist/archaelogist/interrogator, we have to probe even more deeply into that still not fully-understood realm of the human subconscious (that ongoing research that coincides with further exploration of that as yet unknown vast portion of the brain). My connotation of “undreamed of” (Laura’s term, I believe) is the realm of the ‘unimagined’, which theorists may even argue runs parallel to both the conscious and subconscious.

    Now to what many, particularly the BA purists, may deem a tangentary diversion into exploration about language, what you, I and the other post contributors are delving into is not tangentary at all. Language, the embodiment of oral communication, is essential, as BAs have to be not only effective communicators, but to borrow from Laura’s citing of the BA manifesto, BAs have to bring a matter from ambiguity to clarity. I hasten to add that you can interchange the term ‘ambiguity’ to ‘misnomers’, ‘malapropisms’ or ‘gibberish’.

    Sure, no one wants to freely bear the burden of being a bastion of language, as language does evolve, BUT particularly where the obligation of clarity is prevailing, we do have to be vigilant of and counter the extremes: at the one end- the polluting ubonics and gangsta-speak popularized by the low-hanging fruit that is pop culture and slathered like cheese-byproduct spread across portions of the business world by desperate marketers and salespeople on a steady diet of menthols and chewing gum. At the other end- the pollution from tactically deliberate, unnecessarily complex wordsmithing, intended to overwhelm and impress, by crafty lawyers/attorneys and academics ever desperate for approval from their elitist peers.

    BAs and other professionals reliant on strong communication should be vigilant to strike that balance, whether language is simplified for the sake of greater understanding pragmatically, or is more descriptive and higher level again for the sake of better understanding and clarity.

    Language can be simple but still be correct, where ‘subconscious’ is certainly not confused for ‘unconscious’, or ‘literally’ confused with ‘figuratively’ (to borrow your analogy). For example, persons such as Mark Twain and Harry Truman were gifted with the right management/repertoire of a healthy vocabulary while maintaining the knack of ‘plain speaking’. Over decades, you may recall seeing the recurrence of an urgent call to the return of or being mindful of ‘Plain Speaking’ from certain quarters of the business and/or literary communities. ‘Plain Speaking’ advice that remains published is a worthy read for any serious BA.

    I certainly agree that it is fine if we have to agree to disagree in some aspects. As you put it, for daily practicality’s sake, there is convenience if not wisdom to pick and choose when not to “be picky” about the misuse of certain terms; to “live with it” so to speak. However, let us remain vigilant for clarity’s sake, where “living with it” does not represent or signify apathy or prolonged neglect. We do not wish to become apathetic about the clarity of our communication in any form (oral, written, online, etc.). From the handsomely-crafted Body of Knowledge should flow its equally essential legacy, the BA ‘Body of Work’: yours, other BAs, mine…

    Sorry, but I had to go deep with this subject matter… 🙂

    Cheers,

    • Hi, Ronn,

      (You’ve added an extra n to my name, so I’m returning the favor :-p)

      I believe that language is important and also that some distinctions may cause more harm than good (when they are not relevant for the task at hand).

      That’s why I mentioned that in some cases it may be very useful to use the separation you suggest between elicitation and discovery, but in other cases, I can see this being irrelevant and just cause more confusion for stakeholders who don’t really care — they want their needs understood and the resulting requirements properly captured, regardless of the name you want to give to the task :-).

      I don’t think there’s a risk that a BA will see the word “discovery” and think, “ohhh! good, this is a free pass to start inventing requirements on my own”. In my view, the discovery process will always have the goal of finding out the known, unknown, and undreamed of but important requirements. (See? I’m just moving away from conscious/unconscious to avoid the issue you raised with the second term ;-)).

      “BAs and other professionals reliant on strong communication should be vigilant to strike that balance, whether language is simplified for the sake of greater understanding pragmatically, or is more descriptive and higher level again for the sake of better understanding and clarity.”

      Definitely agree with that!

      • Ron Werda says:

        Hi Adriana,

        Sorry for the delay in following up with you, and for the typo with your name. (Shameful)

        I too would be surprised if a BA somehow slipped into some facet of baseless invention of requirements.

        I certainly too am in favour of not causing confusion for stakeholders, but then, the requirements development model that we are discussing is not intended for consumption by any stakeholders, nor to be laid at their feet. It is a somewhat fluid concept for any BA to objectively contemplate and deliberate over (i.e. food for thought), and make of it what he or she will (as all BA’s collectively contribute to the evolution of the requirements development craft).

        Certainly for the sake of the task at hand, a BA ought to be rather thick skinned about a stakeholder/staff member’s misnomers or misuse of language; likewise distinguishing same from trade- or organization-specific vernacular and terminology that tasks the BA to consult or generate a glossary/lexicon.

        Look forward to following up with you across other post threads and any upcoming BTG/MyBusinessAnalysisCareer involvement.

        Best Regards,

        Ron