Slashdot Mirror

Requirements are both good and necessary, but they do require something that I've noticed a severe lack of amongst programmers: Discipline. The discipline to develop preliminary functional models, perform up front what-if analysis, do the FMEA's and maybe a few MSC models for the interfaces. Then map it all back into what the customer says they want and walk them though it. Sound like a lot of work? It is. It also requires a modest amount of negotiating skill and the willingness to both educate the customer, when necessary, and the determination to stick to your guns when you know you are right, always.

I can hire truckloads of happy little coders who don't have a clue about requirements, and then train them (which I often have to do), but I treasure the software engineer who knows and understands the value of requirements, knows what the term "traceability" means, and can effectively translate the customer's needs and wants into a set of models and requirements definitions that accurately and adequately capture the design objectives.

And, yes, things do change during the course of a project, and new things are discovered. That's why the requirements specification is a "live" document subject to continuous review, and there are things called "derived requirements".

And, just one other thing to consider. If you assume a unit cost of defect removal of one (1) at the coding stage, then it's been shown that finding and removing a defect at the requirements stage only costs around .2! That's right. It gets better. Over half of all errors in SW are introduced at the requirements stage. Not doing any requirements? Then brace yourself for some long and agonizing test and debug sessions. Don't believe me? Take a look at this report:

NIST study on software defects

It's big, but chock full of good information.

For an introduction to requirements engineering, this is one of my favorite books:

Davis' book on software requirements techniques

And lastly, here are some links for the curious:

FMEA/FMECA info
Good article on DO-178B
Some more info on DO-178B
A paper on requirements traceability
Info on SDL and MSC

Then again, I guess there are some folks who enjoy whacking away at their software, growing it "incrementally" (no relation to the formal model, BTW), and spending their time at the back end of the project listening to the customer scream about missed delivery dates while they frantically do the compile-test-debug dance over and over. For myself, I'd rather see it just work with a minimum of verification hassle from the outset and then get on with my life.

GutenMark is a GPL'd program to format Project Gutenberg files into LaTeX. From here on, this can be converted into PS or PDF (sample), which can be easily read in a viewer with a large font size. This program also removes the PG banner, seperates text into chapters and italizes the appropriate words. And the page numbers give you free bookmarking.

GutenMark is a GPL'd program to format Project Gutenberg files into LaTeX. From here on, this can be converted into PS or PDF (sample), which can be easily read in a viewer with a large font size. This program also removes the PG banner, seperates text into chapters and italizes the appropriate words. And the page numbers give you free bookmarking.

Strangely enough, people have actually addressed this, notably with the Gutenmark program to convert Gutenberg text into nicely formatted documents in a variety of markup formats (including PDF and TeX, using postprocessing filters).

See GutenMark home

It never ceases to amaze me that, when people see something that only addresses 90% of their own problem, they call it useless, rather than doing a web search to see whether someone has addressed the remaining 10% of their problem.

Gutenberg is an amazingly important project; I urge everyone to support it.

I think Gutenberg is very much there... Have you ever looked at the amount of material in Gutenberg's archives? When it comes to books and material written in english, that is in the public domain, I have to say, that Gutenberg offers almost everything of interest already.

The 'vision' that the author of the Wired article had was somewhat different: To be able to access all texts electronically. Something that everybody who had to hunt down old magazine articles has dreamt of (I still have nightmares from that one dark and dusty university library cellar, *shudder*). While Gutenberg is a great project, to come closer to full availability of all texts via electronic media, there will have to be initiative from governmental organizations as well as commercial entities. Obviously, not all texts will be available for free. But even a somewhat unified way of searching and finding these texts will be huge task.

There is CiteSeer for articles on computer science, there is IEEExplore if you happen to be looking for something from IEEE. But you have to know these places. Even with better search engines like Google it's still quite a task to get your hands on a text, even if you have some time to do the search and are willing to spend money.

A large database of text references (maybe including abstracts) would also be nice to just see what's available while you are still doing research.

The reason the Gutenberg project isn't hugely succesful is not the lack of text. Part of it might be the lack of formatting. Nobody want's to read 600 pages of a classic work on a computer screen in ASCII.

GutenMark does that (almost) automatically. Uses LaTeX.

The problem is that though ClearType looks great subjectively it gives me a massive headache on my 17" ViewSonic VA800 LCD screen if I leave it on for a day or two of heavy computer use, even after I "tuned" it. I haven't set it up on a PDA and tried reading a Gutentext or other ebook because of that (well, and cuz I got rid of my PocketPC device and am back to a Clie for now... doh).

Luckily there are still some immediate options if you are one of the many who *know* about Project Gutenberg etexts (for those of us whose taste in books, e- and otherwise is somewhat antiquated) but have never actually *read* one due to their well, umm, rather plain text look and feel. In particular GutenMark should do the trick. So download a couple of GutenTexts and GutenMark them into PDF/PS and you have something you might not exactly be able to curl up with, but at least it's readable.

Software likes to think of itself as 'engineering' but it's not.

Well, it can be (think aircraft control systems). It just generally isn't. Which tells us that there is some reason(s) buyers don't want well-engineered software.

Bingo!

For some idea of what real software engineering implies, take a look at, for example, RTCA's DO-178B, the guidelines for airborne systems equipment software (a quicky intro can be found here, a project to make these steps easier for open source), or at MIL-STD-498 or IEEE 12207.

These aren't about algorithms or programming languages, they're about the process and the documentation thereof. Development plans, requirements documents, design documents, coding standards, test plans, etc, etc. A ton of boring paperwork -- exactly the sort of thing that goes into the design and construction of any other critical piece of engineering, be it a building, a bridge or an aircraft. (Of course, following one of these doesn't guarantee correct software, but it does make it more likely, and does provide the information to determine where the error first cropped up (code, design, specification, etc) if something goes horribly wrong.)

Of course, all that is expensive in terms of time and salaries, and frankly for much software it just doesn't matter. How often is it life-threatening if your word processor crashes, even if it wipes out your document when it does?

OTOH, it can be easily argued (post 9/11) that anything that compromises the security of or rapid dissemination of critical information could be life threatening -- so perhaps the above standard processes ought to apply to any software used by governmental organizations...