using data-centric business process modeling for discovering requirements for business process...
DESCRIPTION
Building a process model is a natural part of the requirements engineering (RE) when creating requirements for a computerized system/service to support a business process. When a process in question is workflowable (i.e. a process in which the order and the flow of tasks/ operations/activities can be predefined), there are plenty of modeling techniques, notations and tools that can help in this undertaking. These techniques, however, are of little use for discovering requirements for support of non-workflowable processes in which the information artifacts created in the process (e.g. reports, lecture slides, budget documents) are of more importance than the flow of tasks/operations/activities. Other types of techniques, notations and tools are required in this case. This paper reports on a project of using a data-centric modeling approach supported by a computerized tool in RE. The goal of the project was to test whether the approach could be useful for the task of discovering requirements on a computerized system/service supporting the process, and which and how much of requirements could be captured using it. The process used in the test is a process of course preparation in the author's own department. The paper reports on the environment in which the project has been conducted, results achieved, and lessons learned.TRANSCRIPT
DSV SU/IbisSoft1
Using Data-Centric Business Process Modeling for Discovering
Requirements for Business Process Support Systems: Experience Report
Ilia Bider - IbisSoft/DSV SUErik Perjons, Zakra Riaz Dar - DSV SU
Pre-proceedings - http://bit.ly/1chB3pWSpringer proceedings –
http://link.springer.com/content/pdf/10.1007%2F978-3-642-38484-4_6.pdf
DSV SU/IbisSoft2
Goal
Investigate whether a data-centric modeling technique supported by a tool is suitable for discovering requirements on a BPS systems for a non-workflowable process
1. Can it be used directly in facilitating workshops?
2. Are the results are suitable for discussions with stakeholder that have not been part of the requirements discovery team?
3. Which and how much of requirements can be discovered ?
DSV SU/IbisSoft3
Working definitions
Data-centric process modelingany process modeling technique that permits to start structuring data/information processed in the frame of the process before the details of the flow of tasks/operations/activities are known or decided upon.
Workflowable processa process where the order and the flow of tasks/operations/ activities can be predefined.
DSV SU/IbisSoft4
Project context
1. OrganizationDepartment of Computer and System Sciences (DSV) at SUTeaching (BS,MS, PhD) + Research5 700 student, 280 Staff members
2. Business processPreparing a course occasion(for an old course or a new one)
3. Project teamAuthors + 2 teachers from DSV
DSV SU/IbisSoft5
Process in more details
DSV SU/IbisSoft6
Looking for a tool – High-level requirements
Can be used in facilitating workshops and can represent:
1. Structure of data/information created and utilize2. Data/information flow in the process3. Participant collaboration in the frame of instances4. Categories of users engaged in the process and limitation on
the data/information they can access5. Operations/activities in the process and restrictions on their
order
+ usable for
6. Designing a prototype7. Discussing and recoding process scenarios (cases)
We has own tool that satisfied above but wanted to check whether there is something better
DSV SU/IbisSoft7
Requirements refined
• Availability• Domain-independence • Completeness – have means to express all important
concepts• Comprehensibility – for domain experts• Tasks flexibility –can be used for modeling, prototyping,
scenario testing• Tasks suitability - suitable for the tasks• Usage flexibility - freedom to choose how to use• Coherence - produce a whole
Found no easy available tool that satisfies the requirements – stayed
DSV SU/IbisSoft8
iPB functionality
From “iPB online reference” http://docs.ibissoft.se/node/6
DSV SU/IbisSoft9
Main modeling concepts
1. Process MapA collection of process steps + layout + relationships
2. Process step
3. Step Form – data structure defined for a stepA collection of form fields + layout
4. Form fieldAn elementary unit of data structure
DSV SU/IbisSoft10
Process map
Steps
DSV SU/IbisSoft11
Step form
Form Fields
DSV SU/IbisSoft12
Step form in runtime
Form Fields
DSV SU/IbisSoft13
Process map in runtime
Steps
Business rules – step relationships
Business rules – step synchronizations
DSV SU/IbisSoft14
Process modeling with iPB
• Structure of data/information – Step forms• Data/information flow - References to fields from one
form to another• Participant collaboration - Journal fields• Categories of users & access restrictions – User profiles• Operations/activities – Steps for big blocks, action lists
for smaller ones, showing a field to fill also function as an instruction
• Order – business rules: Steps relationships + mandatory fields
• Prototyping – Runtime system• Recoding scenarios – Runtime system
DSV SU/IbisSoft15
Project execution
1. Facilitating workshopInformal discussion
2. Facilitating workshopFirst draft of a process map + suggestions for the forms
3. Extending the model between workshopsStep forms + scenario recording
4. Facilitating workshopGoing through recorded scenario + suggestions for improvement
5. Further development of the modelBased on suggestions
6. Demonstration and brainstormingin the extended group
DSV SU/IbisSoft16
The modelFirst draft
Final map
DSV SU/IbisSoft17
Comparison
Operation based
Data-centered
DSV SU/IbisSoft18
Difference explained
DSV SU/IbisSoft19
Synchronization explainedSynchronized
DSV SU/IbisSoft20
Analysis of results
1. Can it be used directly in facilitating workshops?Yes based on our own reflections
2. Are the results are suitable for discussions with stakeholder that have not been part of the requirements discovery team?Yes based on the opinion of external domain experts
3. Which and how much of requirements can be discovered ?Those 5 that we wanted based on the brain storming discussion by the extended group. However there are limitations … next slide
DSV SU/IbisSoft21
Possibilities and limitations
Captured• Structure of data/information• Data/information flow • Participant collaboration• Categories of users & access restrictions – User profiles• Operations/activities & Oder• Order – business rules: Steps relationships + mandatory
fields
Not captured
• Stakeholders goals• Integration with other system
Would it work for a more complex project?
DSV SU/IbisSoft22
Thank you for your attention!
Q & A
Ilia Bider, DSV SU/IbisSoftEmail: [email protected]