If you work with requirements, you have to work with descriptions of processes or workflows which satisfy requirements. What makes a relevant workflow specification or model?
Let’s start with the basics:
“The workflow concept has evolved from the notion of process in manufacturing and the office. Such processes have existed since industrialization and are products of a search to increase efficiency by concentrating on the routine aspects of work activities. They typically separate work activities into well-defined tasks, roles, rules, and procedures which regulate most of the work in manufacturing and the office. Initially, processes were carried out entirely by humans who manipulated physical objects. With the introduction of information technology, processes in the workplace are partially or totally automated by information systems, i.e., computer programs performing tasks and enforcing rules which were previously implemented by humans.” 
A workflow is a description of what people and machines do, with a focus on showing separate units of work, usually called tasks, activities, actions, or such, and specifically the sequence and synchronization across these units (what’s first, second, third, what waits for what else to be done, what needs to be done in parallel, and so on). It is safe to say that a business process is a synonym of workflow .
Although there are many ways to describe workflows , i.e., workflow modeling or specification languages, knowing them is necessary, but far from sufficient to make relevant workflows for a requirement or a goal, within and across organizations, industries, and markets.
So, what should you want to see or include in a workflow specification?
Think about this in terms of the kinds of questions you want a workflow specification to answer. I group these questions into “layers” of a workflow.
Each workflow has one or more of these layers:
- Communication layer, describing:
- Who communicates with whom?
- What are they communicating about?
- What is the purpose of the communication? For example, joint work, negotiation, exchange of paperwork, etc.
- Does that communication have a pattern, which is repeated over and over?
- Incentives layer, describing:
- Who gets what benefits from whom?
- How important are these benefits for them, relative to their other benefits?
- Who has which costs (loses)?
- How important are these costs for them, relative to their other costs?
- Financial layer, describing financial flows between the parties involved;
- Regulatory layer, describing steps done because of regulatory rules or guidelines;
- Technology layer, describing which, how, and why IT tools are used in each step;
- Base layer, describing steps which do not belong to other layers.
Each workflow can be over several or all layers, and is made of:
- Steps, which can be, for example:
- Tasks to complete;
- Goals to achieve;
- Approvals to obtain;
- Reports to make;
- Tests to perform;
- Relationships between steps (for a deeper discussion, see ), such as:
- Sequence (next step, previous step);
- Parallel steps;
- Alternative steps;
Each step’s description or definition should, ideally, answer the following questions:
- Who (which position in the team or organization) is responsible for doing that step?
- What should be done or achieved in that step? How should the step be done?
- When should that step be done (which conditions need to be satisfied)?
- What are the inputs (documents, approvals, etc.) needed to start a step?
- What are the outputs of the step?
- Which criteria and measures are used to evaluate how well the step was done?
- Georgakopoulos, Diimitrios, Mark Hornick, and Amit Sheth. “An overview of workflow management: From process modeling to workflow automation infrastructure.” Distributed and parallel Databases 3.2 (1995): 119-153.
- Decker, Gero, et al. “Transforming BPMN diagrams into YAWL nets.” International Conference on Business Process Management. Springer, Berlin, Heidelberg, 2008.
- Van Der Aalst, Wil MP, and Arthur HM Ter Hofstede. “YAWL: yet another workflow language.” Information systems 30.4 (2005): 245-275.