So, to respond to a thought on requirements, you respond with limitation of hardware vis-a-vis programs for rockets. Perhaps apropos: Requirements are not rocket science! :)

to respond to a thought on requirements, you respond with limitation of hardware vis-a-vis programs for rockets.

Wow. Is that what you read?

What I read was, that the single most carefully designed and specified software project in history had to deal with changes to its requirements throughout its 30 year lifespan.

Despite setting out with the goals of:

These lessons were applied to the Shuttle. One of the most important lessons was that software is more difficult to develop than hardware. As a result,
• software documentation is crucial,
• verification must proceed through a sequence of steps without skipping any to try to save time,
• requirements must be clearly defined and carefully managed,
• good development plans should be created and followed, and
• adding more programmers does not lead to faster development.

NASA also learned to assign experienced personnel to a project early, rather than using the start of a project for training inexperienced personnel.

And having 6 years of research & development time, and spending $200,000,000:

A second challenge involved requirements. The software requirements for the Shuttle were continually evolving and changing, even after the system became operational and throughout its 30-year operational lifetime. Although new hardware components were added to the Shuttle during its lifetime, such as GPS, the Shuttle hardware was basically fixed and most of the changes over time went into the computers and their software. NASA and its contractors made over 2,000 requirements changes between 1975 and the first flight in 1981. Even after first flight, requirements changes continued. The number of changes proposed and implemented required a strict process to be used or chaos would have resulted.

I guess its true what they say about those that will not see; or at least only see what they want to see.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Is that what you read?

You linked to a long document without giving pointers past that. Further, you lightly insult in your posts. I wanted to just close it right there, but i respect you enough to at least skim the first few pages, and that indeed was what i saw. It's there, and quite relevant to the discussion.

While the "requirements" change here, as you point out "even after the system became operational and throughout its 30-year operational lifetime" That's a revision, not a requirements change. That's a revisions after the initial version came out and after the original requirements already produced a product. Agile will not help you there.

Now, if they started coding for the shuttle before it was done, in anticipation of the years required to write and test the software, perhaps the requirements could not be finished ahead of time, unless done piecemeal. If that was the case, i could hear the argument that Agile might be a viable alternative to piecemeal.