Project Topics
Get Complete Project Material File(s) Now! »
An information system
The concept of Information System has been subject to different definitions. Computers are considered to be a part of an IS (Avision and Fitzgerald, 1998). According to Bervall and Welander (1995) the concept of IS has more and more been thought of as a computerised IS. In this work IS means computerised IS. The concept Information System is composed of information and system. Information is interpreted data (Avision and Fitzgerald, 1998; Eriksson, 1986; Langefors, 1966). According to Aggestam (2001)1 the concequence of this is that computers process data and that data only can be information when it has been interpreted by human beings. A system is a number of related objects (Eriksson, 1986; Langefors, 1966; van Gigch, 1997). Systems are related to other systems, have subsystems and they always have a purpose (Avison and Fitzgerald, 1998; Eriksson, 1986). In accordance with this purpose, the boundary of the system can be defined (Avison and Fitzgerald, 1998; Eriksson, 1986). An IS is a part of the whole organisation (Andersen, 1994; Bergvall and Welander, 1996; Avison and Fitzgerald, 1998), which means that an IS is a subsystem in the perspective of the organisation and its purpose is to support the organisation in their striving to reach their business mission, their objectives.
In accordance with the discussion above we can identify three components of an IS:
• Hard- and software (IT).
• Data.
• Human beings.
These three components agree with definitions in the literature (see e.g. Avison and Fitzgerald, 1998; Avision and Shah, 1997; Andersen, 1994). The components are also resources in the IS and consequently in the whole organisation. We can sum up the discussion by saying that An information system represents a computerised system comprising IT, data and human beings. The purpose of this system is to handle information in order to support the organisation achieving their objectives.
By handle information we mean that the system assembles, stores, processes, delivers and presents the information (e.g. Andersen, 1994; Avision and Fitzgerald, 1998). This definition covers important aspects of our research and is also well in accordance with other definitions in the literature, e.g. Andersen, (1994); Avison and Fitzgerald (1998); Laudon and Laudon, (2000). The definition above is illustrated in Figure 4.
Requirements elicitation
The purpose of Requirements Elicitation is to gather data, to acquire more knowledge about the target organisation and its needs, in order to specify requirements for the system. If we do not understand the organisation well enough we have no possibility to successfully develop an IS. Even the most brilliantly designed IS will not be useful if the requirements specification is not correct (Yourdon 1988). Kotonya and Sommerville (1997) prefer to call this activity Requirements discovery in order to reflect the uncertainties in the process. The identification of the relevant sources and the possibility to obtain all necessary information from them are essential (Pohl, 1998). Before Requirements Elicitation can be described we need to define what we mean by the concept of requirement.
Requirements – a definition
There is no common definition of requirement and existing ones differ in their focus. The focus of our research is the phase that precedes the information system development process. Because of that it is not necessary to provide a formal exclusive definition. The main goal is to come to a common understanding about the concept. A working definition for this research is the one that is summarized in Figure 6.
Every requirement has a motive, an origin and a realization object (Karlsson, 1996). A requirement is also a documented result from a process, is needed by the user and is met by the system in order to support the organisation (IEEE-Std.610, 1991; Beyer and Holtzblatt, 1998). This definition covers all the important aspects according to our research. It is also in accordance with the definition used by Leffingwell and Widrig (2000). There are different types of requirements (Kotonya and Sommerville, 1997). We can for example talk about business requirements versus software requirements.
The formulation of a requirement will depend on the level of detail (Beyer and Holtzblatt, 1998; Leffingwell and Widrig, 2000) and consequently what kind of data that have to be gathered in Requirements Elicitation. To have the right level of detail is an important success factor in the information system development process. This is also in accordance of the idea of van Gigch (1991), see section 3.2. In the next section we discuss Requirements Elicitation.
Requirements Elicitation
If you have to solve a problem, for example to specify requirements on an IS, the first thing you need to do is to find out more about that problem (e.g. Kotonya and Sommerville, 1997; Loucopoulos and Karakostas, 1995; Leffingwell and Widrig, 2000). The common name given to activities in order to find out more about the requirements of a system is Requirements Elicitation (Kotonya and Sommerville, 1997). There are number of techniques that can be used in order to reach this objective, for example interviewing and questionnaires, requirements workshops, brainstorming and idea reduction, storyboarding, use cases, role playing, prototyping and modelling. Requirements Elicitation is the most communication-intensive activity in RE and as a result most of the techniques do not come from computer science research (Saiedian and Dale, 2000). The favoured elicitation technique is the interview (Alvarez, 2002). There is also a number of methods in this area, but according to Kotonya and Sommerville (1997) most of the methods can only be used to support analysis after some initial elicitation. The aim of our research is not to identify important aspects in the perspective of particular methods or techniques. Methods or techniques will because of this not be discussed further.
The objective of Requirements Elicitation is to make the hidden knowledge about the system explicit in a way that everybody involved can understand (Pohl, 1998). Good elicitation from the user´s perspective results in them having a better understanding of their needs and constraints (Saiedian and Dale, 2000). From the developer´s perspective a good elicitation results in a clear high-level specification of the problem that is to be solved (Saiedian and Dale, 2000). Requirements Elicitation can be seen as one part of the work in order to determine and specify a requirement. One of the key determinants of the ultimate success of an IS is the assessment of user needs (Browne and Ramesh, 2002). If the user´s real requirements are not discovered the user will not be satisfied with the system – there will not be a successful IS – and this phenomenon explains why it is so important to run the process of Requirements Elicitation in a effective way (Kotonya and Sommerville, 1997).
Requirements Elicitation is an ongoing process (Kotonya and Sommerville, 1997; Pohl, 1998; interpret from Davis, 1993). If a presented requirement is found to be problematic the elicitation, in order to obtain more relevant information, have to start again (Kotonya and Sommerville, 1997). This process requires careful analysis of the organisation, the application domain and business processes where the system will be used and it is not just to ask involved people what they want (Kotonya and Sommerville, 1997; Leffingwell and Widrig, 2000). To carefully analyse the organisation is an important success factor in the information systems development process. Requirements Elicitation is about gathering/eliciting relevant data. This sounds simple, but it is a complex and difficult process (e.g. Kotonya and Sommerville, 1997; Leffingwell and Widrig, 2000: Pohl, 1998). E.g. the relevant knowledge is available in a variety of representations and distributed among many stakeholders, there are conflicting desires, stakeholders have different opinions about the meaning of requirements and rarely have a clear view of their requirements (Davis, 1993; Kotonya and Sommerville, 1997; Leffingwell and Widrig, 2000: Pohl, 1998). To be able to understand complex phenomena, as for example organisations and their IS, we have to study it from different viewpoints. A viewpoint, is according to Kotonya and Sommerville (1997), a collection of information from a particular perspective and by integrating the information from each viewpoint the overall requirements can be derived.
Different dimensions of Requirements Elicitation are well represented in the literature (see e.g. Beyer and Holtzblatt, 1998; Kotonya and Sommerville, 1997; Leffingweel and Widrig, 2000; Pohl, 1998). In order to further illustrate the complexity of Requirements Elicitation we present an approach suggested by Kotonya and Sommerville (1997). We consider this approach to cover the dimensions which are represented in our literature survey. According to Kotonya and Sommerville (1997) there are four components or dimensions to Requirements Elicitation (Figure 7).
Users and other stakeholders
In our literature survey the concepts user and stakeholder occur frequently. Users and other stakeholders are also important sources in the key activity Requirements Elicitation. We consider them therefore to be of central importance when success factors of the information system development process are discussed. The purpose of this section is to discuss the concepts user and stakeholder and to give an overview of different types of stakeholders and their relationships in order to clarify the complexity belonging to the concepts. In our research we use the specific terms to differentiate between the roles.
People or organisations that will be affected by the system and who have a direct or indirect influence on the system requirements are system stakeholders (Kotonya and Sommerville, 1997). There are different groups of stakeholders, with different roles according to the system, and users is only one of these groups (Andersson, 2002). We can state that stakeholder is a more abstract concept in which the concept user is included. There are stakeholders in the actual organisation, but stakeholders can also be found outside the organisation (Avison and Fitzgerald, 1997). Examples are legislators, developers and competitors. This requires that the system´s boundary is defined. In the literature there are different groups of stakeholders and each of these is categorised. Sharp et al (1998) have identified four different groups:
• Developers.
• Users.
• Decision makers.
• Legislators.
We consider this grouping to be at a high level of abstraction. There are different types of developers, users, decision makers and legislators. Despite this we concern this grouping to give a holistic view of the different types of stakeholders that can occur. Different roles may also overlap (Persson, 2001). We consider this is obvious even at this high level of abstraction; legislators can be users, developers can be decision makers and so on. Involvement with the potential users in the development process is considered as an important factor (e.g. Andersen, 1994; Cherry and Macredie, 1999; Pohl, 1998; Sutcliffe and Economou and Markis, 1999). Users are central in Requirements Elicitation. We will briefly discuss the four group identified of Sharp et al and focus on users.
• Developers; can be found both in the actual organisation and outside it, compare with Figure 15. The roles within this group include analysts, designers, maintainers, trainers etc. (Sharp et al 1998). To have the right developers in the team is an important aspect (Champy, 1997). Their skills, experiences and opinions are important for the resulting system. Many projects fail because developers do not truly understand or address the real requirements of the user and his environment (Saiedian and Dale, 2000).
• Legislators; can make rules that affect the development process and the use of the system (Andersson, 2002). E.g. laws, business rules, agreements and contracts. These rules can be compared with limitations for the project. To be aware of relevant rules already before the process starts is important.
• Decision makers; are present the whole development process. This group include managers of the development team, user managers and financial controllers in both the user and development organisation (Sharp et al, 1998). It is important that they all strive against the same goal.
• Users; it is not always clear what the concept applies to and the definition of it is problematic (Göransson and Gulliksen, 2000). There is a number of different ways to interpret the concept (Sharp et al, 1998). According to Avison and Fitzgerald (1995)
“The term “users” is often a catch-call for anyone who works with the system who is not part of the technical team and unlikely to be an expert of computing…But there are many different types of users” (Avison and Fitzgerald, 1995, p. 6)
We agree with Avison and Fitzgerald in their opinion. In reality there is a variety of types of users and it is desirable that all types of users are involved in the development process (Avison and Fitzgerald, 1995). This is in accordance with the notion that relevant knowledge about the organisation is available in a variety of representations and distributed among many users. In the literature there are different approaches to define different types of users (e.g. Faulkner, 2000; Avison and Fitzgerald, 1995).
In order to show how different these types of users can be we have chosen to categorise some groups. This account is from (Avison and Fitzgerald, 1995).
-regular users: Users that regularly e.g. might prepare data for input to the system or interpret results from it.
-casual users: This group has varied use of the system, e.g. executives, and are unlikely to train in the use of each system that they may wish to use.
-external users: These users are not in the organisation, an example is a borrower in a library searching through the author database in the library.
We can see that the differences in different groups of users can be as big as differences between different groups of stakeholders. In accordance with our earlier discussion we conclude that the success in acquiring the knowledge of the organisation in these groups will determine how well the future IS will succeed. In this context we want to stress the fact that ensuring that the users understand their constraints and the resulting impacts on their needs is just as important as identifying their needs (Saiedian and Dale, 2000). We conclude that number of important aspects will belong to the process of acquiring knowledge of the organisation from groups of stakeholders. After discussing these four groups we see that the area is complex. Saidian and Dale (2000) take another approach and discuss stakeholders in two different perspectives, from the customer side and from the developer side. They concern that there are different “key players” according to different sides, see Figure 8.
Table of contents :
1 Introduction
1.1 Aims and objectives
1.2 Way of working
1.3 Results and Future Research
1.4 Outline
2 Background
2.1 An information system
2.2 The development process
2.2.1 The life cycle model
2.3 Requirements elicitation
2.3.1 Requirements – a definition
2.3.2 Requirements Elicitation
2.4 Users and other stakeholders
2.5 Identified Success Factors – A Summary
3 Organisational Change
3.1 Analysing and Describing Organisations
3.1.1 The concept of organisation – a definition
3.1.2 How to analyse and describe an organisation
3.1.3 The frames in the view of information system development
3.2 Organisational change
3.2.1 Organisational change – an overview
3.2.2 The framework of Flamholtz (1995)
3.3 Identified Success Factors – A Summary
4 Success in Information Systems Development
4.1 A Successful Information System
4.2 Explicitly identified success factors – an overview
4.3 Identified Success Factors – A Summary
5 A framework of Important Success Factors
5.1 An Analysis of the Identified Success Factors
5.2 The Framework
6 The Case
6.1 The target Organisation: the Municipality of Vara
6.2 Our Framework in the Perspective of the Case
7 Discussion
7.1 Future Research
References
