Process analysis is used in the Thinkwise Project Methodology as the way to elicitate the requirements. By capturing the primary process of a company, it is way easier to determine what the application has to do to support this primary process.
The processes are specified using BPMN 2.0.
Processes
The primary process can be specified in the Software Factory using activities called tasks.
This primary process shows 3 partial processes. Each partial process could be the responsibility of one or more different actors. This is why the primary process does not have any lanes. When we zoom into the first partial process, we see that a lane is introduced:
This small process shows two tasks, Make sandwich and Eat sandwich, performed sequentially. The lane indicates the responsibility for the tasks.
To refer to the follow-up partial process, a reference can be made to the next partial process using a black-box pool. Simply typing the id, the number or name of the other process is sufficient to create a reference in the black-box pool.
If a set of tasks is too complex to put in a diagram, a sub-process can be introduced which has its own diagram.
The subprocess does not require a lane, since it always originates in a specific lane.
It is not advised to create subprocesses within subprocesses. Referring to partial processes within a subprocess is also not endorsed.
If a subprocess is used in multiple diagrams, it can be defined as a call-activity.
Call-activities can be recognized by their thick border and are reusable in multiple diagrams. Typing the id, the number or name of the called process is sufficient to create a reference.
Requirements
The idea is that tasks in a BPMN model can be seen as user requirements. The user requirements are actions the user performs to fulfill a certain goal in the primary process. The processes are stored as a hierarchy of user requirements in the Software Factory.
In this hierarchy, it is also possible to add business requirements to convey the goals and targets. Entire requirement hierarchies can be copied, deleted and moved using the corresponding tasks.
Every requirement is provided with a unique ID that will remain constant throughout the requirement lifecycle. The description of each user requirement can be specified, notes and appendices can be added.
When a requirement ID is mentioned within the text, it will automatically introduce a cross-reference to quickly navigate to the referenced or referencing requirement.
Ambiguous expressions can be defined and will be highlighted in the requirement text. This is especially useful when a certain ‘forbidden word’ is identified during the analysis.
Most importantly, the functional requirements can be specified. Up until now, only the goals and the processes have been registered. Those processes do not describe in which way a system has to support those actions. Every ‘leaf’ user requirement, every atomic task that is not a partial process or subprocess, can be decorated with functional requirements which describe what the system has to do to support the user.
System requirements can be prioritized and can be added to a module, which is a logical categorization of system requirements. Modules do not have to be the same as partial processes. I.e. there can be a module called Base data which is used for all base data and supports system requirements of various processes.
Baselines
The processes and requirements are often presented to the stakeholders for verification purposes. To create a report of the processes and requirements, a baseline will have to be made.Baselines are created with a task. These baselines are snapshots of the current state of the processes and requirements. This includes the diagrams. For this purpose, the Software Factory has to create an image of each diagram. This is done using the context menu in a diagram and selecting ‘Publish diagram’. There’s a prefilter to check for unpublished diagrams. Diagrams will revert to the unpublished state when certain modifications to the requirements are done which affect the diagram visually.
The status (new/modified/unmodified) of each snapshotted requirement is based on the previous baseline, selected in this task pop-up. A baseline can be set as head baseline. The status (new/modified/unmodified) of each requirement is determined by comparing the requirement to the head baseline.
It’s possible to change the order of requirements in the baseline for the report and exclude requirements from the baseline report. Requirement ids can be either included or excluded. A preface, version and author can be set for the report.
The report will create a chapter for every primary process, partial process and subprocess. Paragraphs are created for every task and system requirements are added as bullet-points at the paragraph.
Design
The next phase in the development process is the design of the application. A future blog post will discuss this feature.Final notes
BPMN 2.0 is an extensive model. With the release, only a subset of the elements will be available in the Software Factory. A ticket in TCP can be created if additional elements are required.Keep in mind that the process analysis is not a mandatory part of development with the Software Factory. Existing projects can continue to rely on paper versions of the process analysis or a different project methodology altogether.
And yes, the diagrams used in this blog are probably not BPMN 2.0 compliant. They’re just examples, no need to get all worked up.