System Development: The Enthusiastic User
The Enthusiastic User, who knows the business procedures intimately, often attempts his hand at programming. A small system is created that works well and then is adopted into the procedures of a company. All is good!
And like as not, buoyed by this success, the Enthusiastic User adds more functionality. At this stage the Enthusiastic User, with any common sense, will get himself trained in the technologies used. But usually, even more functionality is added to the house of cards – layer upon layer.
When it all gets too hard, the Enthusiastic User usually decides to get sick, or retire or find another job. The company is faced with using an essential but unmaintainable administration system. All will work, sort of, for a while, until …
The problems that will become apparent:
- The database system will have capacity, design and efficiency problems
- Code that is lengthy, disorganised and difficult to debug
- Code that is repeated frequently
- Out of date software
- The lack of a Code library
- The lack of coding standards
- Confusing naming conventions
- Lack of Code Refactoring (the process of restructuring code and removing dead wood)
Recovering from the mess may prove difficult, if not impossible.
The User Requirements Document (URD)
The "Enthusiastic User" option is acceptable for departmental solutions, but even then, within tightly controlled limits. But it cannot be used for serious administrative systems that are the life blood of a company.
The system developer seldom has the detailed knowledge of how a business runs, compared with a business user. And equally, business users have little idea of what a computer system can achieve. The way to bridge this gap is through the URD.
The URD sets out formally the business requirements and what the user expects the software to do. No technical knowledge is required by the business user in creating the URD. It is seldom possible that the business user, when first creating the URD, to foresee all the variations that arise from the request. Nor should this ever be attempted.
Programming is a collaborative and reiterative process
It is the interplay between user and developer, which will produce a successful outcome.
The programmer creates a prototype of the changes requested in the URD. Programming the prototype is reiterative, until the changes are finally accepted by the user.
- Eliminates misunderstandings on the part of the user and the programmer
- Includes any additional requirements
- Incorporates new ideas as they become evident
- Excludes exceptions to the rules, as they are found
Finally, the prototype is put into production. Very likely, the final result will look vastly different from the original concepts in the first URD attempt.