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.
0 Responses to “Communicating requirements is vital”