Marketing guys have it rough. [That’s your cue to get out your hankies because you just know that sometime during this movie you’re going to be crying for the poor marketing guy. ] They research and they request and they require and they cajole and they do and they do, and what do they see for their efforts? [Besides the one guy that actually does have his hanky out at this point… yeah… he’s hoping for a transfer into marketing…]

Let’s say you’re new to a company, or you’re proposing a new product. Engineering and manufacturing will demand a requirements document. And an environment analysis (remember SWOT?) And a competitive analysis. And a business/ROI analysis. And a marketing plan. And a sales plan. Make that a forecast. For five years, accurate to 10% or else you’ll get called on the carpet.

And some bazillionaire just wrote a book on how he single-handedly got his bazillions (ignoring such trivialities as luck or the trust fund or the many many phone calls that daddy made to smooth things out), and he’ll have some new sexy-sounding sort of thing like a Thunderation Analysis that everyone wants done now so that they too can become bazillionaires. Meanwhile, the biggest B schools have moved from 4 Ps to 5 Qs to 6 Rs, so you have to redo your 4P analysis as a 6R analysis, and the Austin Consulting Group has come up with a nifty new graph that everyone wants to see, and…

And so you spend the better part of several months researching and writing and making up numbers forecasting, and you finally deliver a triumphant set of documents weighing about ten pounds.

Here’s a quick sanity tip: at this point, don’t go asking the people you sent this to what they thought. Really, you don’t want to go there. Because if you go there, here’s what you’ll find: no one read it. Yup, it’s in their in-baskets, they plan to read it when there’s time (you can decode that one for yourself), but they have development work to do, and they really don’t have much time for casual reading.

And you’ll tear your hair out, indignantly pointing out that the only reason you wasted diligently spent several months on this was that they insisted that no professional marketer would propose something without doing all the necessary homework. And, being professional, you complied. And… why… it seems like now it was all just a delaying tactic so that engineering could keep working on something that no one asked for but is really cool and fun to develop.

And you’ll get no satisfactory response. So don’t go there.

[Hark: was that a sniffle I just heard?]

Let’s rewind a bit and focus in on the bits that might actually be useful. Because, not all of those documents are the business fashion flavor of the month or a dilatory diversion. In particular, requirements are a good thing – assuming they’re based on a real understanding of what customers need. But you’re a conscientious marketer [Hey, was that a muffled guffaw in the audience? Maybe this is working as a comedy…], so you’ve got a handle on what your customers want. All you have to do is write that down and you’re golden. Right?

Well, I wouldn’t say golden. You’ve made it to pewter, maybe.

How do you know whether the requirements actually made it into the product? I mean, sure, the obvious ones are there (the ecru background on the splash screen, for example). But are numbers being rounded accurately at 11 decimal places per the spec? On the off chance that a lightning strike occurs within a half-mile radius during a teacher-learning day in early fall when the grass is still tinder-dry and just aching to burst into a devastating conflagration, does the automatic fireproof student records vault locking procedure initiate properly as per the spec? You really don’t know. You have to trust your engineering team when they say it got done. And you do trust your engineering team, don’t you? Well? Do you?

Let’s change points of view now. Let’s say you’re a conscientious engineering manager. [The tone just changed back from comedy to serious drama.] You have been presented with a set of marketing requirements. Being conscientious, the first thing you did was actually read them. And found that they contained a surprisingly complete set of use cases, relatively well spelled out. And, against all your better instincts, you think, “Yes, I will implement this, I will make this right.”

[Oooo, violins crescendoing into brass… nice… must see if this soundtrack is available]

But now you have to figure out how to make that happen. If nothing else, you have to maintain the list yourself, checking things off once you know that they’re in place. Rechecking with every regression test run. Oh, and did we mention there are about a million lines of code? Yeah, that’s a lot of requirements.

This is where LDRA has a module called TBreq that’s intended to help: it’s not requirements tracking, but requirements tracing. Yes, dropping that one little “k” changes a lot. It’s not for capturing your requirements; you’ve already got plenty of ways to do that. This is where you connect the requirements into the program being written.

You can assign who works on what and map requirements to actual code. And, importantly, you can create tests from the requirements and assemble those tests into a complete verification plan. Now if a test fails, you can see which requirement it corresponds to, as well as the related source code. Apparently, it can even point out code that isn’t linked to any requirement. (So if you want that flight simulator buried in there, you have to find a way to get that put in as a requirement. There’s a challenge for you… You have 48 hours… Go!)

TBreq integrates with LDRA’s other test and analysis tools; it brings requirements into the flow. It can take them in the form of Word or Excel or even PDF docs, or it can talk to DOORS or RequisitePro (to be specific, that’s Telelogic DOORS and Rational RequisitePro, or, wait, no, it’s IBM Telelogic DOORS and IBM Rational RequisitePro, or wait, no, now they’re calling it IBM Rational DOORS…) or a variety of other tools.

This actually creates the possibility of a seamless top-down design process that provides accountability. [Here is where the conflict resolution part starts… yes, that means the movie is almost over and you probably will be able to hold it till the end.] Marketing can research the requirements, specify them in conjunction with engineering; engineering can take them and tie them into the code, executing an exhaustive verification plan and generating reports that demonstrate that, hand in hand, marketing and engineering have successfully proven the cynics and the slackers wrong.

But in case this all sounds like some improbable Romeo-and-Juliet romance, there are times when this stuff isn’t just a good way to create quality code from the start; it actually matters. Traceability is critical when you’re developing code that affects whether people live or die – say, in the avionics system that needs to do more to smack the pilot and let him know that people have been trying to get his attention for an hour and he just passed the destination and fighter jets are ready to scramble. Or the nuclear power plant controls that we rely on to operate reliably even when Burns and Smithers are otherwise distracted in some fashion we’d probably best not attempt to imagine. In these scenarios, the required accountability becomes much easier to manage, saving time and avoiding errors.

Panning back over to our feckless marketing guy, it’s not clear that his life of generating reports that no one reads is over. He may still have to build wildly unlikely revenue scenarios to please The Board. But requirements, well, that might actually prove to be a satisfying endeavor. By seeing their implementation all the way through verification, he may actually make it from pewter to golden.

Link: LDRA TBreq