feature article
Subscribe Now

Going for Golden

Tracing Requirements with LDRA’s TBreq

 

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

 

Leave a Reply

featured blogs
Mar 28, 2024
'Move fast and break things,' a motto coined by Mark Zuckerberg, captures the ethos of Silicon Valley where creative disruption remakes the world through the invention of new technologies. From social media to autonomous cars, to generative AI, the disruptions have reverberat...
Mar 26, 2024
Learn how GPU acceleration impacts digital chip design implementation, expanding beyond chip simulation to fulfill compute demands of the RTL-to-GDSII process.The post Can GPUs Accelerate Digital Design Implementation? appeared first on Chip Design....
Mar 21, 2024
The awesome thing about these machines is that you are limited only by your imagination, and I've got a GREAT imagination....

featured video

We are Altera. We are for the innovators.

Sponsored by Intel

Today we embark on an exciting journey as we transition to Altera, an Intel Company. In a world of endless opportunities and challenges, we are here to provide the flexibility needed by our ecosystem of customers and partners to pioneer and accelerate innovation. As we leap into the future, we are committed to providing easy-to-design and deploy leadership programmable solutions to innovators to unlock extraordinary possibilities for everyone on the planet.

To learn more about Altera visit: http://intel.com/altera

featured chalk talk

Industrial Drives and Pumps -- onsemi and Mouser Electronics
Sponsored by Mouser Electronics and onsemi
In this episode of Chalk Talk, Amelia Dalton and Bob Card and Hunter Freberg from onsemi discuss the benefits that variable frequency drive, semiconductor optimization, and power switch innovation can bring to industrial motor drive applications. They also examine how our choice of isolation solutions and power packages can make a big difference for these kinds of applications and how onsemi’s robust portfolio of intelligent power modules, current sensing solutions and gate drivers are a game changer when it comes to industrial motor drive applications.
Mar 25, 2024
600 views