Four Business Analysis Techniques I Always Use in my Project

Making a move from digital marketing to business analysis and the product was a big leap for me. Given the different job responsibilities and required skillsets, this job switch not only changed my career path (partially), but also drove me to think more about how to fulfil my “skills matrix” to get on with my new role. Whilst some fundamental skillsets that I have gained in digital marketing are transferrable, such as research skills, data analysis techniques and technical writing skills, there are quite a few other essential skills I should learn as well.

Without any technical background, working as a product manager (with a focus on the business analysis) in a techie team always makes me reach the limit of my interest in technological matters easily. However, if you want to ensure that the team understands the requirements from both the business and development perspective, you have to get yourself conditioned in such a “technical environment” by bringing in great business analysis outcomes. Since many developers have great capabilities to screen out “distractions” and “noises” (all business-related) in project exploratory discussion. Instead, they will mainly focus on system architecture, security implications, and functionalities. If developers don’t put themselves into users’ shoes or don’t have the mindset of adding value to the client’s business, the solution won’t be successfully implemented. Therefore, it’s the business analysts’ job to translate business requirements, solution requirements, stakeholder requirements and transition requirements into the artefacts that the development team could easily comprehend. Depending on the nature and the complexity of the project, not all business analysis techniques are equally important so some may not be used throughout the project. Below are the techniques I always use in my project. Part of them is transferred from my digital marketing skillsets while others are applicable for specific purposes.

 

Four Business Analysis Techniques I Always Use in my Project

Four Business Analysis Techniques I Always Use in my Project

1. Business process modelling 

Organisations are in an attempt to harness the digital transformation in order to improve efficiency and productivity. When they start thinking about implementing a new solution to automate, standardise and streamline the business process, they are inclined to the idea of simply matching their needs with the features. For instance, to describe a requirement as “I need a payment function so users can pay for product”. From a development perspective, the development team will need to think about various scenarios and potential implication in terms of user interface and system interface. Therefore, using business process modelling, in particular, in a legacy project, can be really helpful in visualising the sequential steps of the execution process and analysing the gaps between existing business process and future business process. The approach I always use is to define and design process with clients, conduct technical analysis and implication with the team and finalise the modelling with clients. With the assistance of Business Process Modelling Notation, both clients and my team are able to understand the workflow and interactions.

To understand the essentials of BPMN: https://www.lucidchart.com/pages/bpmn-bpmn-2.0-tutorial

To start using BPMN Tool: https://app.diagrams.net/

2. User persona

A persona is defined as a fictional character or archetype that exemplifies the way

a typical user interacts with a product. Personally, the concept of user persona may stem from customer segmentation, at least there is some overlapping in the attributes/factors used to describe user behaviour and categorise customers. As a result of conducting user research, user persona makes a great contribution to prompting the development team to think from the users’ perspective and address users’ needs when designing and developing functions. In a typical user persona, demographic, behavioural and psychographic aspect should be applied to reflect user behaviour, the intention of commencing certain tasks and expectations of the user groups. The development team can benefit from user personas in terms of designing information architecture, user journey and system interface.

To understand the essentials of user persona: https://www.usability.gov/how-to-and-tools/methods/personas.html

To access user persona templates: https://venngage.com/blog/user-persona-examples/

3. Use case diagram 

A use case diagram visually portraits the scope of the solution, by showing user interaction and the relationship between the use cases. Unified Modelling Language is most frequently used to describe the notation for a use case. Relationships between actors and use cases are called associations. In a typical use case, there are two commonly used associations: extend and include. While the “extend” relation allows for the insertion of additional behaviour into a use case, the “include” relation represents that certain functionalities can be used in another use case. The development team will need a use case to understand the functional behaviour in pre-conditions, the flow of events, post-conditions when designing system interface and functionalities to satisfy the desired outcome.

Source: https://book.akij.net/eBooks/2018/September/5b8a80dd494ce/BABOK_Guide_v3_Member.pdf

To understand the essentials of use case diagram: https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-use-case-diagram/

To create a use case diagram: https://creately.com/diagram-type/use-case

4. Data flow diagram 

Data flow diagram depicts the entities, attributes, classes and the relationship among the data objects. In order for both clients and the development team to understand the dataflow, my data flow diagram is usually supported by textual descriptions. Entities, attributes and relationship association are three key elements in a typical data flow diagram. The entity either represents something physical, usually, an organisation and a department, or something abstract, like an event (making an appointment, making a payment etc.) Under entity, you will need to put the data attribute, which defines particular characteristics and information associated with the entity. Relationship between entities describes the structure of the data model, indicating how data flows and the number of occurrences allowed in each relationship. With the support of data flow diagram, the development team can ensure the logical design of data represents business need by constantly reviewing the data model. Meanwhile, the diagram may also uncover the new requirements and solution gaps which have been identified during the requirements elicitation process.

To understand the essentials of data flow diagram: https://www.lucidchart.com/blog/data-flow-diagram-tutorial

To create a data flow diagram: https://creately.com/lp/data-flow-diagram-software-online/

Please follow and like us:

Leave a Reply

Your email address will not be published. Required fields are marked *