Archive for the 'Business Process Modeling' Category

Communicating requirements is vital

Published by
Maria (Murphy) Horrigan
at 3 November, 2008 in Business Process Modeling, Business analyst and communication. 0 Comments

As BAs, our requirements analysis is not done by simply sitting down at our desk and developing requirements based on a template we used previously. It can only be done by getting out and talking to users about what they require the system to do and then building systems that satisfy these requirements.

Ultimately our requirements analysis results in a specification which clearly describes what needs to be built. The communication of this specification to users and developers is where it gets tricky as there are many different ways that requirements can be specified. There are models, business process maps, use cases, prototypes and simulations. There is no one right path and we need to use the tools and techniques most appropriate to our audience and context.

If the users or the business do not understand what we are specifying in the requirements, then how can they sign off on the specification? Equally, our developers need to use the requirements specification to build the system  and need to be able to understand what the implemented system will look like.

Whilst I like Use Cases, as this was the foundation for me when first learning how to do requirements specifications, I have found more recently, that business process modelling notation (BPMN) is perhaps a better way to communicate to my business user audience. So its not about me and how I like to write requirements, its about my audience (business users and developers) and finding a tool or technique that communicates the requirements in a clear manner and decreases ambiguity.

The communication of the requirements specification in this BPMN visual form is suited to the business user as it is business orientated. Whilst this notation is readily understandable by business users, it also speaks to the technical developers and can help to bridge the gap between business process design and process implementation.

As a communication tool, BPMN clearly shows the end to end process, where the user interacts with the system and how the process may change from the current “as is” process. More and more, the business area is being asked to take an active interest in the development of their business systems so we as BAs need to ensure our tools facilitate communication about requirements.

Agile driven requirements

Published by
Maria (Murphy) Horrigan
at 14 October, 2008 in Agile, User centred, agile anlayst, Business Process Modeling and business analysis. 0 Comments

 One of the biggest challenges for me when developing requirements specifications, is that requirements can and do change and I’ve often struggled with the prescriptive “waterfall life-cycle” approach to software development. This sequential process does not guarantee success of the project nor does it decrease risk, in fact it is often the opposite as this process does not support change or vital feedback from users and the business.

I wrote about the BA life-cycle awhile back when I embarked on a project that was stalled and despite extensive analysis, the project had not yet begun development and we could not get sign-off or agreement on the requirements for this complex system. We had hundreds of Use Cases, lots of Architecture design documents, User scenarios and volumes of analysis and feedback gained over two years of review of the problem to be addressed, in short, the bureaucrats had taken over and we were in analysis paralysis.It was “groundhog day” as neither the business nor the development team had a clear idea of how to move forward. To jump start the process we adopted an agile approach.

The Agile Alliance Manifesto defines four values of encouraging better ways to develop software:

  1. Individuals and interactions over processes and tools - the most important factors to consider are people and how they work together. User and Stakeholder engagement is vital
  2. Working software over comprehensive development - we are there to create a system, not documents (although it is noted that documentation is important for our understanding of the system and some documentation is required to understand how and why a system was built). As Jonathan recently asked in his blog does paperwork really add any value?
  3. Customer collaboration over contract negotiation - customers are unlikely to be able to fully specify the system they want, they will not get it right at first and they are likely to change their minds, therefore communication  and collaboration is vital.
  4. Respond to change over following a plan - I know all the project managers who cling to their Gannt charts will cringe at this but change is a reality and the software development process must reflect this.  You need a project plan approach that is flexible

The key trigger to our move to agile was that the Change Manager took over responsibility for Project Lead. Myself and my colleague Matt in the design and analysis team, were charged with the task to  think differently, be innovative and just make it happen. Given the User Centred Design focus of me and Matt and our colleagues, its not surprising that we focused on the people orientated issues, the Users understanding of the business processes and followed analysis techniques that readily supported change and flexibility. We used storyboards, iterative prototyping and business process mapping notation (BPMN) to convey and confirm the requirements and before long we had a working prototype that the business had approved and sign-offed.

We have embarked on three new projects since this original foray into agile, and are refining our documents and processes. It’s quite exciting as many of the developers and business teams we are working in, were at first a little nervous about the “agile” approach as they are traditionally quite risk adverse, however they are now seeing real benefits. Matt recently blogged about the tools we are using to specifiy design and requirements. These tools and techniques are easy for the business to understand, flexible enough to meet their changing needs and allowing greater collaboration. To the bottom line - this is saving them time, they understand what they are signing off on  and its also giving them a more useable end product.

Requiements Management post script

Published by
Maria (Murphy) Horrigan
at 16 October, 2007 in Business Process Modeling and requirements. 1 Comment

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) Horrigan
at 26 July, 2007 in Business Process Modeling. 5 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.