Monthly Archives: August 2006

BPMN Diagrams – Undefined Intermediate Events

BPMN diagram

There are 9 different intermediate events in BPMN. One of them, called the none intermediate event, is “undefined” in that it doesn’t specify a distinct behavior. Unlike the other intermediate events, the none intermediate event has a single interpretation, and will only be used with a specific methodology.

Background

We presented an introduction to BPMN diagrams almost a month ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

Changing State

The BPMN spec includes the none intermediate event specifically for the purpose of diagramming processes with a methodology that manages and tracks changes in state with events.

Consider the following business process modeling example of an employer evaluating a candidate from a recruiter.

bpmn none intermediate event example diagram

The employer’s process is initiated with a message start event, as a resume is received from the recruiter. The employer reviews the resume, and either rejects the applicant because he is a bad fit, or schedules an interview because the applicant is a good fit. In either case, a message is sent back to the recruiter about the employer’s opinion.

There are three intermediate events in the BPMN diagram. These events are part of the sequence flow, and indicate changes in state of the “Application” business object that the employer uses to track their hiring pipeline. In the first intermediate event, the application is marked as “Pending” to indicate that the applicant is “in the process.” After the decision (represented by the XOR gateway), the applicant is either rejected or approved for an interview.

When the applicant is rejected, the employer’s application object’s state is changed to “Rejected.” If the applicant is approved for an interview, the application object’s state is changed to “Approved.” These state changes are indicated by the none intermediate events drawn in the sequence flow.

The messages are sent back to the recruiter from the intermediate events. They could have been drawn from additional activities such as “Inform Recruiter.” Since the messages are drawn from the events, it implies that the change of state itself is causing the sending of the messages. Perhaps the employer has an automated database that sends an email when the state of the application object is changed.

Summary

None intermediate events indicate changes in state of business objects. They can only appear as elements within the sequence flow of a process. These intermediate events are intended for use when modeling processes that manage the state of business objects. When integrating with or enhancing existing systems, these types of requirements are appropriate to document. When a new system is being developed, then expression of object state change would be considered an expression of design, not requirements.

John Henry, Manual Tester

John Henry

There’s a piece of North American folklore about John Henry, who was a manual laborer during the expansion of the railroads in our country. His job was being replaced by steam-driven heavy equipment, as the railroad industry applied technology to become more efficient. The same dynamics are happening today with manual testers. We need to make sure that manual testers avoid John Henry’s fate – read on to see why.

Manual and Automated Testing

Software can not be tested efficiently with only manual testing. And it can not be tested completely with only automated testing. James Bach writes an insightful article about how he worked his way to enlightenment over several years, and how he has incorporated this perspective into his training classes.

My understanding of cognitive skills of testing and my understanding of test automation are linked, so it was some years before I came to understand what I now propose as the first rule of test automation:

Test Automation Rule #1: A good manual test cannot be automated.

James goes on to explain that if a test can be automated, it is not a good manual test.

We’ve discussed repeatedly the benefits of automated testing, one example is The Code Freeze is Killing the Dinosaurs. We’ve also stressed the importance of doing functional testing where we discuss the dynamics and tradeoffs of using manual and automated approaches to test software.

Generally, we’ve approached the problem from the perspective of blackbox versus whitebox testing (and more details), and thought about our development process from the perspective of continuous integration as a means to deliver more efficiently.

We’ve not thought about it from James’ perspective before. Even with our improved approaches to automated testing, we are still no different than the inventor of the steam-hammer in Henry’s fable.

Enlightenment

James puts things in perspective:

Rather than banishing human qualities, another approach to process improvement is to harness them. I train testers to take control of their mental models and devise powerful questions to probe the technology in front of them. This is a process of self-programming. In this way of working, test automation is seen as an extension of the human mind, not a substitute.

He highlights a very interesting point – we are missing a key benefit of having manual testers – the ability to gather feedback on intangibles, heuristics, usability, affordances, and other elements that we might classify as design bugs.

We talk about the importance of usable software, and different approaches to creating great software. But we’ve never really talked about how to test for software greatness.

A Broken Model

In the 1970’s, when the American automotive manufacturers were getting their clocks cleaned by the newly exporting Japanese companies like Honda, Datsun (now Nissan), and Toyota, a lot of people thought they understood the problem. Many more people pretended there wasn’t a problem, until the US government bailed out Chrysler.

The experts decided that the main problem was that quality was not “Job One”, that American manufacturers ignored the advice of W. Edwards Demming, and the Japanese did not. Toyota’s lean manufacturing philosophy is credited with much of the success.

It is true that the oil crisis of the time gave the Japanese companies an opportunity to penetrate the US market with smaller, more efficient cars. But that crisis ended (about the time that the American companies killed the muscle car and began building more efficient cars). But the Japanese cars didn’t go away. Once gas prices dropped, they lost a differentiating element – but they maintained two others. Cost and Quality.

Target of Opportunity Enables Strategic Advantage

Cost matters. But it matters tactically, as in “I can afford $X right now – what are my choices?” Quality creates Loyalty. And loyalty is strategic. The Japanese manufacturers gain and continue to gain success after success and award after award in the automotive industry. Why? Because they have good quality.

Automated and Manual Testing

As an engineer, I know that we can specify tolerances, inspect components, and test assemblies to make sure that products are “within specification.” And all of this testing can be automated – just like automated software testing. But passing these tests doesn’t make a product good, it merely indicates that the product is “within specification.” Did the Japanese manufacturers have tighter tolerances? Yes. But did they have better designs? Yes. And those better designs were about more than miles-per-gallon and horsepower and torque.

They were about qualitative items that many engineers struggle to absorb. “Feels Good” and “The controls are where I expect them to be” and “Makes sense” and “I like it.” Software developers often struggle with the same issues.

And this is where manual testing matters. Getting qualitative feedback on your product designs is the only way to improve qualitative elements of those designs. The American manufacturers showed their disdain and hubris in allowing their customers to provide that feedback. The Japanese companies got feedback before they sold their products.

We can use manual testing to provide us with the kinds of feedback that can’t be automated. Things like “This UI is confusing” and “Why won’t it let me…?”

Summary

Don’t give up on manual testing as we strive to achieve software product success. Automate everything we can, and use people to test what we can’t.  We need to make sure that we don’t lose the ability (or make sure that we find the ability) to test manually, for qualitative insight into our products.  We can’t let the testers burst their hearts like poor John Henry, trying to manually perform an automatable test.
Thanks again, James, for starting us down this path!

Version Numbering Makes Release Planning Harder

37signals logo

David, at 37signals, writes an interesting post about changing the way their company is managing the naming of new versions of their Backpack information manager product.

David starts with the premise that there is too much feature-creep when scheduling deliveries of software updates.

We’ve previously tackled how to manage this prioritization process via scheduling of changes and managing iterations with timeboxes.

David’s approach to this problem is refreshing – he has provided an out of the box way of solving the problem.

With 37signals’ approach, an update to the software has a major element. We can think of this as the scheduling of a market requirement (or collection of use cases) that provides additional value to the users. This specific focus aligns with our approach of using use cases to communicate delivery schedules.

David’s insight is that once you schedule a release, say 2.1, then other features will try and get themselves included in that release. When I read this, I immediately thought of the riders and provisions tacked onto “clean” bills as they pass through congress. Each little bit satisfies a splinter-group or contingency, at the expense of “more important” stuff.

Imagine if people decided they didn’t want to accelerate the time table on their pet project / feature. That’s what David is doing.

The next release of Backback is titled “Widget Overhaul”, not “2.0.” Suddenly, there’s a lot of clarity about what to include in the next release – overhauled widgets, and not much else.

In a web-release world, this is awesome. In a world where legacy versions of an application will coexist with the latest version, this approach falls down a little (but the idea is still good). Imagine a user calling in for support, and telling the IT guys that he’s running the “Improved Security” release. The IT guys suggest he try upgrading (or is it downgrading?) to the “Improved Performance” release.

There’s a benefit to having a clearly sequential element in the naming of releases. But, as David points out, it comes at a cost – of people adding features until a release is too delayed or too expensive.

How do we get the same benefit with distributed releases? Another approach would be to use dates, for example, the 20060815 release, in conjunction with the benefit-naming approach. Or build numbers.

Identifying a headliner release element is a great idea. Thanks David!

BPMN Diagrams – Introduction to Intermediate Events

BPMN Diagram

Intermediate events are one of the more complex and expressive elements of BPMN diagrams. Here we introduce the different intermediate events.

Background

We presented an introduction to BPMN diagrams almost a month ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

Intermediate Events

There are nine (yes 9!) different forms of intermediate events. And no, you don’t have to read about all of them in today’s article. We’ll just introduce them, and cover them in other articles. The following is the list of intermediate events defined in the BPMN specification.

  • None Intermediate Event. Used to designate a change in state within a business process.
  • Message Intermediate Event. Used to respond to incoming messages or send outgoing messages.
  • Timer Intermediate Event. Causes a delay in a process, or initiates behavior at a set time or set delay.
  • Error Intermediate Event. Throws or catches an error within a process.
  • Cancel Intermediate Event. Used to cancel a transaction sub-process when a cancel end event is reached.
  • Compensation Intermediate Event. Used to initiate or handle compensation within a process.
  • Rule Intermediate Event. Used only for exception handling and is triggered when the rule proves to be true.
  • Link Intermediate Event. Connects another link event to allow for “jumping” from one process to another. Jumping is a “GOTO” statement, not a “GOSUB” statement.
  • Multiple Intermediate Event. An event that can be triggered in any of multiple ways.

BPMN Intermediate Events legend

BPMN Diagrams – How To Use End Events (Part 2)

BPMN Diagram

This is part two of a two part article. The first part is How To Use End Events (Part 1). End events describe how a process ends. Often, the end of one process can initiate other behaviors within a business process. Like death and taxes, every business process has an end. Sometimes more than one.

Background

We presented an introduction to BPMN diagrams two weeks ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

End Events Continued

There are eight different types of end events. We coverd the first four in our previous article. In this article, we will cover the remaining four:

  • Compensation end events
  • Link end events
  • Terminate end events
  • Multiple end events

BPMN End Events legend

Compensation End Event

The compensation end event is an event that, when reached, triggers the processing of a compensation intermediate event. A compensation intermediate event is an event that allows a task to be “undone” with a special process. That may not make sense yet, we’ll explain better as we go.

In the following BPMN example, we again (as with the cancel end event) look at the online purchase from the perspective of the online retailer. The subprocess, “Fulfill Order”, in the flow on the left, is expanded on the right. The “Process Credit Card” has a compensation intermediate event attached to its boundary, with an association (dashed line) coming out of it. Ignore that for now and focus on the flow.

The sequence flow from the “Process Credit Card” task goes to a forking gateway, which requires both parallel branches to be processed. On one path, we ship the ordered product, and on the other path, we check to see if the card is valid. The default behavior is for valid credit cards, and once the card has been validated and the product shipped (via the join gateway), the subprocess is completed.

If, however, the card is found to be invalid, the compensation end event is reached

bpmn compensation end event example

If the compensation end event is reached, it triggers the compensation intermediate event that we were previously ignoring. That intermediate event triggers the “Record Possible CC Fraud” task.

One thing that isn’t obvious about the diagram above – if a credit card is found to be invalid, the “Ship Ordered Product” task is not undone. The compensation end event does not trigger a rollback of the process (like a cancel event would). It only triggers the compensation behavior. To undo the steps in the subprocess, we would have to use a cancel end event, and treat the entire subprocess as a transaction.

What we might desire is that we only ship products if the card is valid, in which case we would change the flow to look like the following diagram.

bpmn compensation end event diagram example

In this diagram, either the credit card is invalid and the sequence flow goes to the compensation end event, or the card is valid, and the product is shipped. This would be a more appropriate diagram – the previous one diagram was shown to indicate that the flow is not “undone” when a compensation event is reached.

[Update: 20060918]

There are a couple mistakes in the compensation end event examples above. Please read this article on compensation events for a correction and detailed explanation
[end Update]

Link End Event

The link end event is used to “connect” two non-sequential subprocesses. The following example shows how a link end event could be used effectively to jump from one subprocess to another.

BPMN link end event example

Everyone flows from “Start” to “C” to “End” by default. Specifically, the tasks would be processed in the order ABCDE. However, the or gateway within the start subprocess presents an alternate flow. The default path ends the subprocess normally, returning control to the parent process (and task “C”). The alternate path links the flow directly to the “End” subprocess

Terminate End Event

The terminate end event is the “STOP EVERYTHING” event. When a terminate end event is reached, the entire process is stopped, including all parallel processes. The following example is from the classic story, Charlie and the Chocolate Factory.

Veruca Salt’s father owned a factory that sold nuts. He retasked all of his workers with opening Wonkabars by the case, in search of the elusive golden ticket. If we made a business process modeling example out of his process, it might look like the following.

BPMN terminate end event example

The employees would receive a single shipment of multiple cases of Wonkabars, and then start the “Process Shipment” subprocess. Within that subprocess, someone would distribute the cases (to multiple employees), and then those employees would process the cases in parallel subprocesses. If there are more cases remaining, those cases are also processed, until there are no more cases.

In the “Process Case” subprocess, the employee first opens the case and then opens a Wonkabar, looking for the golden ticket. If the golden ticket is found, the flow reaches the terminate end event, and everything stops. If no ticket is found, the employee either unwraps another bar (if there is one in the case), or stops the subprocess.

This example illustrates that termination is not only of the subprocess, but the entire process. The “Process Case” subprocess is a parallel subprocess – and all of them terminate once the golden ticket is found.

Multiple End Event

The multiple end event provides us with a way to simplify our diagrams when specifying that multiple events occur at the end of a process.
BPMN Multiple End Event example

In this BPMN example, after dating, falling in love, and getting engaged, three events happen. Our newly betrothed calls his family, reserves a room (for the reception), and invites guests (to the wedding). We can use this event to make our diagrams easier to read.

Summary

Between the first end-event tutorial and this article, we now know how to use and interpret end events in BPMN diagrams.

BPMN Diagrams – How To Use End Events (Part 1)

BPMN Diagrams

End events describe how a process ends. Often, the end of one process can initiate other behaviors within a business process. Like death and taxes, every business process has an end. Sometimes more than one.

Background

We presented an introduction to BPMN diagrams two weeks ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

End Events

In business process modeling, every process has an ending. In BPMN, every path in every process must lead to an end event. Every process starts with a start event, moves through activities and gateways, and then reaches an end. When processes loop, they can exercise multiple endings.

We could create every desired BPMN diagram using only the normal “none” end event, which simply represents an end to the flow of the process. There are eight different end events, and using them allows us to simplify our diagrams while making them more explicit in describing business processes.

In this part of the article, we will cover the following:

  • None (undefined) end events
  • Message end events
  • Error end events
  • Cancel end events

BPMN End Events legend
None End Event

This is the end event we will see (and use) most of the time. When a business process model reached an end event, it is complete. When a subprocess reaches an end event, the process flow returns to the parent process.

bpmn none end event example

The none end event specifies that there is no other special behavior associated with the end of the process. In this example, we are born, we pay taxes, and we die. Nothing else happens within this process.

Message End Event

With this message end event example, in addition to terminating the flow of the process, a message is sent by the end event.

bpmn message end event example

This process begins upon receipt of an application (via the message start event), and the application is processed, then the applicant is accepted, and the application fees are deposited. The applicant is notified (after depositing the fees) by the message end event.

We could have added a task called “Notify Applicant” and have that task send a message, and then have the flow move to a none end event. Using a message end event, we eliminate a task as well as an entity to represent the message flow from that task. The message end event provides us with a simpler way to express that the process ends with the sending of a message.

Error End Event

This error end event example shows a simple process for a consumer, who makes a purchase with a credit card. If the credit card is invalid, the business process flow moves to an error end event. The default behavior represents use of a valid credit card, and takes the flow to a task called “Charge Credit Card” and on to a none end event.

bpmn error end event example

The error end event “throws” an error, which can be captured in another part of the process.  We explain more about how errors are thrown and caught in our article on intermediate error events.
Cancel End Event

The following business process modeling example shows a purchasing transaction from the perspective of an online retailer.

bpmn transaction example of cancel end event

The online retailer’s process begins with a message start event, moves to the task of “Confirm Product Availability”, and then to the “Fulfill Order” subprocess, and on to the “Record Transaction” task. We’ll come back to the “Notify Customer” step (attached via the error intermediate event).

The “Fulfill Order” subprocess is a transaction (the entire thing happens as one atomic action). The easiest way to think about it is that the entire sub-process happens, or none of it happens. This is indicated by the dual-line border of the expanded sub-process.

Within the “Fulfill Order” subprocess, the retailer first processes the transaction on the credit card. The process spits into two parallel paths at this point – shipping of the product on one path, and confirming the validity of the credit card on the other. Most of the time, the card is valid, and the subprocess flow ends (with the none end event). Running the tasks in parallel allows the retailer to be more responsive to customers, and reduce inventory levels by processing orders more quickly.

However, if the credit card is invalid, the retailer wants to be able to “undo” both the step of shipping the product, and the task for processing the credit card. When the cancel end event is reached, the entire subprocess is cancelled. The cancel end event is designed specifically to cancel an entire transaction whenever something inside the flow of the transaction triggers the cancellation.

The cancel end event (bold circle with an ‘X’ in the center) is processed only when the credit card is invalid. If the credit card is invalid, the retailer wants to “undo” both the shipping of the product and the processing of the credit card. Further, if a card is invalid, the retailer wants to notify the customer.

The cancel intermediate event (defined on the double-line boundary of the expanded sub-process) will “catch” the error that is “thrown” by the sub-process. The task “Notify Customer” is then processed.

Summary

There are still four more bpmn end events that we have not covered. Stay tuned for part two of this article…

Free Webinar on Strategic Product Management

Coffee mug

Sit back and enjoy a cup of coffee while listening to a great, 30 minute, presentation by Barbara Nelson, Pragmatic Marketing instructor. Citrix is hosting a free webinar for (well, for everyone, I guess), in exchange for contact information. Barbara presents a great overview of the strategic role of product management, and Pragmatic’s framework. For people who’ve previously attended the PPM training, this is a good refresher – for other folks – if you want to know why product managers should be doing strategic work, check this out.

The Sales Pitch

Eric Choi presents a short (150 second) intro to the GoToMeeting Corporate brand and products before introducing Barbara. Not at all in-your-face, and a small price to pay for Barbara’s presentation.

One thing that is cool about (presumably) the Citrix GoToWebinar software is the ability to do “quick polls” in real time and demonstrate the results, during the webinar. The current webinar (that we can watch) is a recording of a session previously given to a live audience.

Snippets

I still remember the palpable feeling of excitement when I first attended the PPM training (from Barbara, who is awesome!), and when she presented the case for a strategic focus on product management. I reviewed my notes from that part of the training, and the question isn’t “what did I write?” but “what didn’t I write down?” A continuous flow of good ideas.

Having absorbed and adopted this perspective, here are a couple of snippets about what jumps out as the most compelling ideas to me:

  • The role of product management is not defined as “stuff sales and dev don’t want to do.”
  • Product managers should be focused on defining problems in the market that are worth solving – not running demos, writing marketing copy, or specifying user interfaces.
  • If product managers are doing this stuff, who’s doing the strategic product management work?
  • Product managers support downstream processes in a way that ideally prevents fires, instead of putting them out.
  • Barbara’s approach to gap analysis, within Pragmatic’s framework, is very cool.

Where Is The Link?
Right here. https://www.gotomeeting.com/s/CMP_BTA/B/080806

Inside Out is Backwards – Feature Focused or Goal Driven

backwards clock

Kathy Sierra has another great post on the problems people face when using products. One of the sources of the problems is when engineers think “from the inside out” and focus on features or capabilities. People have goals, and they want to achieve goals, not use capabilities.

Feature Focused

Kathy uses a new digital SLR camera as the example for her article. She wonders if the problem is that the company spent too much time thinking about the camera, and not enough time thinking about photography. She points to the user manual as an example – the manual tells users exactly how to perform action X, but never talks about why someone would want to do X.

Goal Driven

Some cameras “get it.” Canon makes a digital camera where the primary adjustment knob doesn’t let you set f-stops, aperture, or shutter times. The primary adjustment knob has available settings. “Action”, “Portrait”, and “Landscape” are some of the settings. Canon’s product manager realized that his customers use the camera with a goal of taking pictures. And the features of the camera support this.

Opposing View

You could argue that the feature focused camera is designed for people who already know why they want a 1/60 shutter setting. And therefore, we don’t need to worry about it. Only relatively inexperienced people would face problems with this camera.

There is a valid argument that features and design should be optimized for competent users. But there is a barrier to entry for those users – they need a way to get enough experience with the product to gain competence. One barrier to entry results from having too many features.

Conclusion

When we’re designing software (and prioritizing requirements), we have to approach our jobs from the perspective of our users. Users have goals. We should design for them.

BPMN Diagrams – Digging Artifacts

BPMN Diagram

Artifacts are more than business detritus. Documents are created in business processes that represent actionable information. See how to represent these useful artifacts in business process modeling notation.

Background

We presented an introduction to BPMN diagrams two weeks ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

More Than A Flow

Most of business process modeling is modeling the flow of events, and the messages between organizations. Artifacts allow us to express more than just a flow. Artifacts allow us to show information or objects that are passed along through the process with the flow. Artifacts are also referred to as data objects in the BPMN official spec, but since they can represent physical objects as well as electronic documents, it is easier to just refer to them as artifacts.

BPMN Artifact

An artifact is drawn as a document as shown above. The name of the artifact is included below the document icon, and the status is shown in square brackets.

Note that artifacts are not required for BPMN diagrams. They can make the diagrams much easier to read, however, and should be included whenever it improves the clarity of the diagram.

Sequence Flow Artifact Example

Artifacts can be passed through a process, changing state along the way. We can show this by attaching an artifact to a sequence flow between activities.

BPMN Diagram example of artifact and sequence flow

In this BPMN example, the artifact (an Application) is passed along the sequence flow between three tasks. This application shows a simple hiring process for an employer. Someone screens applicants, then passes the applications along for approval. Once the application has been approved, the applicant is hired. In this business process, the application is passed along as an “attachment” to the sequence flow between each task.

This approach to attaching artifacts to flows makes for a very clean diagram. It is very easy to see that the application is “passed” as data from task to task.

Message Flow Artifact Example

Messages between activities also represent a type of process flow. The BPMN spec uses the term message flow to differentiate messages from sequences (referred to as sequence flows). We can expand our example to include the process from the perspective of the applicant as well as the employer.

BPMN Diagram Example of Message Flow and Artifacts

In this business process modeling example, we show two pools that represent the worker and the employer. The employer’s process is identical to the previous example, and the artifacts are attached exactly as before (to the sequence flows). The messages sent between the worker and the employer now have artifacts associated with them. The first is a submitted (but not yet screened) application. The second is a submitted job offer.

Attaching artifacts to message flow provides clarity in the diagram much like the sequence flow attachment.

A Supported Alternative

There is an alternative way to represent artifacts – attaching them to activities. In our previous examples, the application artifact “changes state” within the “Approve Application” task. This was demonstrated by the change in state of the artifact between the sequence flows that enter and exit the task. This could also be shown by attaching artifacts to the task itself.

Attaching artifacts to tasks in bpmn diagrams

When we attach the artifacts directly to tasks, we have to include the directional arrows that indicate if the artifact is being sent “into” the task, or coming “out of” the task. As this diagram shows, the application enters the task in a “Screened” state, and exits in an “Approved” state.

This approach is valid for the BPMN spec, but we don’t reccommend it, because it is limited. What if the task were “Evaluate Application” instead of “Approve Application?” We could have the application as an artifact output of the task in either of two states – Approved or Rejected. How would we draw it? It would be easier to understand the process if a gateway were used to direct the process flow after the evaluation, with artifacts attached to the output flows of the gateway.

BPMN Diagram example of gateways and artifacts
One thing that is important – whichever approach you choose, be consistent. We believe that attaching artifacts to flows is the better approach, because it handles more situations with clarity.

Summary

Artifacts are important to business processes. Including them in BPMN diagrams can improve the communication process by putting the needed artifacts in center stage. When we include artifacts, we have choices about how to include them. We should be consistent in using the same approach in all of our diagramming. Attaching artifacts to flows provides more clarity than attaching them to tasks.

Quality and Requirements – You Got Chocolate In My Peanut Butter

Reeses Cup

Quality writers are writing about requirements. Requirements writers are writing about quality. Just like the Reese’s Peanut Butter Cup – Two Great Tastes that Taste Great Together. You can’t have one without the other.

Quality

The Business Analyst Blog writes about speeding up testing:

Everyone has suggestions about how to improve your testing—implement a testing process or methodology, utilize IEEE standards, work towards CMMI compliance, etc. No one mentions that improving requirements will improve testing! […] Why does it take so long? I would argue that one of the main reasons is that poor (or missing) requirements slow down the process as much as any other issue.

Well said. If we’re testing for the wrong things, we’re wasting time and resources.

Requirements

The Software Quality Blog writes about requirements best practices:

No process is more fundamental than the process of defining and managing business and technical requirements. It’s no surprise that studies cite inaccurate, incomplete, and mismanaged requirements as the primary reason for project failure.

Well said again. The Standish Group estimated that 40% to 60% of defects were due to errors in requirements, not code.

Convergence

In Where Bugs Come From, we showed that having the requirements errors happen throughout the process, not just at the beginning of the process. Numbers 3 and 4 of the following list are the painful and visible impacts of the problems both of our authors above are addressing. And those errors are introduced in numbers 1 and 2:

Requirements errors can happen

  1. When stakeholders incorrectly define their goals. A focus on ROI is the best way to assure that our stakeholders are focusing on the right part of the business. Elicitation techniques help us to drive this process in a way that tends to focus on the right requirements. The centerpiece of elicitation is interviewing stakeholders – both users and beneficiaries of the system.
  2. When product managers / business analysts incorrectly document stakeholder goals. Writing good requirements is an absolutely masterable skill. Check out these top ten tips for writing good requirements.
  3. When developers write unit tests of the wrong implementation. Even with a great continuous integration strategy, all we end up doing is efficiently testing the wrong stuff.
  4. When test teams assure that the wrong requirements have been implemented. We waste time testing requirements that aren’t really requirements. And we waste time tracking down false positive defects.

Conclusion

When we’re selling the value of requirements engineering, use this argument to explain the benefits (or impacts) of good (or bad) requirements. When we’re responsible for implementation (dev and test) on a project, remember why we care about requirements. It isn’t enough to verify that requirements are implementable. We have a vested interest in validating that the requirements are also complete and valuable.

Sidebar

[disclaimer: I am a bit of a dork.] I cracked myself up today when I typed “errors of omision”.