Subject Matter Expertise is Essential for Stakeholder Requirements
The stakeholder requirements that define an information technology solution come, in theory at least, from the business community. Since the “business community” is too big to talk with, we need to identify someone (Stakeholders) who can represent their interests (and we are NOT talking lawyers, here!). Actually, we need a couple of different representatives. The first group is people we in the Information Technology universe refer to as “Subject Matter Experts” or “SME”. As the title implies, we expect them to be an expert on some subject that matters (at least to us). Although our definition of an “expert” is “the person in the group who knows the most about the topic”, we sometimes have to settle for anyone in the business community who has time to spend on the project. We are not being facetious here; the business community is very busy doing business — and rightfully so. Without that, they really would not need our services. Subject matter experts are the primary source of stakeholder requirements.
End-Users are People, Too
Other representatives of the business community are often called “End Users” . We are not allowed to call them “Users” since that would imply that we are “Dealers” or “Pushers”; maybe that was what “DP” actually stood for, “Data Pusher” . End users are those folks who, in the end, will use our solution as an integral part of their daily lives. (If we actually talked with those lawyers we excluded earlier, they would probably call these people our “victims”). In order to deliver a working business system to the business community, we need to understand how end users work, what they do, why they do it, and how technology can help them do it better. That is fertile ground for business and stakeholder requirements.
Managers Needed
The third category within the business community we need access to is identified by the ubiquitous term “Manager”. Regardless of what you personally think about those who “manage” things, they are critical for the acceptance of the proposed business system by the entire business community. To satisfy them, we need to understand what information they need in order to do that “managing” thing. If they do not get the data they need, bad and evil things will fall upon the business (not the least of which is that our business system will not be implemented, thereby adding to the statistic of failed projects — and, trust me, that does not look good on your resume!). Managers provide a very crucial set of business requirements.
The Business Analyst Role
Now that we have dealt with the business community’s contributions, we can cross the fence over to the Information Technology side. But wait! Before we can cross that fence, we need to introduce those of us who sit, rightfully so, on that fence. These are the people that we typically refer to as “Business Analysts”, “Business Systems Analysts”, “Requirements Engineers” , or simply “those folks sitting on the fence between the business community and the information technology universe”. Business analysts are, of course, ultimately responsible for ensuring that the business community identifies all of the business needs that information technology can satisfy. Their primary job is to translate those business needs into business and stakeholder requirements. (Their real job is actually to defend the information technology group from attacks by ambiguous, unclear, and especially unspecified business needs that could do serious harm to the project. To be successful, this group, like Gandalf in “Lord of the Rings”, needs to master delivering the phrase, “You shall not pass!” ).
Inside the IT Universe
OK, now we have crossed over. We are truly in the land of the technophiles, commonly referred to as “IT”. Yes, folks, this is IT (double entendre intended)! You have arrived. Here is the land of System Analysts, Data Analysts, Database Analysts, Developers, and a whole slew of similar titles that, to those visiting IT for the first time might seem a bit overwhelming. So to clarify, System Analysts are close relatives to the Business Analysts we described in the previous paragraph. They are so closely related that they sometime join the business analysts sitting on the fence to keep them company. More commonly, however, they translate the business and stakeholder requirements that the business analysts delivered into solution requirements which may then beget system specifications, also known as tech specs.
Data Analysts, on the other hand (and most of them have another hand), take a long, hard look at those same business and stakeholder requirements and attempt to deduce data that might be hidden there. Their job is to determine what information the business community wants and needs to be able to do what the business community wants and needs to do. They then structure the data into business data models, user views, and other forms of magic to try to find hidden data (data is obviously a very shy animal, so data analysts have to conjure up all kinds of tricks to get it to show itself).
Now we could address database analysts, developers, and other awe-inspiring titles, but that would really get us mired down in the technical quagmire which we, who are accustomed to dealing with business and stakeholder requirements, steadfastly attempt to avoid. Let it suffice to say that those folks who bear these intrepid titles are brave individuals indeed. They are the conjurers and magicians who struggle daily to create the magic that is information technology and, if you are one of the lucky ones who has been on that stage and survived, we applaud you! We may not understand you, but we certainly appreciate you and are grateful for your wizardry.
The Critical Role of Testers
Actually, the only other role that we would like to mention is the often neglected role of Tester. This role is ultimately the business community’s final defense against shoddy systems, improbable data, and bugs that appear to proliferate in the technology universe. Apparently, it is quite warm and humid in there, ideal breeding ground for some type of bug that testers dedicate their lives to eradicate. I don’t know about you, but my hat is off to this group of individuals as well. I hate bugs, both in my house (in Florida, land of bugs) and in my systems, so I am grateful to anyone who is willing to take the tedious and often dirty task of finding and killing those creatures that make our lives miserable.
So this is it, then, the group of folks that play critical roles in the gathering, analyzing, expressing, interpreting, and validating of business and stakeholder requirements. There are those who would call this group the “Fellowship of Fools” for embarking upon such a challenging and career-threatening endeavor as this, but we (as members of the group) prefer the title, “The Significant Seven”. We the Subject Matter Experts, End-Users, Managers, Business Analysts, System Analysts, Data Analysts, and Testers are willing to dream the impossible dream, to follow that star no matter how far until we find the requirements that are rumored to lie at the end of the rainbow.
Wish us luck.
