Information system development

The requirements for an operational planning and execution Logistics Information System are important prerequisites for a successful implementation of such a system. Even though information systems have been with us for decades incorrect requirements, changes of requirements,

misunderstood requirements have not disappeared.

Information Systems Development Methodology is defined as:

A collection of procedures, techniques, tools, and documentation aids which will help the systems developers in their efforts to implement a new information system (Avison and Fitzgerald 2006, 24).

Page 37 of 147

4.5.1. Requirements

Requirements in relation to an information system can be defined as:

everything that the set of relevant stakeholders want from a system. Relevant stakeholders encompass all those people involved with legitimate interests, including those both

internal and external to the organization. It includes end-users, line management, senior management, customers and regulators (Avison and Fitzgerald 2006, 97).

The identification, gathering, analysing, documenting and communication of requirements have been an ongoing source for concern since the introduction of the first information systems. Many consider the requirements to be the most essential part for a development of an information system, but they are often misinterpreted according to Robertson and Roberson (1999). The requirements are definitely important as they determine the functionality of the information system, and getting requirements wrong will have a negative financial impact. Leffingwell (1997) claims that 70-85% of the cost related to rework has its origin from erroneous requirements. Research argues that the rework costs related to correcting erroneous requirements are 80-100 times less if errors are detected at the implementation stage. Figure 4.5.1.1 illustrates the relationship of cost of correcting requirement errors in different phases of the development of the information system (McConnell 1996).

Figure 4.5.1.1 Relative costs of fixing requirements errors

Source: McConnell (1996)

Page 38 of 147

Detecting an erroneous requirement at the requirements stage will involve an insignificant piece of work. Fixing a requirement error at later stages will require more and more rework the later in the process one are when the errors are detected. The rework costs after production and release of the system can be significant.

The traditional requirement process

A traditional process to formulate requirements is illustrated in Figure 4.5.1.2 and this is often how the process evolves in large organizations following the life cycle approach. Some stakeholders have an idea of what the system should look like and how the functionality should be. This paper will focus the development of requirements early in the process on a high end functional level illustrated as the blue frame in Figure 4.5.1.2. In a traditional process these requirements are then systemized by the business and system analysts. Through a time consuming iterative process with interviews, meetings, workshops, surveys, storyboards, etc. the stakeholders and analysts finally agree on a specification for the system which then can be signed off (Avison and Fitzgerald 2006, 97-101).

Page 39 of 147 Figure 4.5.1.2 Requirements in systems development

Source: (Avison and Fitzgerald 2006) Real world problems

The traditional model is described in a generic way and the description of such a theoretical model is not surprisingly in many cases different than the real world. Problems arise regularly and the

following bullet points summarize some challenges experienced during the requirements capture phase:

Requirements capture

 Some important stakeholders may not be identified and the analysts may not capture the

requirements from these. This may lead to higher cost than necessary at a later stage in the process.

Page 40 of 147

 Stakeholders may not be very dedicated to the project for various reasons. It might be they are generally not interested or are very busy with other work. The result may be that some

requirements are not captured or misunderstood.

 Lack of good communication between the analysts and the stakeholders can be a reason that requirements are misunderstood or captured inaccurately. This can easily be the outcome as there are numerous details which are subject to difference in interpretation.

 If the specification is not complete, the analysts will miss some requirements accordingly.

 Users can often over-elaborate requirements and request functionality that is less relevant.

 Stakeholders may not propose relevant requirements due to lack of knowledge of available options.

 Users may disagree on some requirements where the analysts pay attention to the senior managers or the majority of the users. This may not be the best way forward.

 Problems related to requirements might be ignored or neglected if other departments need to be part of the discussions or if the challenges appear to be very costly. This might lead to a revisit to the requirements at a later stage and correspondingly higher cost to the system.

These are some of the real world challenges during a development process (Avison and Fitzgerald 2006, 101-104).

Changing and evolving requirements

Although the capture of the requirements has been a thorough and good process, requirements can change after the specification is finalized. In a real wold business scenario changes occur and the traditional process does not cope well with changes in the requirements after freeze of the

specification. This can be the source for a growing problem if there is a long period from specification until the system is implemented.

Unknowable requirements

A basic anticipation in the traditional requirements process it that subject to dedicated stakeholders doing their best through a thorough and good process, all requirements will be captured. Another approach is that some requirements are so complicated and difficult to understand, that they are beyond the reach of the stakeholders. No matter how hard the team work they will not be able to

Page 41 of 147

capture these complex requirements. Such an example is if there is a new technology and the experience in the team is limited. The customer might not really understand what they need.

Non-functional requirements

Although I will not cover Non-Functional Requirements (NFR) I find it relevant to give a brief introduction to this subject. NFRs are important features of the system describing how the system will perform rather than what the system will do. A system might have good functionality and doing whatever the system is designed for, but the users will not be satisfied if the system e.g. is very slow with lots of waiting. The NFRs are in other words attributes in a system affecting the overall user satisfaction. These NFRs are significant for the performance in the final system and should be addressed accordingly during the process. NFRs typically concern system performance, interfaces, designs, and software quality attributes (Avison and Fitzgerald 2006, 104-107).