Archive for the 'Business Process Modeling' Category

Requiements Management post script

Published by
Maria Murphy
at 16 October, 2007 in Business Process Modeling and requirements. 0 Comments

Well I’ve been a bit quite of late as I have been on some much needed rest and relaxation so I have sadly neglected my blog.

I have had a number of comments with suggested tools to consider and comments wanting to know which requirements management tool we choose. After a couple of months of assessing different requirements management applications we did propose Holocentric to the management team. We liked its requirements management flexibility, business process mapping, ability to map relationship and traceability.

We hit a wall though when it can to implementation and unfortunately have had to go back to our previous tools. There were two main barriers.

1. Cost: Set up costs of initial training and licences required to to use the product (these costs were not part of the original project budget so would require new funding).

2. Downtime: We had invested so much time already using the current tools that to convert our current work to the new software would mean a lot of rework to get to the same point and extend the project time-lines.

So, whilst it was too late for this particular project, we now are aware of other tools out there and can captilise on these for our next project.

Business Process Modeling

Published by
Maria Murphy
at 26 July, 2007 in Business Process Modeling. 4 Comments

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.