A. Determinging the Purpose and Requirements of the New System

Introduction

Requirements
Features, properties or behaviours a system must have to achieve its purpose. Each
requirement must be verifiable.

Client Needs & Statement of Purpose
The information gathered from the above activities allows the analyst to formulate a list of needs. Only needs which the client has agreed upon are included. The final list of needs is used to create a statement identifying who the information system is for and what it must achieve. This statement is the purpose of the information system. 

Commonly the Requirements Reports commences with this statement of the purpose followed by the list of identified needs. In some cases it is appropriate to include a list of needs that will not be addressed by the system. 

This ensures both the developers and the client are clear about the scope of the project, that is the boundaries for the system are determined to clearly identify what will be included and what will not be included. 

Often the analyst creates models of the existing system, such as dataflow diagrams and data dictionaries, to assist and inform their efforts. 

Requirements List
The needs are refined to create a list of achievable requirements. In general terms, a requirement is a feature, property or behaviour that a system must have. If a system satisfies all its requirements then
all the identified needs will be met and the system’s purpose will be achieved.

It is necessary to verify that all requirements have been met if we are to accurately evaluate the success of the project. For this to occur, all requirements must be expressed in such a way that they can be verified or tested. 

Consider the statement ‘Customers are to be informed if there will be a delay delivering items’. This is a satisfactory need and may well form part of the system’s purpose, however it is difficult to verify if it has been achieved. It is a subjective statement and is therefore unsuitable as a requirement.  Now consider the statement ‘The system shall email customers if an item cannot be delivered within 5 working days of receiving an order’; this statement can easily be tested and is therefore a suitable requirement. In essence it must be possible to design a test which verifies that a requirement has or
has not been met.

Some requirements will address existing items that must be used by the new system. For instance, existing participants and their skills, hardware and software that will remain or details of an existing network. Any data accessed from other systems should be specified – a context diagram is often useful.

 The set of requirements should address everything the system must do and everything the system must use.

Notice the words “must do” and “must use”; the requirements do not specify details of how the requirements are to be achieved and they don’t specify items unless they must be included. 

It is important that the requirements do not restrict the range and nature of possible solutions unless it is unavoidable. This particularly important for large complex systems where the Requirements Report will be used to obtain quotations and possible solutions from a number of different IT providers.

The Requirements Report should be expressed in such a way that it is understandable to the client and also useful as a technical specification for the new system’s developers. In most instances these two parties have a very different view of the system, hence it is often appropriate for two different versions of the requirements report to be produced. Each version contains the same content organised into a form that meets the specific needs of each party. In essence the Requirements Report forms
a communication interface between the client and the system’s technical developers. 

Ensuring each party understands the Requirements Report is absolutely essential as all
subsequent stages of the SDLC rely on its content.

A. Preliminary Investigation

A preliminary investigation determines whether a quick fix of the existing system will solve the problem or a new system is necessary. 

  • The fundamental operations and problems of the existing system must be understood.

  • Each of the information processes are examined and any deficiencies in the existing system are recorded. 

  • The preliminary investigation takes into account the needs and concerns of all the participants.

    • Participants play an important part in developing a workable system. 
    • These views are gathered using different data collection methods.

B.  Data Collection

  • Data and information are gathered throughout the system development cycle. 
  • Data is used to understand the problem and develop an appropriate solution. 
    • It is also needed to
      • assess the feasibility of a proposal, 
      • design a new system and 
      • evaluate the system.

There are several methods used for data collection, such as 

  • interviews, 
  • surveys, 
  • observations 
  • measurements.

Web designers use a technique called ‘click streaming’ to collect data. It records where individual users click on a Web page and how they navigate through a Web site.

Data collection is very important. 

  • If the data is incorrect, the new system may not meet the needs of the participants. 
  • Data should be gathered in an organised way to ensure nothing is omitted. 
    • During an interview or survey, a person has the right not to answer a question. 
    • The interviewer must take care in writing questions that do not discriminate on the basis of gender, religion, age or political preferences.

After the data is collected it must be carefully interpreted to ensure that the resulting information is valid. 

  • For example, can the results of a survey be generalised to a large group of people. 
  • The reliability of the data is also an issue. If a similar research were conducted at another time and place, would the results be the same?

Data collected needs to be documented for it to be analysed. 

  • A diagrammatic method of documenting data is often used, such as a context diagram, data flow diagram or system flow chart. 
  • These methods are examined later in this chapter.

The analysis of the existing system should determine how the system works, what it does and who uses it.


C. Requirements Report

Client Needs and Statement of Purpose

    • The information gathered from the above activities allows the analyst to formulate a list of needs. 
      • Only needs which the client has agreed upon are included. 
      • The final list of needs is used to create a statement identifying who the information system is for and what it must achieve. 
    • This statement is the purpose of the information system.

The requirement report is a statement about the needs of a new system. 

    • It outlines the aims and objectives (purpose) of the new system and how it will help the organisation. 
      • Based on data collected from the participants. 
      • It must match the goals of the organisation to ensure that management are satisfied with the solution. 
    • Provides an overview of the new system 
      • in terms of the data/information to be used, 
      • the information processes and 
      • the information technology required. 
    • The requirement report is used to develop potential solutions to the problem.

More Information

    • The information gathered from the above activities allows the analyst to formulate a list of needs. 
      • Only needs which the client has agreed upon are included. 
      • The final list of needs is used to create a statement identifying who the information system is for and what it must achieve. 
      • This statement is the purpose of the information system.
Contents of Report
  • Commonly the Requirements Reports commences with 
    • statement of the purpose followed by 
    • the list of identified needs. 
      • In some cases it is appropriate to include a list of needs that will not be addressed by the system. 
      • This ensures both the developers and the client are clear about the scope of the project, that is the boundaries for the system are determined to clearly identify what will be included and what will not be included. 
  • Often the analyst creates models of the existing system, such as dataflow diagrams and data dictionaries, to assist and inform their efforts

Requirements Definition
  • The needs are refined to create a list of achievable requirements. 
    • In general terms, a requirement is a feature, property or behaviour that a system must have. 
    • If a system satisfies all its requirements then all the identified needs will be met and the system’s purpose will be achieved.

  • It is necessary to verify that all requirements have been met if we are to accurately evaluate the success of the project. 
    • For this to occur, all requirements must be expressed in such a way that they can be verified or tested. 
      • Consider the statement ‘Customers are to be informed if there will be a delay delivering items’. 
        • This is a satisfactory need and may well form part of the system’s purpose, however it is difficult to verify if it has been achieved. 
        • It is a subjective statement and is therefore unsuitable as a requirement. 
      • Now consider the statement ‘The system shall email customers if an item cannot be delivered within 5 working days of receiving an order’; 
        • this statement can easily be tested and is therefore a suitable requirement. 
        • In essence it must be possible to design a test which verifies that a requirement has or has not been met.

  • Some requirements will address existing items that must be used by the new system. 
    • For instance, existing participants and their skills, hardware and software that will remain or details of an existing network. 
  • Any data accessed from other systems should be specified – a context diagram is often useful. 

  • The set of requirements should address everything the system must do and everything the system must use. 
    • Notice the words “must do” and “must use”; 
    • the requirements do not specify details of how the requirements are to be achieved and they don’t specify items unless they must be included. 
  • It is important that the requirements do not restrict the range and nature of possible solutions unless it is unavoidable. 
    • This particularly important for large complex systems where the Requirements Report will be used to obtain quotations and possible solutions from a number of different IT providers.

  • The Requirements Report should be expressed in such a way that it is understandable to the client and also useful as a technical specification for the new system’s developers. 
    • In most instances these two parties have a very different view of the system, hence it is often appropriate for two different versions of the requirements report to be produced. 
    • Each version contains the same content organised into a form that meets the specific needs of each party. 

  • In essence the Requirements Report forms a communication interface between the client and the system’s technical developers. 
    • Ensuring each party understands the Requirements Report is absolutely essential as all subsequent stages of the SDLC rely on its content.

Student Activity
  1. The Requirements Report is a particularly critical document when developing systems for larger organisations or when a team of developers will be used. Identify reasons why this is true.

Comments