What We Say We Want and What We Really Need: Experiences on the Barriers to Communicate Information System Needs

Information system requirements are meant to communicate the relevant needs and intention to a wide range of stakeholders. The requirements form the basis on which the tenders are issued, projects are agreed upon, and service-level agreements are made. However, as the requirements state what the system owners---or the ones who are willing to pay for the system---want the system to achieve, they reflect the owners' views and understanding. This setup is plagued by many weaknesses. First, the system owners are seldom experts in the information system design and therefore they may be unable to state all the relevant requirements comprehensively. Second, no matter how much energy and time is invested in the requirement definition and elicitation, many aspects of the requirements are only revealed during the development and deployment, and remain unforeseen until later on, when the development is well under way. Finally, the required system architecture cannot be appropriately designed, if we do not know the requirements at a sufficient level. In this chapter we reflect our experiences from participating in a number of large, commercial information system development projects in both public and private sectors in which the traditional way of handling the requirements has proven to be insufficient. With the software as a service (SaaSSaaS ) business model, where the goal is frequent releases and continuous delivery of ever-improved services, the associated weaknesses become even more prominent. We propose better practices for specifying systems and suggest concentrating a lot more on the true communication and discussion, focusing always on the most important issues and most important stakeholders only and keeping the vision updated and clear for the whole duration of a system development project and also the system maintenance period.