Using Business Process Models as the source for software requirements

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.

Comments

• Anonymous
  July 16, 2008
  The comment has been removed

• Anonymous
  July 16, 2008
  The comment has been removed

• Anonymous
  July 17, 2008
  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?

• Anonymous
  July 19, 2008
  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.

• Anonymous
  August 04, 2008
  I have tried to do this and it does help. However trying to get others to understand they cant just skip straight to the information or technology block is hard. People are averse to processes where I work and dont even think about capability. Your diagram is a nice succint way of showing this common sense.