User Requirements Are Everywhere
Not only are user requirements notoriously difficult to capture, they can also be very challenging to express. My basic premise is that user requirements frolic freely around the minds of managers and business users. You also know that the primary job of the business analyst is (in my not-so-humble-opinion) to capture those user requirements, round them up, corral them, cage them, or do whatever else is necessary to keep the user requirements in a safe place where they cannot harm the innocent designers, developers, testers, and other downstream project participants.
The topic du jour, therefore, is not where you get the user requirements from, but how do you tame them without breaking their spirit? Okay, I don’t really think that they have a spirit per se, but they are definitely alive because they grow like weeds, change every time you look at them, and never turn out quite the way you thought they ought to when you first spotted them in the wild. (Hmmm, given that definition, they sound a lot like children — but let’s not go there!). Taming user requirements is basically a question of figuring out the form best suited for each individual requirement based on what it is trying to express.
Using Text to Express User Requirements
Human languages are our primary mode of communication. Many user requirements expressed in plain, simple English (or whatever other language you prefer) sentences will be on their best behavior. They really do not need to be given preferential treatment, pampered like stars, or otherwise distinguished. They are what they are, plain and simple. I do, of course, highly recommend that even user requirements expressed in this, the simplest possible form, conform to a few, simple rules. This means each individual requirement statement is a simple, complete, well-structured sentence that emphasizes "what" should be done, not "how" to do it. It targets components that are in scope for your project in understandable, unambiguous, clear, and objectively measurable language that build complete, internally consistent, non-redundant, prioritized sets of conditions the future business solution should meet.
That sounds simple enough, doesn’t it? If you can express your business requirements as simply as I just stated the six rules in the previous paragraph, approximately 26.2% of your target audience will understand you (according to the Readability Index that my word processor provided). This sounds more like a case of do as I say, not as I do. Really, keep it simple.
Sometimes, Text Is Not Enough
Unfortunately, there are some user requirements that simply do not lend themselves easily to natural language. User interfaces requirements (excuse me, I’m showing my age; I should say "user interaction requirements") have long been recognized as falling into this category. They were and are the primary target of prototypes. A prototype of a user interface may contain text, but the primary idea is to illustrate layout, feature placement, interactive components, etc. in a manner approaching what the end user will see in the future. Of course, there are varying levels of fidelity in prototypes, from the plain, simple paper tigers to sophisticated simulations that look for all the world like the solution is ready for prime time (although it obviously is missing minor components like security, functionality, interfaces, databases, etc.)
Anytime you are dealing with the development of a component of the human/machine interaction boundary (another negative example of simplicity in action), I would recommend that you consider and/or develop a prototype of it as early as you possibly can. The requirements that the prototype expresses set expectations for the users and will ultimately determine how they react when they first see the real deal.
Are We There Yet?
(Obviously not, or the article would end here!) Having taken care of the visible interfaces and whatever aspects plain language describes, what is left? Well, there are a whole slew of user requirements that need to be expressed visually to be understood. The problem is, these user requirements do not deal with what the end user will see, but with the structural components of the solution. The major structural components of information technology solutions are functions (a.k.a. processes) and data (a.k.a. data).
Process models make what real people do visible in a way that many in the business community (and, all too often, many in the information technology area) have never seen before. A process flow can be represented in the form of data transformations, transportation, and storage (using data flow diagrams — DFDs) or control flow (using activity diagrams — with or without swim lanes). If the project deals with highly interactive situations, use case models and documents may also be appropriate. Each mode of representation shows different dimensions of the solution and each can help the business community spot holes in their process. These models can be just as revealing for the people who are doing the job as it is for those responsible for managing the process. They are certainly valuable tools in the toolkit of the intrepid business analyst.
Does This Go Any Deeper?
I have not even scratched the surface of data, yet. For example, data attributes and relationships are a whole lot easier to express, analyze, and present in data models (good, old, Entity-Relationship Diagrams — ERDs — or the classier Object/Class Diagrams of the UML) than in simple sentences. Seeing these user requirements represented in the models helps the business community uncover other, missing requirements that are related. This view also unveils inconsistencies in a set of requirements that are not visible in the textual representation.
Just for clarification, I am not talking here about the technical, physical data models that developers often would like the business community to sign off on. I am referring specifically to the non-technical, business-focused representation of data components that the business community can relate to. The business community typically does not particularly care whether your model is perfectly "normalized" (whatever that means) or not. They do, however, have a vested interest in whether an "Order" can have more than one "Ship-To" address and whether or not a "Customer" can have multiple "Accounts" — and that is just the tip of the iceberg.
Is There Anything Else?
Actually, there is a thundering herd of other modes of representation that might be applicable for your requirements. It is your job, nay, your sacred duty as the one responsible for capturing, clarifying, confirming, and communicating the user requirements, to expand your toolkit to include the mode best suited for each individual requirement. Your goal is to ensure that the business community and those involved in developing and delivering the solution share a common vision of what each and every business requirement really means in all aspects and incarnations. To achieve that goal, you need to have a fiendishly large business analysis toolkit.
