In the early 1980's there was very little "tool support" for the requirements process. Very few IT workers had access to PC's. I first started using a PC at work in 1987. We had a team size of 30 and we had to "sign up" for 1/2 hour blocks to use two PC's. The PC's had a basic text editor for composing simple documents.
We also used a PC tool called "Excelerator" that allowed us to manage basic architectural deliverables such as data flow diagrams and functional decomposition charts (they looked like company organization charts, that hierarchy described the functional architecture of an application). Processes were documented with data flow diagrams, that often zoomed down multiple levels.
I remember these PC's having 10mhz processors and 256K memory. We had a 512K "buffering" system that allowed us to print large documents to the printer. These were very basic PC's, yet their impact on our work was extensive. We could edit and change documents ourselves and present them again to users!
Business processes were considered "unstable" so the vogue thing was to do "data analysis". The idea was to interview the customer, review reports, etc. and perform a normalization (third normal form) of the data. The database and data entry "screens" were developed based on populating the third normal form of the data.
Many users complained that these "data oriented" systems did not align to the way they did business. Business users complained that they were just data entry clerks. We would reply that the data had to be entered so that it could later be reported on and analyzed. The users were often "forced" to use these systems, as much money had been spent, and at the end of the day they would basically work to capture data, move it to where it was needed and allow for analytical functions.
It was very typical that the first systems produced by these data oriented methods were not much more than prototypes. Often the users complained and many changes had to be made until the system was at the minimum "acceptable". Systems were not as complex as they are now, so requirements were often more simple, yet the methods used results in a "hit or miss" fulfillment of user requirements.
I remember a timesheet system we developed for a customer. In the first rendition, the "users" (blue collar folk) detested the system so much they would put a wrench through the screen in disgust. We'd get plenty defacement of company IT property. Eventually the system was streamlined so that it became acceptable enough so that damaged equipment no longer was problem and users could enter their timesheets with minimal fuss.
Requirements were generally written using the Victorian novel approach. If you wrote enough about it, stakeholders would make changes until they cried "Uncle" and signed off! There was some movement towards rudimentary requirements statements, as some methodologies enforced the word "shall" or "must" in requirements statements. Forget structured requirements statements, requirement id's, traceability and use cases - that would come in the 1990's!
My next blog entry will talk about requirements gathering in the 1990's.
