Writing Design Specifications

Over the years, working as an engineer, the approach I take to design specification writing has matured into a two-part process. First there is what I call an external design specification (EDS), followed by what I call the internal design specification (IDS). The EDS is a black box view of the project from the perspective of the end user or customer. The IDS, on the other hand, is a white box view of the project written from the perspective of the engineers who are doing the actual design of the product. Then, at the conclusion of a project, the process of “validation” is done to the external design specification, while the process of “verification” is done to the internal design specification.

The IDS is generally written separately from the EDS and is put together by the engineering staff that will be responsible for designing, building, testing and otherwise turning the original EDS into a working piece of hardware. Starting with a well-written EDS, the IDS should virtually write itself.

Sadly, more often than not, what passes for a project’s EDS is generated by the marketing and sales departments. Rather than a clear outline of what needs to be accomplished, the project design specifications take the form of a vague wish list of features; some of which might be impossible to attain, while others turn into a set of mutually contradictory design goals. In cases like this, it’s the engineering management and staff that have to fill in for all of the missing design specs. It’s at this point projects start to fall apart. Looking back on my career, I would have to say every time I watched this happen, the project in question invariably ended up getting terminated, six months to a year later, without ever coming close to completion.

So what information should a well-written and robust external design specification contain?

• An EDS needs to set forth its meta-goal. That is, what is the intent of this project? It’s so easy to get caught up in the design of a particular piece of hardware that one fails to ask the very basic question, “What are we trying to do with this in the first place?” I’ve had the experience myself of getting partially into a project design only to realize that there is actually a way easier and better way to do it than was originally envisioned. An EDS needs to be flexible enough, so that if something like this comes up, it can go through a revision process and take off in a new direction. An EDS which is written too specifically can trap the design team into an effort which, before it’s even done, people realize is not going to work. I’ve noticed as a physicist working in the engineering world that this kind of question comes naturally to me, but it generally seems to be an area of challenge for those trained academically as engineers.

• An EDS needs to set forth a single design priority for the project that should then be religiously held to throughout the design and development process. This could be cost, size, speed, power consumption, a particular user interface or target environment, and etc. The important thing is that a project design can have only one priority. Once you allow a project to have more than one design goal, the dreaded problem of feature-creep sets in.

• An EDS cannot assume as fact information which is not yet available. Another way to formulate this point is to say that an EDS should never try to specify the design of the final product in its first revision.  Once a design team gets involved with a project, all sorts of unknowns will surface that will invariably force a review and amendment of the original design specifications. At the very least, a project should pass through three stages; a prototype stage, a refinement stage, and the final stage. And for each of these stages, there should be a unique revision of the original EDS.

In some ways, you can think of an EDS as a tool or template, which if used properly, will help you formulate your ideas into a doable project that has the greatest chance of a successful completion.

So the first task in creating an EDS for my project is to narrow down exactly what it is I intend to accomplish. I’ve spent a lot of time the last month reviewing literature on the subject of asynchronous processor arrays and have narrowed down my field of interest to the subject of very large asynchronous arrays of simple processors (VLAASP’s). As I've Googled around the web looking for technical papers on such an architecture, I’m finding next to nothing there. I’m taking from this that I’ve stumbled onto a field of inquiry which might still be open for an individual like me to make some contributions to. So the overarching goal for this project will be the eventual publication of original results.

The project at this point breaks into two separate but parallel pathways. The reason for this is that what goes into the individual simple processor cells is going to be determined by the kinds of applications that the asynchronous array is going to be running. So before I can develop the Verilog code to be installed into the various FPGA parts I need to have some idea of what these individual cells are going to be doing. But the kind of applications I might search for in the literature will be constrained by what the underlying hardware can do in the first place.

So the first pathway in this process will be the creation of a piece of working hardware that would function as a demonstration platform for my ideas. The first pathway breaks down further into the construction of a proof of principle prototype followed by the creation of a larger asynchronous array. The second pathway will be to search for applications for which a very large asynchronous array would be uniquely suited for. There will no doubt be multiple blog posts on both of these subjects over the course of the next few months as my ideas converge on some doable but useful project goals.