On my flight to Sydney, I found a missed requirement. Or perhaps it was a de-prioritized one that just never got developed. And honestly as an end user, I won’t ever know.
The issue was that I most often fly American, and for this trip I was flying on a partner airline. Well, because they are partners, my status on American translated to the partner airline. And because they are partners, the American agent could make sure my special meal request was on my reservation. So all was good, right?
Well, over the Pacific ocean, our first meal came around and I asked the flight attendant if they had my meal. He hurried off to look, and came back with a “no”. He asked to see my boarding pass and so I showed him, curiously wondering why he needed that. After quick glance he recognized the issue and went on to explain that the line of text in which they print my partner airline status bumps the special meal request off that line and off the page – and this is the same problem in both the flight manifest and my boarding pass. So in the printed form which they use to stock the plane with food….there is no record of my meal, just my status. So the moral is, you can only be picky about food or have partner airline status!
In all seriousness though, it’s interesting miss in that the boarding pass had lots of blank white space, yet the system didn’t support printing 2 unrelated pieces of information. And I’m guessing it was a missed requirement, but it could be they decided the percent of the population that has status and with special food needs is small enough, that it wasn’t worth writing and testing the code.
Assuming it’s a missed requirement, I have to think about how it could have been caught. There should be process flows that represent capturing the user’s flight info before the flight, another that deals with printing a manifest and boarding pass, and yet another for stocking the plane. I also would hope there would be Business Data Diagrams (BDDs) to show the objects in play here – such as user, ticket, manifest, plane – and Data Dictionary to capture the specific attributes, such as the meal request and status on the user object. And ultimately business rules should have come out of those attributes.
Anyway, I should wrap this up by assuring any worried readers that I didn’t starve. First all, lots of credit goes to the flight attendants who offered me multiple salads and fruit plates and to scrounge business class for whatever food they may have for me. And further, as anyone with special food needs would do, I always carry food with me! So it worked out fine in the end, and at least made for an interesting case for good requirements analysis.
