Business Process Modelling or Life without Use Cases
I recently became 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, that despite this activity, the system development has not progressed and the project is facing a fast approaching deadline. The team is now trying to develop requirements specifications, prototype and build-of-the system all at the same time. Big Challenge!
I am working in an agile environment where there is rapid change and the business needs are evolving, and this needs to be managed. As we know Requirements are never really complete until the project is finished, as the needs of the business will inevitably change over the life of the project’s development.
In this instance, the project manager does not like use 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. The rest of the BA team and I 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.
When I discussed this Case Study with a colleague of mine, he commented that this points to an oft overlooked element for requirements- that of communication. The requirements specifications task is not just about documenting the requirements it is also about communicating them and, as business analysts, we need to be flexible around the vehicles we use to communicate. We should not push the communication vehicle we are comfortable with, rather we should ensure that the requirements are accurately communicated via a vehicle that our clients are comfortable with. This requires flexibility.
The real key to our success in navigating this agile environment has been teamwork and collaboration between the development, analyst and business teams. Without this interaction, between members, our project would not be progressing well. Communication is so important and as an agile analyst, I believe this capability is a core skill in an agile environment.
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.”
Adrian Marchis from Modern Analyst commented on my recent blog about Business Process Modelling and agreed that a “use case shows the steps (or process) that an actor employs in order to accomplish a goal” and, therefore, “process vs. use case is just a name”. He suggested that in reality the details of a use case can be documented as either a use case or as an activity diagram or process flow. He noted that although clients may like the process flow format for its visual properties, it does have one drawback and that is that process flows may not offer the same level of detail found when using use case specifications.
Business process modelling 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.
Maria Murphy is a business manager and information and communications specialist. She has over 10 years senior management experience within the medical/pharmaceutical industry, not-for-profit organisations and government. She has a reputation for innovation, managing change, driving strategy implementation and successfully delivering programs. She has extensive experience in the management of large federal government contracts, project management of large scale ICT business system reviews, development of requirements, systems planning and change management. Maria is currently a consultant with SMS Management and Technology. She is the Regional Lead for a Business Analysis at SMS and provides advice to her colleagues on developing requirements specifications for appropriate IT systems to support clients’ programs and initiatives.
Maria is on the Board of WIC (Women in Information and Communication), is a member of the International Institute of Business Analysis (IIBA), Australian Institute of Company Directors (AICD), The Australian Computer Society (ACS) and The Australian Business Analysis Association (ABAA). She can be reached at [email protected]