March 28, 2018 – QRA Team


Requirements Lessons from the Cult Classic, “The Pentagon Wars” Movie

  Quick! Here’s a riddle for you: What’s a troop transport that can't carry troops; a reconnaissance vehicle that's too conspicuous to do reconnaissance; and a quasi-tank that has less armor than a snowblower… but has enough ammo to take out half of D.C.?

 

Quick! Here’s a riddle for you:

What’s a troop transport that can’t carry troops; a reconnaissance vehicle that’s too conspicuous to do reconnaissance; and a quasi-tank that has less armor than a snowblower… but has enough ammo to take out half of D.C.?

 

Go on — hop inside this armored vehicle. Hope you like roller coasters!

 

If you’ve seen the hilarious cult classic film The Pentagon Wars, you know the answer: It’s the infamous Bradley Fighting Vehicle (BFV). The BFV — an armored troop transport unit tasked with shielding its occupants from enemy fire while offering offensive capabilities — it actually exists in the real world. And it actually does all the things it’s supposed to do … now, at least. It was an arduously long and painfully expensive road to get there.

 

Ready … Aim … Miss your target by an embarrassing margin! The random chagrined soldier at the end of this GIF is all of us.

 

The Pentagon Wars is a satirical examination of the BFV’s extended, expensive, and disastrous real-life path from the idea phase to prototype. In the film, as well as in real life — the design, development and testing of the BFV cost The Pentagon over $14 billion (taxpayer) dollars and took more than 17 years.

Yikes!

Want to complete your own engineering projects without all the heartache, delays, and cost overruns?

Of course you do.

Study after study tells us the same truth: As you move further along in a project’s life cycle, the cost of fixing engineering errors in systems and software increases exponentially.[1][2][3][4]

And, as Ralph Rowland Young notes in The Requirements Engineering Handbook, “Errors that originate in requirements tend to be the most expensive and troublesome to eliminate later.” Put even more simply: “More than half of all defects can be traced to requirements errors.”[5]

The numbers are sobering. According to a report from IAG Consulting, when there’s a problem with the requirements specifications document, companies spend 49 percent more money and take 39 percent more time to deliver applications. Further, 79 percent of said projects come in over time and over budget and consume over 41.5 percent of the new project development resources on poorly specified requirements. Simply put: There’s a 60 percent time and cost premium to be paid on projects that have poor quality requirements.[6]

The message is clear. Getting the requirements document just right A.S.A.P. is vital to controlling costs and ensuring application success through the life of a project.

Luckily, the rules to ensure requirements document success are somewhat finite. NASA published the following “quality attributes” that every successful requirements document should possess[7]:

  • Complete: Precisely defines the system’s responses to all real-world situations the system will encounter
  • Consistent: Does not contain conflicts between requirements statements
  • Correct: Accurately identifies the conditions of all situations the system will encounter and precisely defines the system’s response to them
  • Modifiable: Has a logical structuring with related concerns grouped together
  • Ranked: Organizes the specification statements by importance and/or stability (which may conflict with the document’s modifiability)
  • Traceable: Identifies each requirement uniquely
  • Unambiguous: States all requirements in such a manner that each can only be interpreted in one way
  • Valid: All project participants can understand, analyze, accept, or approve it
  • Verifiable: Must be consistent with related specifications at other (higher and lower) levels of abstraction

 

For more on those, we wrote an in-depth report on the 21 most important engineering tips for writing an exceptionally clear requirements document. It’s available here.

Keeping in mind both NASA’s 9 requirements engineering attributes and our 21 top engineering tips — let’s investigate the various false steps and disastrous mishaps that happened during the development of the BFV, as told in The Pentagon Wars.

 

Note: While all 21 engineering tips are not explicitly discussed below in relation to the film, we recommend that you always check your requirements document for compliance with all those rules. For an easy way to do so, download our handy Guide & Checklist, which offers a quick summary of all 21 tips, as well as a compliance checklist.

Table of Contents

1. Use a Good Requirements Document Template

Organize in a Hierarchical Structure & Use Identifiers to Your Advantage

Throughout The Pentagon Wars, several themes echo, forming a common thread suggesting institutional incompetence and an endless passing of the buck.

In one running gag, we learn that intra-office communication can be so bad within the Pentagon that officers often find out about their colleagues’ projects only through leaks to the media. Near the climax of the film, Lt. Col. Burton (Cary Elwes) — the undisputed “good guy” of the story — is saved from a dead-end office transfer after the U.S. Secretary of Defense (Richard Benjamin) reads about Burton’s unfair demotion in The Washington Post.

 

Read all about it: Pentagon officials often get their news via the newspaper in this movie. That’s definitely a sign that intra-organizational communication systems are lacking.

 

This episode drives home an important point about organizing your requirements document. Clarity and communication are essential. That’s why we strongly advocate the use of a consistent requirements template. It’s the first tip to keep in mind, because sound organization is the basis of a solid document — and if you start writing one without a clear hierarchy in mind, you’ll surely run into trouble sooner rather than later.

Document management begins at the top. Remember to include a cover page, section headings, essential guidelines for the content in each section, and a brief explanation of your version management system. It’s also wise to include standardized sections addressing how verbs will be used, what your governing formatting and traceability standards are, and other organizational notes. All these steps promote consistency and legibility. They cut down the possibility of future errors arising from confusion.

 

The case for a clear version management system: In this montage in The Pentagon Wars, Lt. Col. Burton’s report “evolves” from the original sentence: “The Bradley test standards have been consistently altered in extreme ways” to “The Bradley tests have been extremely consistent. They have altered the standards for testing.” As stunning an example of creative writing as that may be … it’s a total subversion of requirements document best practices.

 

Rules 2 and 3 — concerning the use of proper hierarchies and clean identifiers — stem from Rule 1. Their theme is the same: Establish a clear pattern for your requirements document, explain it, and stick to it. Aim for clarity and ease of indexing; never let murkiness and unnecessary esoterica invade your requirements document.

From the first absurd moments of The Pentagon Wars, we immediately understand that this is a story about a project gone horribly wrong. And we can tell from those first few scenes that poor communication played a big role in this outcome. Much of the comedy in the movie stems from Major General Partridge (Kelsey Grammer) — the undisputed “bad guy” of the story — and the way he obfuscates, fudges, and outright fibs his way through his professional life. While it’s funny to watch Partridge try to weasel out of questions with non-answers during a Congressional hearing, it’s alarming to understand the depths of this character’s sociopathic lack of regard for the real-life consequences of his disastrous fighting vehicle.

For many projects, the requirements documents are indeed that serious — poorly organized, hard-to-understand specifications can lead to great cost, huge headaches, and critical failures. The easiest, most qualitative thing that Major General Partridge could have done to streamline the creation of the BFV was to start with a clean, organized, and logical requirements document. That’s just the beginning, of course — but it’s an essential step.

2. Standardize Your Requirements Document Language

Be Consistent With Imperatives

Standardization and consistency are two of the most important qualities to consider when writing a requirements document. Amazingly, these two are also the most straightforward directives. It boils down to the cliche: Keep it simple. (“Stupid” on the end of that line is optional.) Just like the NASA rule that requirements should be unambiguous, these tips urges engineers to be mindful of words with multiple definitions and phrases with subtle shades of meaning.

When we first meet Major General Partridge in The Pentagon Wars, he’s in the heat of a crisis. He’s finally being taken to task for his bad faith supervision of the BFV project — some $14 billion and 17 years later.

When he’s asked about the paveway bomb — a spectacularly inaccurate piece of weaponry — he’s forced to admit that “it missed by a mean distance of 5 miles, and nearly 60 percent of the time.”

To say that those are terrible odds for a piece of American combat equipment may be the understatement of the year.

Want to guess where things went off the rails during the making of the paveway? Yes, it’s almost certain that vague and nonspecific adjectives were used in the requirements document. You know the ones — words that sound great to a casual reader, but which are woefully undescriptive and completely non-quantitative when it comes to functionality engineering.

This is the other side of the “readability” coin. Since most requirements documents are written in natural language, these ultimately meaningless terms can easily slip into the text. Such words seem, on their surface, to lend an easy flow and accessibility to the document. You do want flow, of course, but not at the cost of fatal vagueness. Resist the trap!

 

These words are some of the worst offenders:

  • Easy
  • Straightforward
  • Intuitive
  • Efficient
  • Powerful
  • Fast
  • Effective
  • Reliable
  • Compatible
  • Normal
  • User-friendly
  • Few
  • Most
  • Quickly
  • Timely
  • Strengthen
  • Enhance

 

Do everything you can to omit them from your requirements document.

 

3. Ensure Each Requirement is Testable

Of the many idiotic and ludicrous lines that Major General Partridge has in The Pentagon Wars, perhaps the best is: “Whatever problems there are, we’ll fix them in the field … after it’s deployed. That’s the way things are done around here.”

Wouldn’t you just love to be a soldier/guinea pig/sitting duck tooling around in a completely un-battle tested Bradley fighting vehicle?

Now, part of the trouble with the BFV’s impracticality arose from a stubborn refusal to test it. For example, the vehicle was ordered into production with an aluminum exterior. While the Pentagon failed to perform any field tests regarding how this material might hold up under adverse conditions, a British firm ran such evaluations, and they determined that the results were not favorable. When the aluminum exterior was hit by a shell, it burned and gave off a toxic gas. Oops!

But Lt. Col. Burton isn’t like the men who came before him. Early in his tenure, he announces his intention to run a full battery of tests on the BFV. … And his superiors scramble to stop him. Describing Burton’s methods in the Congressional hearing, Major General Partridge calls them “somewhat peculiar.” He’s not wrong — Burton’s tests are innovative and odd, which makes for great movie scenes.

But the reason Burton’s doing things this way isn’t his personal preference for flashiness. The lieutenant colonel is attempting a workaround for a problem that stemmed from poor requirements engineering choices. When designing the BFV, engineers broke an important rule of requirements: They failed to consider how the implementation of requirements would be verified. When you write requirements with specific test scenarios in mind, it helps ensure that design and test engineers know exactly what they will be required to do.

Without the benefit of that forethought, Lt. Col. Burton orders a field test to determine how flammable the BFV might be in case of enemy fire. In the test, he puts fully-clothed mannequins in the BFV. But unfortunately, his evaluation is thwarted — knowing that the test is likely to lead to a fiery explosion, test officials (acting under orders from Major General Partridge) strip the dummies and place their clothes in a fireproof container.

 

The gauntlet … or at least the mannequin head … is thrown!

 

The conclusion to draw from this cover-up? It’s obvious that the BFV would fail a fire test miserably. More importantly, all the decisions that went into the requirements document regarding the safety of the vehicle in combat were not designed with testability in mind. It seems that the engineers only concerned themselves with the theoretical, and never the practical — not a great approach when your final product will be entering a live fire situation.

As detailed by a Congressional committee member during the climactic hearing — many people tried to sabotage Lt. Col. Burton’s tests. For instance, Major General Partridge’s underlings filled the fuel tanks of the vehicle with water during a combustibility test.

 

Hey, this fuel tastes quite refreshing …

 

Defending his subterfuge, Partridge claims: “That wasn’t devious! If the tanks had been filled with fuel, there’s a good chance the vehicle would have exploded. … If the vehicle had exploded, we couldn’t run additional tests.”

Good rule of thumb: If you don’t want to run tests on your product out of fear that the test itself will annihilate your product … you need to re-examine your requirements.

 

And don’t forget the ammunition that’s been emptied out and filled with sand. Hey — water, sand: They’ve got everything they need to enjoy a day at the beach!

 

The climax of the testing portion of The Pentagon Wars comes when the stakes are highest: Lt. Col. Burton declares his intention to test whether the BFV is a safe means to transport real, live humans.

As he makes his intent known, the extreme pushback from Major General Partridge and his cohorts indicates not only that the BFV isn’t safe for troops — but that nobody ever bothered to test this fact.

Again, this represents a major requirements document faux pas. Never get yourself into a situation where you can’t test the ideas or execution of your requirements in a safe and conclusive manner.

By this point in development — and in line with a theme for the movie — it’s too late to overhaul the requirements in the way that they really ought to be. Instead, practicality dictates that Burton and co. must “build the airplane as it flies,” so to speak. In a concession to that truth, the lieutenant colonel sets out to procure livestock for the live fire tests, since testing on humans would be extraordinarily risky and cruel. Long story short: It ends in yet another cover-up, a tense chase … and a tragic amount of unnecessarily incinerated sheep.

 

Colonel Bach (John C. McGinley) is looking pretty desperate to get those sheep on board the BFV. Probably because Lt. Col. Burton said if the livestock weren’t on board this rolling death trap, they’d test on humans . Yikes. Learn from Bach’s mistake: Make sure your requirements are easily testable.

 

Always ensure that your requirements can be extensively evaluated. Don’t let the sheep die!

4. Write Functional Requirements to be Implementation-Neutral

The Pentagon Wars offers an extremely relevant argument for this rule. Since the film deals with the creation of a combat vehicle — that is, a weapon for war — it’s all the more obvious that requirements document writers must create rules that are fully functional and completely free of design details. This is critical in helping prevent conflict between requirements later, should incompatibility or implementation problems arise.

To phrase it simply: State what the system must do, not how it must do it.

During Major Partridge’s hearing, a fed-up member of the Congressional committee sarcastically recounts the impracticality of the BFV by noting: “We have an effective weapon … as long as the enemy allows us to build a two-story crane directly above their tank.”

 

Oh yeah, the missile works great! Just have to mount a massive platform directly on top of your target and get your enemy to hold very still. No biggie. This is a clear case where functional requirements were not written in an implementation-neutral fashion.

 

Can you imagine where this highly granular (and hugely impractical) design concept came from? Yep, smart money says it’s from a horribly miswritten requirements document.

We get a glimpse into the chaos and confusion that went on during the design and prototyping of the BFV in a hilarious montage. It’s clear from the dialogue and the on-screen action that the BFV was a victim of bureaucratic power plays, system-wide inefficiency, and a case of good old-fashioned “too many cooks in the kitchen” syndrome.

These moments lend the movie its tragicomic vibe. Major General Partridge’s ineptitude regarding the BFV is hilariously out-of-touch. You laugh … until you have the sobering thought that his buffoonish errors could translate to real casualties in the theater of war. (It’s even worse when you recall that this movie was based on real-life events.)

When you write functional requirements, resist the urge to make reference to constraints on manner of implementation. They don’t belong in that section. Instead, you can list them out in highly specific non-functional requirements at the outset of the program.

5. Rationale Statements Are Always Appreciated

During a particularly hilarious flashback of how the BFV developed over several decades, we learn a bit about the personality clashes and one-upmanship that yielded the cluttered and ineffective fighting vehicle that exists in the movie’s present.

This scene delivers the perfect illustration of why rationale statements — or the explanations and justifications that illuminate design reasoning — are absolutely vital.

There’s nowhere that imaginations run more wild and costs spiral so out of control quite like an Army brainstorming session, apparently. The logic checks out: With seemingly unlimited budgets and obscure oversight hierarchies, it’s no wonder flashiness trumped practicality when the BFV was designed. According to the film (and the final product), it seems like the BFV was created through a series of impractical people challenging each other: “What if we added this?”

At the beginning of the BFV project, in 1968, the engineers show off a fairly simple design. Their objective was simple: “an infantry transport vehicle that would be a worthy replacement for the M113 armored personnel carrier.” This first iteration was capable of carrying 11 troops and a driver, and it featured a 20mm cannon. It cost $1.5 million.

 

In a vacuum, the first iteration of the BFV was a smashing success. All that the engineers had to go on were loosely arranged ideas, a vague sketch, and a heavy helping of self-congratulatory speeches. Nevertheless, the design worked great! … Before it was required to do anything, at least.

 

In the ‘70s, Army officials couldn’t leave well enough alone. Next, we see a series of change orders whose flimsy justification consists of no more than a passing thought of “Wouldn’t it be cool if …?” Spitballing around a table, the uniformed men debate the merits of various add-ons: scouts, radar, increased opticals, portholes on the side for increased firearms, a turret, and 25mm shells. After some spirited horse-trading, they send an order to the poor designers to add all of those things.

 

When prototyping goes so, so wrong: This scene demonstrates a “kitchen sink” approach to design, which is definitely not recommended. It’s also one of the strongest arguments for why it’s so important to include rationale statements in your requirements document.

 

Clearly, discretion and rationale-based reasoning have gone out the window. Those who are tasked with implementing this improbable beast of a vehicle finally push back. One shouts: “We’re not trying on Levi’s here!”

Costs begin to spiral once more, but that’s just the beginning. Because these modifications are not designed with clear and logical rationales, the engineers miss a valuable opportunity to identify defects and shortcomings. Further, by deviating from rationale-based requirements engineering, the officials make this design even more vulnerable to future change, as design decisions become untethered from functional requirements. Remember: Rationale statements greatly reduce the risk of rework.

 

You definitely want to avoid endless rounds of haphazard permanent marker scratch-outs.

 

The montage eventually devolves into absurdity, as different parties argue back and forth over whether the BFV is a “taxi,” a tank, and even whether it should have amphibious capabilities.

This is just the light side of what happens when rationales are abandoned. The comedy of errors is the least of the problems that can occur — more seriously, costs begin to spiral, waste skyrockets, deadlines get sent into oblivion … and with armored vehicles like BFV, actual casualties can occur.

After many frustrating rounds of go-nowhere, contradictory design revisions, one official sums it up best: “What we’re talking about is 11 years with nothing to show for it.”

He’s not completely right — there is something to show for that time. It’s just a functionally useless, totally impractical “mashup” of disparate ideas. (And astronomical taxpayer waste to go along with it.) The resulting version of the BFV lost nearly half its transport capabilities (it can now carry only six men, instead of 11). It’s tricked out with “the most sophisticated surveillance equipment,” as well as a rapid-fire cannon, an anti-tank rocket launcher with 1,500 shells and 10 tow anti-tank missiles.

Sergeant First Class Fanning (Viola Davis), who acts as Lt. Col. Burton’s confidant throughout the film, brands the BFV “a troop transport that can’t carry troops; a reconnaissance vehicle that’s too conspicuous to do reconnaissance; and a quasi-tank that has less armor than a snowblower, but has enough ammo to take out half of D.C.”

Adding insult to injury, the official who oversaw this disaster of a project gets a promotion.

 

After overseeing a project with massive cost overruns and very questionable outcomes, Col. Robert Smith (Richard Schiff) gets … a promotion to general! And also: a massive tension headache.

 

That’s the danger: Creating requirements without the benefit of rationale statements makes engineers vulnerable to the sunk cost fallacy.

No good decisions come from that mindset.

6. Go Beyond Expected Events and Behavior

Ah, contingency planning. It’s not “sexy” to brainstorm all the different ways that your project could go wrong if even the slightest condition changes. But it’s absolutely essential to anticipate as many exception scenarios as possible. Why? Because — unfortunately — the biggest and costliest requirements-related project snafus tend to occur when engineers neglect to consider eventualities that diverge from the best-case (or normal use) scenario.

In the opening scene of The Pentagon Wars, we’re thrown right into the urgency of a crisis: Major General Partridge is being grilled during a Congressional hearing. You can practically feel his unique mix of panic and delusion as he attempts to explain away the many failures of the BFV.

Reading from a tome-like document that recounts the many misfortunes the BFV has suffered, the chairwoman of the Congressional committee (Olympia Dukakis) reminds the major general: “I see here that you taped an electric hot plate to the surface of the vehicle to help your heat-seeking missile find its target.”

Whoa, whoa, whoa. An electric hot plate taped to a tank?!

 

That heat-seeking missile works like a charm! Except for the fact that you have to strap a bunch of hot plates to the surface of your target so the weapon can find it. Teachable moment: Go beyond expected events and behavior. Also — as detailed in another tip — make sure all your requirements are testable!

 

It gets worse. We begin to gather that this MacGyver-like jury rigging was a matter of necessity. Thanks to compounded errors over time, users of the BFV faced a real survival threat, as the vehicle that was designed to protect them from enemy fire did nothing of the sort. In fact, it made them more conspicuous to combatants, while also creating a new danger of collateral damage.

So, not only were constant spur-of-the-moment improvisations required in order to keep the vehicle (barely) functional, but users had to make quick high-stakes calculations weighing out the risks and benefits of doing so. In other words: requirements document failures lead to project execution mishap whack-a-mole.

Since the BFV was designed without exception scenarios (i.e., electric hot plate add-ons) in mind — the temperature of the vehicle was so high that it could have fried an egg at 20 feet. Yikes! Soldiers over easy, anyone?

Major General Partridge tries to explain this disastrous outcome away, of course. He argues: “There was a verifiable deviation. Standard test data accumulation.”

It bears repeating: Always account for exceptions, deviations, and unexpected scenarios when writing requirements.

7. Don’t Fall Into the Requirements Document Vagueness Trap

As we follow the time-jump narrative of The Pentagon Wars, we start to wonder one thing: How could so many competent army officials come to the same seemingly ridiculous conclusion about the efficacy of the BFV? Is this a mass delusion incident?

We notice that there appears to be a vast conspiracy to look the other way on the vehicle’s many failures. Obviously, there’s pressure at the peer and organizational level to cover up the extreme unsuitability of the BFV.

Throughout the film, much of the comedy comes from little vignettes about the ways in which field tests were fudged. Lt. Col. Burton — who distinguishes himself from his predecessors through his earnest determination to find answers — decides to drop in unannounced and witness some of these tests.

One burning question weighs on Lt. Col. Burton’s mind: How could the BFV have passed an artillery test with flying colors? On paper, the BFV was shot at to test its shielding capabilities, and it sustained little damage. But in practice — the BFV was known to be extremely weak, very vulnerable, and abundantly flammable.

Per the (extremely vague) specifications, “only Soviet arms” were used for the firing test.

 

But wait a minute … is that Romanian writing? Let’s just say — that country isn’t exactly known for the potency of its artillery. Lesson learned: Write requirements so that they are specific and finite — not vague and abstract.

 

But when Lt. Col. Burton runs a similar field test on a door (which sustains barely any damage), and when he spies some Romanian writing, he puts two and two together. Field testers intentionally used extremely weak Romanian shells (“Romania was part of the Soviet bloc,” one sheepishly explains.)

The result? The BFV emerged virtually unscathed — but not on the strength of its defensive capabilities, but rather on the weakness of the shell’s offensive capabilities. The attack artillery amounted to a “spitball from Romania,” which was hardly a threat. The incident clues Lt. Col. Burton into a sobering truth: His own subordinates are taking advantage of vague and amorphous requirements specifications in order to manipulate test results to their advantage.

 

“The ammunition doesn’t work!” says Lt. Col. Burton. The so-called “spitball from Romania” barely left a scratch. Hm, seems like those tests that declared the Bradley to be a formidable shield were … flawed. Sounds like a case of vague requirements.

 

Vagueness slips into requirements documents for a variety of reasons. First, some customers prefer and encourage vagueness, because they think it allows them more latitude to refine things later when they have a more concrete idea of what they want. Authors and engineers like vagueness for a similar reason: It gives them the illusion of greater freedom of interpretation down the road.

As The Pentagon Wars demonstrates over and over — this temporary feeling of “freedom” on both sides almost always gives way to disaster and complications in the long run. As Lt. Col. Burton figures out the extent of the mess he’s inherited with the BFV, he realizes that functional requirements must define precisely what the system needs to do, and non-functional requirements must define precisely what the system must be. In each case, requirements have to be written and structured in such a way that compliance can be readily observed, tested, or otherwise verified.

 

Related rules: Don’t Use Weak Words, Avoid Passive Voice, Use Negative Requirements Sparingly, Define Compatibility, Avoid Using Slash (/) Symbols

8. Write Requirements Documents From the Perspective of a Client or Manager

Before Lt. Col. Burton’s arrival on the BFV project, one thing seems sorely lacking across the board: empathy.

It’s not about being mushy; from a practical standpoint, it’s extremely important that engineers understand how an application will be used and maintained. The engineer’s job isn’t just about creating an impressive product — obviously, the final result should be something that makes the end user’s life more enjoyable, or at least easier.

When creating the requirements document, it’s important to think about whether the component will interface with third-party supplier systems. Also, what maintenance crews will come into contact with it? Which other components will this component interface with?

One clear lesson we can learn from The Pentagon Wars involves foresight. It’s critical for engineers to consider a thorough analysis of the needs of all potential stakeholders who will interact with the system.

When Lt. Col. Burton confronts Major General Partridge with his concern that the BFV doesn’t suit its end users’ needs very well — he meets understandable resistance. Major General Partridge attempts to blow him off by directing him to “read the files.” Lt. Col. Burton surprises him by announcing that he already has.

Earlier in the film, we already saw a visual representation of the “kill them with paper cuts” approach to documenting the BFV’s development. That is to say, its documentation includes “200 pages on the rear door, 250 pages on the paint job, computer simulations of combat conditions … [and] not a single test that actually indicates what might happen if the Bradley takes a hit.”

 

“Which national forest laid down its life for this one?” asks Sergeant First Class Fanning (Viola Davis) poetically. Indeed, there are thousands of pages documenting the inconsequential minutiae of the BFV’s construction. Whoever murdered these reams of paper didn’t even have a clear purpose!

 

It’s obvious why this happened. Men who held Lt. Col. Burton’s position before him were constantly rewarded for pushing paper. The entire BFV development scheme was a conspiracy to pat each other on the back, look busy and confuse outsiders — while creating a final product that was of absolutely no practical use to its end user.

Lt. Col. Burton decides to correct this error by ordering a full battery of tests simulating combat conditions. Amazingly, nobody thought to do this before he came along.

Don’t make the same mistake in your projects. Keep client and manager needs in mind at all steps of the requirements engineering process.

9. Evaluate the Requirements Document With a Diverse Team

In a sobering scene near the middle of The Pentagon Wars, we learn that every single official who was appointed to oversee new weapons testing prior to USAF Lieutenant Colonel James Burton failed to give his true opinion due to politics and fear of missing out on a promotion.

The epilogue of the film drives the point home, as we learn that Lt. Col. Burton’s courageous actions caused a life-saving overhaul of the death trap BFV. But no good deed goes unpunished: in the fallout, Major General Partridge — who was completely blase about the real-life casualties that could be caused by his negligence — was promoted. Meanwhile, Lt. Col. Burton was forced to retire.

Looking at the rest of the film through this lens, we understand that the Army isn’t a place where “out of the box” thinkers are rewarded. For all its strengths, the organization is sometimes riddled with cronyism, red tape, and a pervasive rat race toward promotions and pensions.

That said, it’s no surprise when we learn that the developers of the BFV broke a cardinal rule of requirements engineering: You must evaluate the requirements document with a diverse team.

Who should be on this team? It’s important to include several groups. Definitely include any designers and developers who will be implementing the requirements to create the system. Don’t forget to loop in the testers who will be handling compliance verification. Finally, include engineers who design, maintain, or manage other systems that will support or interact with the new system, as well as end-user representatives and the client team.

When questioned about the need for more eyes on the BFV testing process, Major General Partridge offers the flimsy (and elitist) explanation: “It takes people with sophisticated knowledge and expertise to conduct these tests and to interpret the results. If the U.S. Army acted on the advice of every Tom, Dick, and Harry who had an opinion on these matters, we’d wind up with a bunch of B-52s powered by outboard motors.”

As hilarious an image as that is — and acknowledging the kernel of truth in his words, that structure and hierarchy are needed during field testing — Major General Partridge’s approach is flippant and wrong. Never be a “lone wolf” while doing requirements engineering. Sure, flow of collaboration must be carefully coordinated. But it’s extremely important to gather a diversity of viewpoints throughout the process and to hear from all affected parties who will be interacting with the application.

 

Conclusions

The Pentagon Wars describes the extreme wastefulness that resulted from the highly convoluted and inefficient development process of the Bradley Fighting Vehicle. The story told in the movie is embellished — though not by much.

In order to prevent similar cost and deadline overruns in your own projects, make sure the specifications listed in your requirements document are clear, unambiguous, well-organized, and complete.

As shown in the film — and as proven numerous times in real-life applications — problems that stem from inadequacies in the requirements document cause massive issues through the life of the project. The compound effect of these issues means that you’re often better off going “back to the drawing board,” as it were, and fixing the problems of your requirements document, rather than trying to modify the live project on the fly.

Ideally, of course, you prevent these headaches by using a proven requirements template, a specifications checklist, and a solid compliance plug-in from the get-go.

And if you’re ever tempted to cut corners — just think of those poor sheep.

 

The Pentagon Wars reminds us that even when everything feels distant and theoretical — the stakes are high when you’re a requirements engineer. Always follow the 21 Tips for successful requirements engineering documents as you write.

 


References
[i] Jonette M.,et al, Error Cost Escalation Through the Project Life Cycle, NASA Johnson Space Center and INCOSE, June 2004.

[ii] Boehm, B. W., Software Engineering Economics, Prentice-Hall, 1981.

[iii] Rothman, J., What does it cost to fix a defect?, Stickyminds.com, August 2002.

[iv] McGibbon, T, Return on Investment from Software Process Improvement, The DoD Software Tech News, Volume 5, Number 4, November 2002.

[v] Young, R. R., The Requirements Engineering Handbook, Artech House, 2003.

[vi] Videos: Reasons Projects Fail (n.d.), https://www.iag.biz/resource/small-projects-service-video/, Retrieved January 28, 2018.

[vii] NASA Systems Engineering Handbook, Books Express Pub, 2010.


Share this Story

 

Get the Latest Updates

If you're part of an engineering team, tech company, or just like to be at the bleeding edge of innovation

Rethink Requirements Today

Put QVscribe to the test on your documents to see how much time and rework you could be saving.


Learn About QVscribeSchedule a Demo