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.
What do you think? Are you comfortable with the expression “requirements elicitation” or “trawling for requirements”, or do you also believe that there must be a better term to describe the key task of defining requirements?
|
By Adriana Beal. Adriana Beal received her B.S. in electronic engineering and MBA in strategic management of information systems from two of the most prestigious graduate schools in Brazil. For the past 10 years, she has been providing IT business consulting services to a diverse client base, including major U.S. financial institutions. She is the principal consultant at Beal Projects, where she offers consulting assistance throughout the software development life cycle for organizations implementing large, complex software projects. She is also the founder of Projeto 100%, a movement making successful changes in the lives of families living in poverty in Brazil. View more blog posts by Adriana Beal |
Related posts:
Loading ...
{ 2 trackbacks }
{ 16 comments… read them below or add one }
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
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.
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.
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.
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.”
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.
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.
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.
Linda, I really like your suggestion, “Requirements Development”, exactly for the reasons you mention. Thank you for the contribution!
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.
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!! : – )
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?
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
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.
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!
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.”.