Using Business Process Models as the source for software requirements

re: Using Business Process Models as the source for software requirements

Tycoon — Thu, 17 Jul 2008 07:46:53 GMT

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.

re: Using Business Process Models as the source for software requirements

NickMalik — Thu, 17 Jul 2008 09:21:52 GMT

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

re: Using Business Process Models as the source for software requirements

Craig — Thu, 17 Jul 2008 16:04:26 GMT

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?

re: Using Business Process Models as the source for software requirements

NickMalik — Sat, 19 Jul 2008 19:22:24 GMT

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.

re: Using Business Process Models as the source for software requirements

Andrew — Mon, 04 Aug 2008 19:10:09 GMT

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.