The Problem of Requirements Engineering
Traditionally, software development processes have been requirements-driven: an attempt is made to provide requirements definitions and then to implement those requirements. Therefore, the success or failure of requirements determines the success or failure of software projects. In real world however, virtually every major software program suffers from severe difficulties in requirement specification. Many studies cite requirement management issues as a primary cause of software project failure.
Requirements are typically defined as what the system should do, as explained in Wikipedia: “In systems engineering, a requirement can be a description of what a system must do, referred to as a functional requirement. This type of requirements specifies something that the delivered system must be able to do. Another type of requirements specifies something about the system itself, and how well it performs its functions. Such requirements are often called nonfunctional requirements, or ‘quality of service requirements.’ Examples of such requirements include availability, testability, maintainability, and ease of use.”
Professional developers usually develop software for someone other than themselves – they build it for the users of the software. It is assumed that the users must know what they require. However, little experience trying to gather requirements from users soon reveals them to be an imperfect source of information. Frankly, users frequently do not know what the requirements are or how to specify them in a precise manner either. Even with the help of analysts, user did not fully understand what the software system ought to do. As projects proceeded, users and the developers themselves could see what the system would look like and thus came to understand the real needs better, a wealth of change would be suggested.
The source of functional requirements is the opinions of the users and developers. They are ambiguous and largely depend on the individuals’ experiences and preferences that vary from time to time and from people to people. Hence the software system is built on sand (personal opinions) instead of rock (stable scientific principles). This shaky foundation on which the software system is built is the root cause of the problem.
The functional requirements, what the system should do, by definition is the solution. There is no scientific knowledge, the law of “nature” to be applied in creating the technical knowledge. The fundamentals of design common to all engineering is a process of applying scientific knowledge to create technical knowledge by which the design constituents are harnessed and intended utility or functions are implemented. Therefore the problem of requirements engineering cannot be solved for the lack of scientific knowledge.
Fred Brooks drew on an ancient philosophical tradition of distinguishing between “essential” and “accidental” properties to describe software. Essential properties are those properties that a thing must have to be that thing. A car must have an engine, wheels and a transmission in order to be a car. A car might or might not have a V-8 or V-6 engine or an automatic or manual transmission. These are “accidental” properties that do not affect the basic “car-ness” of a car. Software entity, within the context of enterprise, is described in two aspects: essence inherent in the nature of software and accidents attending its production but not inherent.
The essence of a software entity is the scientific knowledge that is a business concept: a construct of business processes, business rules, entities, relationships, algorithms, and invocations of business functions. This business concept is abstract in that such a conceptual construct is the same in view of different software technologies. It is nonetheless highly precise and quantitatively detailed and hence the “essential” property. The accident of a software entity is the technical knowledge that represents the essence by means of computer languages in the form of graphic user interfaces, databases, components, middleware, and network protocols, etc. This representation is concrete in that such representation can be in many different ways subjective to IT workers’ experience and preferences. It is nonetheless highly diversified and qualitative and hence the “accidental” property. Creating technical knowledge without creating and applying scientific knowledge first is the root problem of requirements engineering.
Jerry, I like your writings a lot. But I have to pick a point with you. A car is a man-made thing which self-propels on a solid surface (of some range of zero to positive inclination) while providing a protective environment for one or more human passengers as its load.
One solution is to use an engine, wheels and a transmission. Would it be any less a car if it each wheel had its own engine, and there was no transmission? Or there were no engines at all, just flywheels that stored the necessary energy?
One of the many problems in requirements engineering is that our education systems do not produce engineers with the skill to distinguish between problem and solution.
Kind regards
Robert
Hi Robert,
Your question is that a car may have many essencial properties? If with a different essence, then we may call it something else other than a car. A dog is called a dog because they all have some (unchanging essence, the DNA) in common. The defining function of an automobile is to move people from one place to another. With this defining function, there is an optimal solution as described in the essencial property, the form under a set of constraints. The function determines the form. Or form follows function. This is one-one mapping for the uniqueness of optimal solution under fixed constraints.
Agreed with your problem vs. solution remark. If the problem representation can be precise, concise and complete then we can derive the solution in one iteration…the dream of process improvement.
Regards
Jerry