Writing Better Requirements

I have to disagree with the event analysis approach as described in this article. The article recommends listing all processes / events in a matrix before diagramming them. No one - whether business or skilled BA - can come up with an accurate and comprehensive list of processes or events without putting them into the flow and context of a process model. So the diagramming should come first, and the list of processes and events is then built through the diagram.

There are a number of good BA tools such as Sparxsystems Enterprise Architect that allow you to build your object repository from the diagrams themselves.

I would also disagree with the statement that BPMN diagrams become unmanageable when alternate paths are included. There is a very good example under the 'Templates' area of Modern Analyst - check the 'BPMN Cheat Sheet' for a great example of a readable yet very detailed BPMN diagram.

The Requirements Solution Specification template link in the article is a nice template - nice to see examples that offer different levels of detail.

Sandy

Hi Sandy,

Thank you for your comments – here’s some background on the paper which might add some context.

When analysis begins, the event table is not a comprehensive list of all events in the system. It is a list of the known events (at this stage) for which the system must have a use case or process in order to respond to the event. Each will be used to model and define a use case or process, depending upon the preferred methodology.

During analysis other events will be found, often using a process modelling technique when the requirements get too complex. In a use case this is usually an activity diagram but DFDs or BPMN could be used. This is similar to the best practice approach to BPMN analysis. Stephen White, who was a member of the OMG standards group developing BPMN 1.0 and 2.0 states that he does not start by producing a process model: “The temptation is always to leap straight in and start modelling. Yet a more considered approach normally pays significant dividends.”

He further states that his preferred approach to BPMN is a service oriented approach “Functional decomposition tends to reinforce the very same silos that a process oriented initiative is trying to break down.” “The trick is to think of the outcomes that are important to the customer and other stakeholders, and then imaging the ‘Services’ that will deliver those Capabilities. They should be the Services that will delight the customer and provide a superior customer experience. These Services will be composed of other Services, but eventually, a Process (procedure) implements a Service.”

A service equates to an event when the user, customer or stakeholder begins to interact with the system and expects a response. This we express as a process or use case to be executed in order to provide the service they want. All we are doing is making a list of these events and naming a process which will meet that need. The next thing we do is a model of that process or use case. We think before we model as Stephen White recommends.

From this description we see that the service based approach is very similar to, if not exactly the same as, an event table approach, supported by activity diagrams within the use case named in the event table.

The second point states that alternative processes in BPMN can lead to the model becoming too complex to manage. We are echoing a common problem that is often raised with BPMN. It is controversial, but needs to be discussed.
Gartner BPM lead analyst, Jim Sinur states; "BPMN for business professionals is just not up to a business level of need. Some folks think that BPMN is good enough for IT and it should be good enough for business professionals. I think the former is true, but the latter is way off the mark. Fortunately a number of BPM vendors are smart enough to support multiple representations, so that both audiences can be happy. I get the idea of standardization for engineers that are disciplined, but not for business folks. If we fully expect BPM to enter the "C suite" and become the business man's best friend, it had better shape up its image."

John Everhard of Pegasystems states: "The BPMN 2.0 specification has been so tightly coupled to the more technical BPEL-based execution model as to impact its usability by business analysts," “BPMN does not allow business analysts to fully describe the full scope of their objectives and intents.

Jan Recker of Queensland University researching the application of BPMN found: “Through this study, we identified a number of critical issues related to the practice of modelling with BPMN in contemporary process management initiatives, for example, the capture of business rules and the specification of the Lane and the Pool constructs.”

Egon Borger (see below) states: “We investigate three approaches describing models of business processes: the OMG standard BPMN in its recent version 2.0, the workflow patterns of the Workflow Pattern Initiative and their reference implementation YAWL. We show how the three approaches fail to provide practitioners with a suitable means precisely and faithfully to capture business scenarios and to analyse, communicate and manage the resulting models.”

One outcome from these limitations is often a common need to manage two BPMN models. Business users need a simple model of their processes that they can relate to as a story of their business understanding. IT professionals need more detail and technical detail and rigor to provide a detailed specification that they can design and build to. Managing two versions manually can lead to errors in the process. However, as John Everhard mentions “Fortunately a number of BPM vendors are smart enough to support multiple representations, so that both audiences can be happy.”

Another approach is to use multiple techniques to represent different properties of a system. As Everhard remarks, “Business applications consist of more than just process models, they include user interfaces, data models and must be managed in a hierarchical repository that understands how to apply the appropriate business rules and process elements "situationally" - taking into account dynamically circumstantial information such as customer type, customer value, product, geography, temporal conditions, in fact anything that can be codified and inspected at execution time by the BPM engine. By forcing everything, including business rules, to be modeled as a "process", BPMN has fallen short of describing what happens beyond the "happy path", the rules that govern processes (Unified Policies and Procedures) and the technical implementation details.”

I hope the above explains the points in the paper in more detail. I’ve tried to show that our approach is similar to those of process modellers using BPMN. I’ve also tried to show that we are not alone in experiencing limitations with BPMN, especially when complex processes become unmanageable, by quoting some sources from industry and academia. Include are some of the remedies such as using a diversity of modelling techniques and a repository to ensure they co-exist and mutually support each other. I’m as enthusiastic about BPMN as any tool in the toolbox, no more and no less than any of the other tools. It is the outcome that counts.
References
Stephen White, BPMN Modeling and Reference Guide
Jan Recken, “How Good is BPMN Really? Insights from Theory and Practice”,
Egon Borger, 2012, Approaches to modeling business processes: a critical analysis of BPMN, workflow patterns and YAWL, Softw Syst Model (2012) 11:305–318
Jason Stamper Interviews John Everhard, “Pegasystems says BPMN 2.0 is "too hard for business"”, Computer Business Review 16 May 2011.