Business requirements are a highly effective tool that can optimize routine processes, increase customer conversion, process arrays of individual unique information and provide the client with a resource advantage (save on the number of man-hours spent on software development and prototyping).
You can read more about this in the blog material “What is an effective way to identify requirements in IT projects“.
As noted, the effectiveness of identifying requirements depends on communication between all participants, so it is important to choose an effective language in this regard. Recently, BPMN notation has become a popular option for communication between development teams and stakeholders, where the biggest advantage of using it is that it is easy to share, has a certain boundary set of icons, and most modelling tools widely support BPMN. It is important to add that the use of BPMN also complements the requirements in the form of UML diagrams (activities, use cases or sequence diagrams) and provides new opportunities, for example, the creation of common algorithms for working in the form of streams.
The widespread using of BPMN is known through the Business Process Management (BPM) approach, but its use in software development depends on how well thought out all business processes are end to end, but it is almost impossible to take this into account in large projects. Therefore, in such cases, traditional management (BPM) will not help and an agile approach is needed. We are talking about the fact that flexible BPM (agile) is a business process methodology that allows businesses to automate known stages of everyday operations, leaving space for solving so-called non-format tasks or taking into account unplanned factors.
Project managers need to analyse BPM in terms of inputs, processes, and outputs. Inputs are variables — they can include queries you don’t expect, data models that change, and so on. Flexible BPM allows you to enter new unscheduled input data and provides a structure for their processing. This is again both convenient and effective: you do not need to build a separate algorithm that would take this into account.
This flexibility provides customers with quick analysis, understanding and making the necessary adjustments to the workflow. For this purpose, BPMN-based platforms offer effective solutions that are a reasonable alternative and a compromise between ready-made program code and the high cost of developing special programs from scratch. Separately, it should be noted the possibility of rapid development of these individual business applications and providing opportunities for those who work with them to also become developers.
How does agile BPM work?
Agile BPM works as the basis for your processes. It offers specific methods that companies can use to manage their business processes. This method is something like a whiteboard or Kanban table (visualize all processes) that can be used to implement agile BPM principles.
For an agile BPM to work, team members must be able to work with unstructured or ad hoc work requests while following either a sustainable workflow or modifying it on the go.
Two causal models are the basis of why agile BPM is needed and explain how it works:
- A causal model of operation (IT operations)
Reason: This is due to standard (routine) procedures, such as batch uploads or reconfigurations. Due to constant changes in systems, these procedures are not routine, as more knowledge is often required to complete the process than what is indicated in the documentation.
Effect: Agile BPM will allow you to adapt the process of performing procedures so that you can incorporate additional knowledge needed for successful execution.
- A causal model of development (application delivery management)
Reason: The software development process requires much more collaboration than specified by the project office processes. You may need to split one task into several stages so that more people can contribute to the project at the same time.
Effect: Agile BPM will allow multiple teams to work simultaneously on a project, allowing project managers to break a single task into smaller chunks so they can complete it faster than expected.
Wouldn’t it be easier to sit down and work hard to compile a complete list of required tasks and their dependencies so as not to disrupt the traditional process? You can try to do this, but, as experience shows, it is much more difficult to do it in reality than in theory. After all, you can spend a lot of time and effort planning for all the contingencies you thought about and still miss something.
If this happens on a larger scale, it is easy to lose control over all stages of the project. Imagine that a manufacturer of telecom equipment worked in the business of providing voice services, but decided to expand its activities to provide television services. The probability of encountering inconsistency in the processes of providing heterogeneous services in the context of individual autonomous processes is much higher than when you extend a process that has already been streamlined and work is smooth. Business growth is often a catalyst for implementing flexible BPM.
How can an organization implement agile BPM?
If you want to implement agile BPM in your organization, you will have to consider the following nuances during the development process:
- The ability of team members to change things on the go. You should be able to change small parts of the process, like assigning a new team member or splitting tasks into smaller chunks.
- Agility mentality. Your team needs to understand that processes can change — and that they have the power to change them.
- Precise evaluation process. If your processes change, you should be able to assess whether this change has had a qualitative outcome.
What do BPMN notation and requirements management look like in a working diagram?
In simple words, the requirements management process using BPMN looks like this.
- The requirements management process begins with identifying and defining a problem or opportunity (actualizing the customer’s vision), and what exactly the future software should solve.
- Then there is the collection of requirements from stakeholders (which include users, customers and other participants) who will be affected by the system. These requirements are then analysed, documented and streamlined, and any inconsistencies or ambiguities are eliminated. This stage is usually accompanied by Stakeholders Request (STRQ) artefacts, which must be traced to the User story (US) artefacts
- The second-to-last step in the requirements management process is designed, as it contains BPMN visualization of ordered requirements to ensure that they are complete, consistent and feasible in practice. This stage has a realistic model of the graphical interface (mock-up or GUI) accompanied by artefacts, which must be consistent with the BPMN Workflow
- The process of verification or prototyping (PoC) using low-code is completed to efficiently use developer resources and verify the viability of the prototype among a narrow circle of friendly users.
To understand this in more detail, let’s pay attention to the visualization of the process in requirements management using BPMN from the authors of the study «An Approach of Software Requirements Elicitation Based on the Model and Notation Business Process (BPMN)»:
1) Problem Defining: the activities of business analysts aimed at understanding the task at a high level (a broad context without details). Delineation of scope, aimed at coordination with the options involved.
2) Macro definition of the involved: In this activity, business analysts need to identify, in addition to the main stakeholders, one or more owners of the process. The stakeholders are responsible for ensuring the consistency of the organization’s strategies and must provide ready-made algorithms as answers to possible doubts.
3) BPMN modeling: here process modeling is complex and requires the effort and dedication of those professionals involved in the development since it is a graphical diagram representation of reality. This top-down simulation begins with macro processes to define organizational strategies. After clarification, business analysts identify corporatization procedures, and only after that you can start displaying actions, which assign roles and determines the degree of responsibility for the correct execution of each type of activity (a separate BPMN Workflow).
3.1) Activities Description: consists in creating a general scenario of workflow for each manual or automated activity that must be performed in the process, in particular, including components such as cause or start of the flow’s thread, subjects or active elements and thread (operations, actions, etc.), rules or flow direction control conditions (prechecks, sets of responses, etc.), objects or passive elements of the flow (data, models, etc.), measuring instruments or error handling, flow results (successful and unsuccessful) and schedule of the flow (synchronised, asynchronised, based on events, manual, etc.).
3.2) Definition of the involved: consists in identifying all steps involved in the flow (fetching data, creating a database record, API call, message processing, etc.). This identification should identify all persons who in one way or another influence the development and architectural solutions of the stream or depend on the results of its work.
3.3) Process border Identification: the activity aimed at determining the existence of other systems or even other processes that need or do not need to be mapped. This identification should identify all persons who in one way or another influence integration decisions, and those who affect the flow (provider or southern interfaces) or are dependent on it (consumer or northern interfaces).
4) Functionalities Description: consists in defining algorithms, and functional and non-functional requirements for each defined step of the thread (input and output data, algorithms, etc.) to meet the needs of the developers of the simulated stream (Workflow BPMN).
It is important to note that the proposed approach provides a ready-made dataset in the form of a file in the BPMN 2.0 standard, which can be used to write program code (for example, automation in the Camunda platform) or even automatic software creation through the use of low-code technologies (for example, creating high-performance applications in the MEF.DEV platform.