Requirements elicitation is a critical, yet under-appreciated, activity. A core capability of business analysts, the ability to get the customers to describe what they want, and need, is both a science and an art. Requirements elicitation requires equal measures of careful planning, situational awareness, acute listening skills, business acumen, and a kind of optimistic tenacity.
I have long taken for granted two basic principles of requirements elicitation.
First: a rule: The goal of requirements elicitation is to first understand, and then document, the needs of the business for a software solution.
Secondly, a process: if you want to understand a system (be it a software system or a system of business processes), look first at the business problem that it solves. Look second as how people use that system to solve the problem. Look next at the information that moves from one point to another. Look last at the technologies that have been identified and consumed by the system.
To be honest, I don’t know where these notions came from. I don’t remember reading them in any book, although I suppose that I may have done just that. They are assumptions that I have used, for a long time, to organize my thinking about software requirements.
Yet when I went looking for industry sources that discuss the need to trace a requirement from the business problem, through business process, I could not find any.
The "Guide to the Business Analysis Body of Knowledge (BABOK)" published by the International Institute of Business Analysis goes into some depth about requirements elicitation. in the BABOK, the authors discuss many techniques for getting users to talk, including Brainstorming, Focus Groups, Job Shadowing, and JAD sessions, to name a few. Unfortunately, their description of the traceability matrix, where a requirement is traced to something valuable, is sparse IMHO (This is true for BABOK version 1.6. Perhaps the upcoming version 2.0 will provide examples?)
To my surprise: there is no mention of using a model of the business process as the source for software requirements! As far as the BABOK is concerned, requirements come from people… not from a process model that may have required the consensus of six or sixteen people to help build it. (Perhaps I missed it. If there is such a reference, in v1.6 of the BABOK, please reply with the section where I can find it).
Of course, this only meant that I needed to search out other sources of information… Someone, somewhere, must be talking about using business processes as the source for IT software requirements.
Now, many of you are probably saying: what about use cases? Aren’t they simply descriptions of a business process, specifically for describing software requirements?
The answer is: go up a few layers of abstraction… away from the software… I’m interested in seeing how the subprocesses, from an enterprise viewpoint, are driving requirements. I’d like to see how specific activities in a BPMN business process model drive requirements. The requirements can be captured and shared in the form of a use case, or a big list, or a database in Visual Studio, for all I care. But we don’t start with the use case. We start with the process.
Or at least, I do.
Do you trace your requirements back to business process models? If so, why? If not, why not? I’d love to hear from others.
Nick – am an avid reader of your blogs (and have been nodding my head in consensus in most of the cases). I agree with you that requirements should be identified from business process models for all IT applications (which solve a business problem). I have not seen any bible-like book talking about the same, but it is more of a practice being followed.
We believe in creating rich process models, identify use-cases from the above said rich process models, integrate data entities information (as needed) and elaborate the identified use-cases or the requirements using biz rules, alternate paths and data journals. These elaborated requirements are managed (traced to downstream phases) and usage of technology can ease things. There are tools that associate the elements like user interfaces, data journals, biz rules to use-cases and generate reports. As an addendum, these elaborate requirements can aid in automatic generation of test cases.
The technology also helps in seamless transition of identified and elaborated requirements (along with associated elements) to tools like ReqPro, DOORS etc. On the top of this, functional test cases can be traced using this method.
To top it, we have been trying to generate automatic estimates based on the identified requirements from business processes (definitely complex algorithm but this can certainly be done).
Cheers
Tycoon
PS: I lead a set of about 25 consultants who excel in this approach.
Excellent response, Tycoon. Thanks for contributing. Clearly, I’m not nuts ;-).
But I wonder why this is not described in a book that I can find and cite. Perhaps I’m not looking hard enough?
If anyone knows of a good book or authoritative journal article that discusses traceability from business processes (at the activity level) to software requirements, please leave a note.
— Nick
Nick
I read a thesis last year that argued that requirements gathering should not be assumed to start with a process.
I had a feeling that the article was called "the case for use cases" but I googled it and couldn’t see it.
Anyway, as I recall the argument is to provide functionally oriented tools as enablers for one or many processes.
At the time this also lined up with my project which was looking at delivering tools to a third party sales force – enabling them without telling them what do do.
The idea for me was of a business context use case rather than a process map.
I think the source of the process foundation you are working from is probably Michael Hammer’s ‘Re-ngineering’ which advises businesses to take a process first appraoch to organising themselves.
Yes? No? Maybe?
Hi Craig,
Thanks for the note on ‘the case for use cases.’ I may agree with the author of that article more than I disagree.
You see, I believe that software is not composed of requirements. It is composed of features. The features are not directly tied to a process, but serve to meet the needs of a process. They are independent abstractions.
The use case does a good job of describing part of a feature from the perspective of a single interaction. It is a very small building block, and that is both its strength and its weakness.
I’ll blog on use cases soon.
As far as Hammer, I have read some of his work, but not nearly enough to have influenced this fundamental assumption of mine. I had a friend give me one more of Hammer’s articles just last week, in fact.
Regardless, I’m modeling on the basis of identifying requirements from processes, and then describing features that meet the needs of those requirements. Use cases are a mechanism to elicit the requirements.
I have tried to do this and it does help.
However trying to get others to understand they can`t just skip straight to the information or technology block is hard.
People are averse to processes where I work and don`t even think about capability.
Your diagram is a nice succint way of showing this common sense.