I desperately need stinkin’ requirements

8/19/2010 12:33 AM EDT

Jack. I think I can help reconcile the spat.

We don't need typical stinkin' requirements. The only requirements worth having are good ones.

Except when dealing with Big Government contracts (you know the type: the paperwork has to weigh more than the aircraft carrier it specifies), it is pretty much impossible to capture all requirements up front. In the real world requirements will emerge as the project progresses.

What I prefer is to rigorously set the scope of the project. Minimal requirements changes that stay within scope are OK. We should expect some changes. That is life.

Huge requirements changes that change the scope of the project are not allowed. The way to handle this is to explain to the management etc that this is not a change, but canning the old project and launching a new one.

Those projects where marketing suddenly want to "just add wifi" are best handled with the scoping approach. Capture, and clearly articulate, the limitations of the project so that management can understand. When they want to "just add wifi" it is then a lot easier to say no and offer the alternative of canning the current project and starting a new one.

Another way to limit feature creep is to specify when the product will be supeceded. This allows excessive feature creep to be pushed to the next project.

Such requirement gathering is important in all engineering, not just EE and CS. Our civil engineering friends just have the benefit that their customers can more easily visualize their needs and the impact of change.

8/19/2010 12:45 AM EDT

It's quite fascinating that (for the purposes of this discussion) military weapons systems and commercial avionics apparently aren't considered to be examples of "embedded systems"! The folks who put together these requirements are called "systems engineers" and they put this information in structured databases using dedicated products such as DOORS, and in the case of FAA-certified software they do so by collaborating with the project's DER. The process of testing that the completed software meets all of the individual requirements consists of V&V (verification and validation) and functional testing; the FAA often also requires an additional process known as structural testing which may also be loosely coupled to the requirements. Gee I never stopped to think that for the last couple of decades I was toiling away in a field apparently either unknown or of only minor interest to a large segment of the embedded community (and apparently totally ignored by academia), otherwise how to explain that there is even a controversy over the subject? Detailed requirements are ESSENTIAL for a project's success (and in some cases even mandated by law)!!

8/19/2010 7:48 AM EDT

Oh wow.. Jack for president.I just started out in industry three months ago and this article is massively awesome. Thanks Jack! Thanks a million

8/19/2010 8:06 AM EDT

JeffL_#2 is right in that in highly regulated embedded systems fields, requirements gathering is stringently followed, but I do find it funny to contrast his response with cdhmanning's comment on "Big Government contracts". I've seen both intelligent and mindless application of processes; it usually depends on the amount of buy-in by developers and managers.

On requirements analysis (I prefer this term to "gathering", as it implies an attempt to understand.), I've seen developers fail to use common knowledge, because it wasn't formalized. I've also seen developers fail to formalize uncommon knowledge, because they believe it to be common (or they believe that the project will never leave their hands). The latter leads me to say that all requirements should be documented. The problem is that I haven't seen many attempts to (properly) reuse requirements; this is often due to poor separation of subject matter, so that (much like in software) platform independent elements get tied to platform dependent elements. e.g., "xyz functionality shall be written in C for use on an abc processor."

8/19/2010 9:16 AM EDT

I couldn't agree with Jack more.

Benjamin Franklin once said, "Never confuse motion with action." In modern times, with our trend toward instant everything, we only tend to recognize and reward "motion" and not "action".

I have found that most (but not all) people who resist defining fundamental requirements do so for one of two reasons: (1) They are unwilling to put forth the front-end effort to do so. (2) They are unwilling to commit to what constitutes "success". Of course, to the extreme, without any requirements, there can only be "motion" and not "action", since there can be no deliberate convergence on any goal ... no goals were defined. Satisfaction and success are always defined solely within my discretion.

8/19/2010 10:24 AM EDT

Sorry Jack, but it is not because of our poor requirement gathering, but rather, the customer really does change requirements. It is the customer's poor requirements gathering that are the cause. My second point is this, written language is ill suited to stating requirements. The proper way to state a mathematical, logic, or engineering related algorithm is to use a logic diagram, eg, Simulink, SciLab. We should view logic diagrams as a language in their own right. After all, it was scientists and engineers who invented logic diagrams and the motivation was to express their ideas in a more precise form than written language ever could.

8/19/2010 10:42 AM EDT

I've recently waded into the world of Requirements Management. I agree with Jack's recommendation of Weigers' book(s), and would add The Atlantic System's Volere Requirements for a somewhat different but common-sense view of REQM from across the pond.
I'm also not entirely opposed to a certain amount of "jumping in" before requirements are set - because we all design by switching between high and low levels, and the need to do some low level exploration shouldn't be restrained by a rigid adherence to a top-down high level "requirements analysis first" approach. But this exploration must be disciplined with the understanding that it will probably need to be "thrown away" as serious development begins.

8/19/2010 11:52 AM EDT

The issue isn't just feature creep and changing requirements. Much bigger problems are unspecified requirements or conflicting requirements. It is easy to blame the customer or our internal Marketing department, but the truth is neither of them can possibly know all those unspecified requirements or understand the conflicts by the time design must start.


In the consumer world, two of the most important requirements are schedule and cost. On almost any project plan, Design Engineering is behind schedule the moment they start, and the longer they wait for requirements to solidify, the more behind schedule they are. But the customer has an imperfect crystal ball regarding the market window, so sometimes being a little bit late according to the project schedule is actually right on time according to the market -- and sometimes being right on time really means being 3 months too late.

Likewise with cost targets. The customer will be delighted that you met his cost target...until your competitor comes out with the same widget at a lower price.

As much as we engineers would hate to admit it, a lot of times in consumer electronics, coming out with the right product at the right time and the right price involves a great deal of luck -- no matter what the requirements were or when they changed.

8/19/2010 12:21 PM EDT

Spot on, Jack! There is a classic battle between getting started (well and successfully) and getting the definition right (or waiting for the perfect set of requirements). My experience in avionics was that even there we had time/resource constraints and often a systems engineer had not finished the details of a sub-section I needed to work on. So what did I do? Work with the systems engineer, discuss the gap (faster than trying to get him to write it down since other needs were pressing) and then go away and write my requirements. After we had a set of requirements, we could review them together and refine them with much less of the systems engineer's precious time. But, that doesn't mean they cannot change.

8/20/2010 5:32 PM EDT

Great essay Jack! I agree that Weigers' book is a great place to start.

The vital distinction here is that just because you can't get *ALL* requirements perfect up front doesn't mean you should just give up and start with NO requirements defined. Not every product is first-of-a-kind, and that means you have some manner of requirement information to work with on day one. The art is in keeping the paperwork light enough and managing changes.

Not all engineering academics are clueless (and I know you didn't mean to say quite that). In my senior/grad level course the title of lecture #2 is Requirements. But I realize I am an amazingly small minority on that point!

8/23/2010 2:49 AM EDT

Ah, requirements. My take on requirements is they are a futile attempt by technical people to reign in non-technical people. If requirements are complete and feasible, it should be possible to fulfill those requirements and claim success. A good requirement procedure does not have any TBD, Unk, or “Then a miracle occurs” (black boxes) when completed. I as an engineer would love to have good requirements to speed development and give me some CYA. However, reality sets in and few non-technical people want to give an engineer a solid answer lest they are stuck with the blame when things go wrong and the engineer goes free. I have tried this requirement process unsuccessfully at a few places and the countermeasures seem to follow the pattern of turning it back on the engineer and pin the blame on them. Examples; The non-technical customer says the contractor will inform us of our current manufacturing processes and regulations then formulate future changes to these processes and regulations to improve production methods for our future products. The engineer looks at this, says, there are current processes and regulations being used, therefore some documentation and data to start building requirements should already exist. Then there are “future products” which means they are already being planned and someone should have the requirements for those. From these I can start the design process. The engineer asks the customer for this information and is told you are already supposed to know that information or the information also has trade secrets. The customer then informs your superior that you are an idiot and you are fired. Similarly, in WWII this happened to the manufacturer of RADAR chaff when they asked for the length to cut the chaff and where told that was a secret. No one would divulge the needed information for fear they would be blamed for leaking a secret.

8/23/2010 8:56 AM EDT

The best requirement detail is whatever the customer wants to agree to. I worked with one military customer that wanted extremely detailed requirements. We delivered the requirements document in a 25 foot truck (50 paper copies). Other customers wanted less than a page of requirements.
It is important to have an agreement on how changes will be managed and paid for. This conversation may identify more requirements.