One of the most important stages in software development is specifying requirements for the future software. Different approaches and tools are used for that. Almost all of them are helpful and allow to build a good product. But…
At the same time in our practice we faced the fact that majority of those approaches and tools sometimes are too “heavy” and do not allow to stay flexible when planning, projecting, presenting concept and develop software.
And flexibility and ability for customisation appear to be very important for almost every business.
That is why I have decided to describe the scheme which is applicable in different cases when building software from scratch, extending existing application with new functionality and even when planning optimisation of offline processes.
Presented scheme(diagram) could be used as a basic template for specifying all elements of business processes which need to be automated and/or optimised.
It may become a foundation of technical specification for the development of any business software application(as far as it always consists of processes and it elements: participants, tools, relations etc.).
So let’s check what the scheme is about and what it contains.
When I prepare any specification or follow someone’s requirements the best way to check it is to use ‘From left to right, from top to bottom’ principle.
So at the top of it I put the time line arrow which gives an overall understanding that all described activities below are time dependant.
This diagram describes an hypothetical Functional System, which called A, with several Functional Modules 1, 2 etc. (those three black dots mean that it is possible to extend the scheme whenever it is necessary). Each Functional Module contains Functional Sections, that cover set of activities of Processes that we expect to automate and/or optimise. Img. 1
In this example I shown two Roles. Each of them has a description on the scheme, and with a help of visual border it shows what actions this Role execute within each of the business process.
Colour coding is also helpful but not obligatory. We can show interactions between different participants of the same business process with arrows, it can connect one specific action with another one or can display general connections.
Background process is a type of the process that is executed either by third party or should have an autonomous nature within our system (like generating of the document, sending a report or something else). Img. 2
It is very easy to read the scheme:
we can see that it describes 3 business(or any other kind) processes in which two Roles are involved. Role 1 ( it can be a manager or any other professional) does three actions within Functional Section 1.1 after that Role 1 and Role 2 execute specific actions within Functional Section 1.2 (these actions can be done at the same time) , after that Process 2 follows (some background activities appears during that), and so on…
Of course when we describe not hypothetical but real system it is more interesting to build and read such scheme. Img. 3
I also suggest to have some descriptive information on the scheme, like overall description of the system, its modules and sections(if exist). It would be helpful to have listed all documents formats, and third party services that might be involved. Img. 4
I listed several crucial principles for the business processes diagram(Img. 5):
- It should be clear for any person who is not familiar with the system and will understand it without any ambiguous meanings
- The way how the scheme is prepared should make it self-explanatory and intuitive (of course that is expected on the level of presented details)
- The scheme should allow engineers(or other specialists) to specify it with more details using and explaining existing elements.
- The scheme should allow to use its parts as independent cells(for any specific purpose, like projecting and planning a software module for a part of the system’s business process )
- And another important principle, the scheme should be potentially compatible with any other schemes as a generator of Input or recipient of Output(for that there will be a necessity to extend the descriptive part with unified table of meanings).
As a result your technical team should receive a scheme that allows them to make technical decisions and choices: like technology stack for future software, type of its architecture, possible risks when working with other systems etc.
Another useful fact that it is possible to include this diagram in the official documentation of your software product which will definitely add it the value.
Please share if liked and let me know if you have any questions or would like to receive an editable version of the diagram. Thank you!
COO, YSBM Group
Request free consultation