Small-Scale Classification Schemes: A Field Study of Requirements Engineering

• Authors: Morten Hertzum
• Venue: Computer Supported Cooperative Work
• Year: 2004

Small-scale classificationschemes are used extensively in thecoordination of cooperative work. This studyinvestigates the creation and use of aclassification scheme for handling the systemrequirements during the redevelopment of anation-wide information system. Thisrequirements classification inherited a lot ofits structure from the existing system andrendered requirements that transcended theframework laid out by the existing systemalmost invisible. As a result, the requirementsclassification became a defining element of therequirements-engineering process, though itsmain effects remained largely implicit. Therequirements classification contributed toconstraining the requirements-engineeringprocess by supporting the software engineers inmaintaining some level of control over theprocess. This way, the requirementsclassification provided the software engineerswith an important means of discretely balancingthe contractual aspect of requirementsengineering against facilitating the users inan open-ended search for their systemrequirements. The requirements classificationis analysed in terms of the complementaryconcepts of boundary objects and coordinationmechanisms. While coordination mechanisms focuson how classification schemes enablecooperation among people pursuing a commongoal, boundary objects embrace the implicitconsequences of classification schemes insituations involving conflicting goals.Moreover, the requirements specificationfocused on functional requirements and providedlittle information about why these requirementswere considered relevant. This stands incontrast to the discussions at the projectmeetings where the software engineers madefrequent use of both abstract goal descriptionsand concrete examples to make sense of therequirements. This difference between thewritten requirements specification and the oraldiscussions at the meetings may help explainsoftware engineers' general preference forpeople, rather than documents, as theirinformation sources.