next up previous
Next: The problem of selection Up: The source of requirements Previous: The source of requirements

.

Of course a bad decision about requirements for a small component is not such dramatic as error in requirements of a big project. The problem is in the quantity. If many small software components are developed for wrong purposes, the tangle of small problems can become a very big problem.

There are many levels of requirements. We can consider a code unit as a hierarchy of smaller units and as a part of the bigger hierarchy. Sometimes a logical unit can be separated in different physical units. For instance one header file, two files with implementation code and one document in the project's database. We can make different logical and physical hierarchies for different purposes.

The biggest "unit" of one project consist of all documentation and source code files. It may be a part of some other hierarchy of related projects, but this isn't interesting for us. We can say, that highest level of user-oriented information are the requirements for the software project. Consequently the highest level of developer-oriented information are the reasons of these requirements.

A source code statement may be considered as smallest unit in our hierarchy. It has his own purposes and reasons. In most cases they are simple to understand by reading the code. They may be hidden too. For instance a developer can use special order of operations by the numerical calculation to get maximal accuracy. Sometimes empty cycles are used to delay the execution. Many developers use "magical" numbers without any explanation. In this situation other developer should guess is 15 a casual value, four lover bits being set to 1, sixteen minus one or something else. These are the cases when a small "right" change of one code line causes an unexpected failure of the program.

Hidden reasons and purposes of some code unit add their darkness for the developer. Usually the higher level of the software are better documented as lover. The opposite situation is rare in commercial companies. If the people make excellent documented parts of unknown whole, the project is as rule unsuccessful.


next up previous
Next: The problem of selection Up: The source of requirements Previous: The source of requirements
2002-03-18