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
May 18, 2021
Since I was a kid, I’ve always been a fan of technology making life better. When I was 8, I remember programming the VCR to record the morning cartoons so I wouldn’t miss the good ones after the bus picked me up from school. When I was 10, I made mixtapes of my fa...
May 18, 2021
原文出è•: Please Excuse the Mesh: CFD and Pointwise ä½è…: Paul McLellan Cadence於今年四æˆæ”¶è³¼äº†æµé«”動力學公司Pointwiseã‚å¨æˆ‘的前ä¸ç¯‡æ–‡ç« æŽ¢è¨Ž PointwiseãPCIeã...
May 13, 2021
Our new IC design tool, PrimeSim Continuum, enables the next generation of hyper-convergent IC designs. Learn more from eeNews, Electronic Design & EE Times. The post Synopsys Makes Headlines with PrimeSim Continuum, an Innovative Circuit Simulation Solution appeared fi...
May 13, 2021
By Calibre Design Staff Prior to the availability of extreme ultraviolet (EUV) lithography, multi-patterning provided… The post A SAMPle of what you need to know about SAMP technology appeared first on Design with Calibre....

featured video

Introduction to EMI

Sponsored by Texas Instruments

Conducted versus radiated EMI. CISPR-25 and CISPR-32 standards. High-frequency or low-frequency emissions. Designing a system to reduce EMI can be overwhelming, but it doesn’t have to be. Watch this video to get an overview of EMI causes, standards, and mitigation techniques.

Click here for more information

featured paper

Ultra Portable IO On The Go

Sponsored by Maxim Integrated

The Go-IO programmable logic controller (PLC) reference design (MAXREFDES212) consists of multiple software configurable IOs in a compact form factor (less than 1 cubic inch) to address the needs of industrial automation, building automation, and industrial robotics. Go-IO provides design engineers with the means to rapidly create and prototype new industrial control systems before they are sourced and constructed.

Click to read more

Featured Chalk Talk

Rail Data Connectivity

Sponsored by Mouser Electronics and TE Connectivity

The rail industry is undergoing a technological revolution right now, and Ethernet connectivity is at the heart of it. But, finding the right interconnect solutions for high-reliability applications such as rail isn’t easy. In this episode of Chalk Talk, Amelia Dalton chats with Egbert Stellinga from TE Connectivity about TE’s portfolio of interconnect solutions for rail and other reliability-critical applications.

Click here for more information about TE Connectivity EN50155 Managed Ethernet Switches