I have recently been involved in a project that has been ongoing for the last 18 months. In that time, a lot of documentation had been developed and over 80 use cases have been written. The problem is however, that despite this activity, the system development had not progressed and the project is now facing a fast approaching deadline. So, the team is now trying to develop requirements specifications, prototype and build of the system all at the same time. Big Challenge! Aaaargh!
The project manager does not like uses cases and has decided that a process orientation modelling approach is required to meet the deadline. The approach is to develop business process maps from the user pathways, document the information flows, develop prototypes and then build the system. Use cases are “banned” and process mapping is the key focus for Business Analysis and the BA team.
As a BA, use cases have been the main way to capture functional requirements for a system, so at first I was a little perplexed. I thought to myself, “if we don’t have documented requirements specifications (via use cases or an alternate method), then how will the developers know what to build, how will the clients know we have the requirements right and what requirements will we test the system against”? Will process maps be enough?
Anyway, I started to map my processes and sub processes for the system. Myself and the rest of the BA team are working side-by-side with the information architects and developers and as each process map is delivered, a prototype is built and shown to the client area. Sign off and development begins (all within a week). It’s a hectic schedule but it seems to be working.
The business maps are slowly uncovering the business requirements and are a key communication tool for the project team and business area to discuss the “current” and “future state” requirements for the system. The process documentation is highlighting the inputs, outputs and document flows for the system and importantly, the client understands this type of documentation and is therefore able to quickly sign-off on the processes.The project is now gaining some traction and we are progressing well along our time-lines and meeting the deliverable for each stage of development.
I must admit that when I look at the node map for the business processes and sub processes, it does look strangely like a use case “context diagram” and the documentation does indeed specify the functional requirements but as long as we don’t format these documents as “use cases”, the project manager is happy. For me, I guess these documents are not exactly use cases however a “rose by any other name would smell as sweet”.
So this may be a different take on documentation of system requirements for the team but the client area is happy and so far the developers are comfortable with the level of requirements specifications contained in the process maps and associated documentation.
Hi,
This story points to an oft overlooked element for requirements. The task is not only about documenting the requirement it is also about communicating it. And as my wife often reminds me - communication needs 2 people and sometimes we need to be flexible around the vehicles we use to communicate.
I find that too many BA’s push the communication vehicle they are comfortable with, rather than ensure that the requirements are accurately communicated. Sometimes the client have selctive hearing and can only hear the message via the vehicle they are comfortable with.
I applaud your flexibility.
This same thing happened to me on a project a couple of years back. Use cases were banned and process flows were mandated. However - a use case shows the steps (or process) that an actor employs in order accomplish a goal.
So process vs. use case is just a name.
The reality is that the details of a use case can be documented as a use case document (verbose) or as an activity diagram or process flow. Many people like process flows because of its visual properties.
The one drawback I found with using activity diagrams or process flows instead of use case specifications is the level of detail. Most descriptions of activates/steps in a process flows tend to be very brief whereas in a use case more detail is usually added.
Thanks for sharing your experience!
- Adrian
Thanks for the post. What kind of techniques and tools did you use for process modeling? (such as Aris, metocube, visio, etc…)