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
Dec 4, 2020
As consumers, wireless technology is often taken for granted. How difficult would everyday life be without it? Can I open my garage door today? How do I turn on my Smart TV? Where are my social networks? Most of our daily wireless connections – from Wi-Fi and Bluetooth ...
Dec 4, 2020
I hear Percepio will be introducing the latest version of their Tracealyzer and their new DevAlert IoT device monitoring and remote diagnostics solution....
Dec 4, 2020
[From the last episode: We looked at an IoT example involving fleets of semi-trailers.] We'€™re now going to look at energy and how electronics fit into the overall global energy story. Whether it'€™s about saving money on electricity at home, making data centers more eff...
Dec 4, 2020
A few weeks ago, there was a webinar about designing 3D-ICs with Innovus Implementation. Although it was not the topic of the webinar, I should point out that if your die is more custom/analog, then... [[ Click on the title to access the full blog on the Cadence Community si...

featured video

Improve SoC-Level Verification Efficiency by Up to 10X

Sponsored by Cadence Design Systems

Chip-level testbench creation, multi-IP and CPU traffic generation, performance bottleneck identification, and data and cache-coherency verification all lack automation. The effort required to complete these tasks is error prone and time consuming. Discover how the Cadence® System VIP tool suite works seamlessly with its simulation, emulation, and prototyping engines to automate chip-level verification and improve efficiency by ten times over existing manual processes.

Click here for more information about System VIP

featured paper

Tailor-made gateway processors lay the groundwork for zone architectures

Sponsored by Texas Instruments

Automotive suppliers and original equipment manufacturers are heavily investing software R&D efforts on adding new functions and features to achieve autonomy, electrification and connectivity. Still, enabling these functions by adding more electronic control units (ECUs) is not sustainable when it results in increased complexity and cost. There are two ways to consolidate and streamline ECUs within a vehicle…

Keep Reading

Featured Chalk Talk

Benefits of FPGAs & eFPGA IP in Futureproofing Compute Acceleration

Sponsored by Achronix

In the quest to accelerate and optimize today’s computing challenges such as AI inference, our system designs have to be flexible above all else. At the confluence of speed and flexibility are today’s new FPGAs and e-FPGA IP. In this episode of Chalk Talk, Amelia Dalton chats with Mike Fitton from Achronix about how to design systems to be both fast and future-proof using FPGA and e-FPGA technology.

Click here for more information about the Achronix Speedster7 FPGAs