(Last modified Fri Apr 11 15:28 2008)
The posing of systematic questions enables the derivation of a more complete set of goals and requirements.
Stakeholders seldom understand their requirements fully at the beginning of a project. They often lack a clear vision of what the system should do and change their minds during development. In general, stakeholders only become more sure about what they want when they see a system that does not exhibit the necessary features. [p.157R¶1]
— "The Use of Goals to Surface Requirements for Evolving Systems", in Proceedings of the 20th International Conference on Software Engineering (ICSE 1998).
Clearly, it pays to invest effort in finding requirements errors early and correcting them in, say, 1 man-hour rather than waiting to find the error during operations and having to spend 100 man-hours correcting it.
— "Software engineering",
IEEE Transactions on Computers
25:12, 1976.
in Klaus Pohl, Process-centered requirements engineering, 1996, p.100.
This suggests the following Modified Golden Rule: "Do unto others as you would have others do unto you — if you were like them." [p37]
In the example shown in Table 2, a large commercial organization found that the most convenient source of detailed requirements came from their existing operational procedures. This "automating the existing system" approach caused so much unnecessary user input workload and such obtuse user outputs that the system had to be scrapped after about three years and $20 million worth of effort. [p38]
— "Escaping the software tar pit:
Model clashes and how to avoid them"
Software Engineering Notes
24:1, January 1999.
Oversimplifying outrageously, we state Brooks's Law:
Adding manpower to a late software project makes it later.
— The Mythical Man-Month, 1975, p25.
... [M]uch of the essence of building a program is in fact the debugging of the specification.
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
— “No Silver Bullet: Essence and Accidents of Software Engineering”.
IEEE Computer April 1987.
According to the Standish Group, 29% of all software development efforts are canceled prior to completion, and another 42% are completed but never used by their intended customers. Clearly, all our efforts to write requirements well are not paying off. [p205]
— "The missing piece of software development", Journal of Systems and Software" 53, 2000.
Summarizing: as a slow-witted human being I have a very small head and I had better learn to live with it and to respect my limitations and give them full credit, rather than to try to ignore them, for the latter vain effort will be punished by failure.
— “Notes on structured programming”, 1970, p3.
Program testing can be used to show the presence of bugs, but never to show their absence!
— “Notes on structured programming”, 1970, p7.
Requirements are often ill-defined, fuzzy, ambiguous, incomplete, or simply incorrect with respect to the users' needs. Problems in the system caused by deficiencies in software requirements are often not identified until well after the system is deployed (Martin, 1988), or are thought to be caused by bad design or limitations of computing technology.
It is well known that as much as 60% of the errors that show up during a system's life have their origin in the requirements gathering and specification stage (Davis, 1990; Schach, 1992). It is also well known that the cost to correct an error found in the development and later stages of system development is orders of magnitude higher than to correct the same error found during the requirements gathering and specification stages (Boehm, 1981). The importance of getting the requirements right cannot be underestimated.
—
"AbstFinder, a prototype natural language text
abstraction finder for use in requirements elicitation"
Automated Software Engineering 4, 1997, p375
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
— (cited in Bowen, "Ten commandments of formal methods")
"We all think Fred's brilliant ... " He swivelled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. "Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it." His voice dropped to a reverent hush. "Fred tells me that he's not sure he understands it himself."
... "Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple."
— Software Requirements and Specifications: A lexicon of practice, principles, and prejudice (1995), p.20 "Brilliance".
Whenever possible we will build more complicate programs up from the simpler; whenever possible we will avoid building at all, by finding new uses for existing tools, singly or in combination. Our programs work together; their cumulative effect is much greater than you could get from a similar collection of programs that you couldn't easily connect.
— Kernighan and Plauger, Software Tools, 1976, p3.
Requirements engineering is asking the right question, of the right person, at the right time. Easy, isn't it?
— [personal communication, 2004]
We view the documentation as being (at least) as important as the product itself: if there is good documentation, a software product can be revised or replaced relatively quickly; without good documentation, software products are of questionable long-term value.
— Parnas and Madey, "Functional documentation for computer systems", Science of Computer Programming 25:1 pp. 19-23, Oct. 1995.
I would advise students to pay more attention to the fundamental ideas rather than the latest technology. The technology will be out-of-date before they graduate. Fundamental ideas never get out of date. However, what worries me about what I just said is that some people would think of Turing machines and Gödel's theorem as fundamentals. I think those things are fundamental but they are also nearly irrelevant. I think there are fundamental design principles, for example structured programming principles, the good ideas in "Object Oriented" programming, etc.
One bad programmer can easily create two new [programming] jobs a year.
— ACM Fellow Profile, Software Engineering Notes 24(3), May 1999.
Traceability adds to what has to be done across the entire life cycle but will reduce the non-productive work by much more.
— G. Stehle, "Requirements traceability for real-time systems",
EuroCASE II, 1990,
cited in Klaus Pohl, Process-centered requirements engineering, 1996, p.100.
