Analysing the system requirements

We said previously that the systems analysis stage involved investigating the problem in detail and how any proposed system would solve the problem. We have said that one of the first things the Systems Analyst needs to do is become familiar with the business and expert in the area of the problem that needs solving. They must understand:

  • The way the system currently work.
  • Problems with the current system.
  • Aspirations of the company. What do they want the new system to do that the old system doesn't do?

They find out about these things by using fact-finding methods such as interviews and collecting existing documentation. They summarise what they find out and include these summaries in the deliverable for this stage, which is the Systems Analysis Report. There are a number of ways that information can be summarised in the Systems Analysis Report. These include:

1.Written descriptions of current methods and systems. 
2.Dataflow diagrams (DFDs). 
3.System flowcharts. 
4.Jackson diagrams. 
5.A data dictionary. 
6.Written descriptions of problems. 
7.Requirements specification. 
8.Possible outline solutions. 
9.Hardware and software constraints. 

Written descriptions of current methods and systems

A good starting point for a Systems Analyst when investigating a new problem in an unfamiliar business is to write out how each system in the problem area operates in as much detail as possible. This should be done: •By describing systems using the present tense.

  • By describing systems as though the Systems Analyst is 'a fly on the wall', an observer.

For example, consider a school library that is completely paper-based. A Systems Analyst has been asked to investigate computerising the library. They would arrange an interview with the librarian who would then explain how each of the sub-systems in the library work. One sub-system might be the one used to take books out. The Systems Analyst would listen to what the librarian says and then produce a written description of it. It might go something like this:

  • A pupil selects a book from the shelf and takes it to the checkout counter. They present the book and their membership card to the librarian. The librarian retrieves the member's details from the 'members card index system'. She then checks how many books the pupil has out already. If it exceeds 3 then the pupil is told that they must return a book before they can take any other out. The librarian also checks to see if the membership has been 'blocked'. This can occur if a fine hasn't been paid for an overdue book or if the pupil has been misbehaving. If the pupil has got less than 3 books and the account has not been blocked, then the librarian transfers the title and author details to the member's card and also the date the book is due back. This card is then filed. The librarian then retrieves the 'book details' card from the 'borrowed book card index system' and records the pupil's membership number on it and the return date. This is filed. The book is stamped with the return data and returned to the pupil with their membership card.

Of course, the Systems Analyst will want to go back to the librarian and read back the description after it has been written up, just to check that they have understood everything correctly and that nothing has been missed out. The above example is for the 'Taking a book out' sub-system. The Systems Analyst would also need to write descriptions for such sub-systems as:

  • The 'returning a book' sub-system.
  • The 'blocking a pupil' sub-system.
  • The 'fine' sub-system.
  • The 'adding a new book to the library' sub-system.
  • The 'removing a book from the library' sub-system.
  • The 'adding a new member' sub-system.
  • The 'removing a member' sub-system.
  • The 'reserving a book' sub-system.

Describing these sub-systems, arranging interviews, writing them up, summarising them and then checking that they are accurate and complete descriptions is not a 5 minute job! A lot of information is going to be generated and, following on from written descriptions, the Systems Analyst will want to use special diagrams to bring the information together.

Dataflow Diagrams (DFD)

Dataflow diagrams, or DFD diagrams, are used to summarise the flow of data around a system. Written descriptions are fine, but pulling a lot of information together in the form of a diagram helps everyone involved 'see' what is going on in the system a lot easier. Because systems such as the library can get quite complicated, they should be broken down into sub-systems, as we have already explained. Each one can then be described and then a DFD can be drawn for each one. There are only four basic symbols in a DFD (not counting the big system box in the Level zero diagram).

  • An oval, representing an entity. This is someone or something that puts information into the system or receives information from it.
  • An arrow, representing a flow of data from one place to another.
  • A box, which represents an action or processing on some data.
  • A long box, which represents a store of data

System flowcharts

A similar but different type of Dataflow Diagram is known as a 'system flowchart'. This type of diagram also gives an overall picture of a system. A systems flowchart shows similar information to DFDs in that it shows the processes that happen on data along with the data flows. In addition, however, these diagrams also show what hardware is used for input, what hardware is used for output and also the data storage devices. They also show what type of file is being used, for example, whether it is a master file or a transaction file. Both system flowcharts and DFDs are used by analysts to show whole systems.

Data dictionary

The data dictionary holds information about data! Any system needs data to make the system work. The Systems Analyst must construct a dictionary of all the data items used in the system because this information will be needed by the people who actually build the new system, who write the software. This point of reference for information about data items is known as the 'data dictionary'. They tell somebody the form of the data, how each data item is actually made up. Data dictionaries are often best done as a table, using the following headings:

  • The name of the data item.
  • What synonyms there are for the data item.
  • Data type. (Whether it is a real number, an integer, a text, a character, a Boolean, a date and so on).
  • Validation rules that apply. (For example, the range of allowable values for integers, the number of allowable characters for text, the allowable characters for a character, the way that the date has to be entered, the number of decimal points allowed, for example).
  • Examples of typical data entries.
  • The origin of the data, where it comes from, how it is generated in the first place, where it is stored.
  • What exactly the data item is used for, what happens to it, why it is part of the system at all.

The Systems Analyst will start the data dictionary at the beginning of the project and, like the list of problems, will add to it as new information becomes available. Some of this information may come from interviews, but much may come from existing documentation. One reason why collecting documents from an existing system is important is that it shows the Systems Analyst what data is needed in the current system, with examples of the data, where data comes from, how it is used and so on. This information can be summarised using a data dictionary and then used as a definitive reference.

Written descriptions of problems

As interviews progress and the Analyst becomes more familiar with the existing system, problems with it will emerge. People using the current system and methods will highlight problems and the Analyst will notice others. For example,

  • System users might complain about things not working as it should.
  • Users might complain about some tasks being time-consuming or requiring a lot of paperwork.
  • Customers might complain that they never get the right information at the right time.
  • It might become obvious to the Analyst that some tasks are labour-intensive and could be easily automated.
  • It might become obvious to the Analyst that some tasks which should be possible and which an organisation has never thought about doing are simply not possible with the current set-up.

For example, in the paper-based library example, the librarian might during interviews bemoan the fact that she has to use two different card index systems, one so she can search for members and the books they have out and one so she can search for books to see which member has it out! The Systems Analyst might do a questionnaire to pupils to find out what they think of the library service and many might comment on how slow the system is or what features they actually like about the current set-up. The Systems Analyst should write a list of all the problems as they come across them! They should also write a brief description explaining why each problem happens. This is often best done as a table.

Requirements Specification (RS)

When the Analyst has fully investigated the problem area of a business, they should have produced the following deliverables for the Systems Analysis stage of the systems life cycle:

  • Written descriptions of current methods.
  • DFDs of current methods.
  • System flowcharts.
  • Structure diagrams of current methods.
  • A data dictionary of the current system.
  • A table of problems and why they exist.

In summary, the Analyst now understands the business, the problems in detail and the methods used at the moment. Note that they have as yet not started work on designing the detail of a new computerised system. Having said that, the Analyst will have been considering how the problem can be solved. They will have been investigating alternative solutions and weighing them up against each other. They will have a good idea where the solution will come from, but they haven't got down to the detail of designing the new system yet. This is because they have not actually agreed with the customer what the final system will be able to do! This is the next job in this stage. The Analyst should work on producing one of the most important deliverables in the project, the Requirements Specification. This document will form the contract between the company needing a new computerised system and the company who will make the new system:

1.What the customer expects the system to be able to do. 
2.How, when the project is complete, the final product will be judged. 

Each item in the Requirements Specification should state a way that the success or failure or degree of success of that item can be measured. When the project is finally finished, it is the Requirements Specification that is used by the customer to check that they have got what they agreed to buy and it is used by the Systems Analyst to check that they have made what they said they would make, to the standard they said they would make it to.

SMART requirements

When you are writing a Requirements Specification, one way to help you write excellent requirements as opposed to wishy-washy ones, is to ensure each requirement is SMART.

  • Specific. Each requirement must be clearly described and easily understood by everyone.
  • Measurable. You should be able to write down tests that can measure the requirement. Requirements such as 'user-friendly', ' easy to use', 'effective' and 'pleasing to the eye' for example, are difficult to measure. 'Fast' is easy to measure because you can set tests e.g. must be able to display a customer's account details in under 0.5 seconds.
  • Agreed. The customer and the Project Manager must agree on each requirement and the way it will be measured.
  • Realistic. Each requirement must be realistically achievable, taking into account the resources and budget.
  • Trackable. The project manager must be able to monitor and measure the progress of the achievement of a requirement. For this to happen, the requirement must be something tangible, something that they can see being developing, something that they can tell has been finished.

The process of producing an agreed Requirements Specification (RS)

The Systems Analyst will use the written description of problems as a starting point to producing the RS. They will produce a 'draft RS'. In the draft RS, the Analyst will set out what she thinks the customer should expect from the new system, what the new system will be able to do and how success/failure will be measured. She will then arrange a meeting with the customer so that they can discuss the draft. Both the customer and the Analyst may well want to make a few changes as a result of the meeting. The Analyst then goes away and re-drafts the RS. Another meeting is arranged and the re-draft is discussed. If everyone is happy, both parties sign and date the RS. If more work needs to be done on it, then it is re-drafted again.

Possible outline solutions

Once the Requirements Specification has been completed, the Analyst can start outlining solutions. They need to think about what software will be used and how the features of the software will be employed to meet the requirements laid down in the Requirements Specification. It is always possible in a piece of software to approach a problem in different ways. The Analyst should document some of these possible approaches. They could also look at different applications to solve the problem and compare and contrast the ability of each application to meet the needs of the Requirements Specification. They may also look at designing a completely new application from scratch.

Whichever of the solutions is preferred, it should be justified. There should be a clear statement which identifies the features of the software that will solve the problem as laid out in the Specification.

Hardware and software constraints

The Analyst needs to produce a list of the hardware and software that is being used in the current system (if applicable). When a list has been drawn up of what exists currently, they should then comment on how this may or may not impact on any future solution. They might be able at this stage to identify that certain software is being considered for a solution, but the software cannot be run on the existing machines because they are not of the right specification, for example. It may be that there are only standalone computers at a business but the analyst is thinking of using email and shared resources that require a network. It may be that an operating system needs to be updated or printing facilities need to be reviewed.

The Analyst should then draw up a list of any new software and hardware that will be needed. They should also justify these proposed purchases to the company so that they are clear about the reasons for spending their money on this equipment.

Once the Requirements Specification is completed and agreed to, the real work can begin! The Systems Analyst can start designing the detail of the new computerised system in the next stage of the systems life cycle - the Design stage.

Business | Systems

QR Code
QR Code analysing_the_requirements_of_a_system (generated for current page)