Requirements analysis Details, Meaning Requirements analysis Article and Explanation Guide

Requirements analysis Guide, Meaning , Facts, Information and Description

Requirements Analysis is an important part of the software engineering project process. It is the process by which business analysts or software developers identify the needs or requirements of a client. Having identified these requirements they are then in a position to design a solution. For most of the history of software engineering it has been considered to be a relatively easy part of the process. However, in the last decade or so, it has become recognised as an vital part of the process, and is often the cause of project failure or overrun. If the requirements are wrongly identified in the first place, it makes it highly unlikely that the finished piece of software will suit the needs of the client.

Table of contents

1 Introduction
2 Problems
3 Techniques

3.1 User Interviews
3.2 Requirement workshops
3.3 Contract style requirement lists
3.4 Prototypes

Introduction

If you imagine a scenario, a person approaches a company and asks them to build a system to carry out some task, or automate some task for them. This is all very well, but what do they require the system to do?

The main issue of requirements analysis is to truly find out what the person wants, and find it out in detail. Only this way can a system that truly meets their needs be made.

Problems

The problems involved with requirements analysis are increasingly well known.

Typical problems caused by software developers are:

Software developers and the end user often have different vocabularies. Consequently, they can believe they are in perfect agreement until the finished product is supplied.
Software developers often try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client.
Analysis is often carried out by software developers, rather than business analysts, and often software developers lack the people skills and real world knowledge to understand a business process properly.

Steve McConnell, in his book Rapid Development, details a number of ways users can inhibit requirements gathering:

Users don't understand what they want
Users won't commit to a set of written requirements
Users insist on new requirements after the cost and schedule have been fixed.
Communication with users is slow
Users often do not participate in reviews or are incapable of doing so.
Users are technically unsophisticated
Users don't understand the software development process.

One of the solutions to this problem has been recognising that requirements analysis is a specialist field best carried out by experts. Business or system analysts, who could bridge the gap between the business and IT worlds were seen as the answer. However, while this has helped, this has by no means solved the problem, because the techniques used to analyse requirements have not proved sufficiently effective.

Modern techniques introduced in the 1990s like UML, use cases, and Agile software development seem closer to resolving the dilemma.

Techniques

Requirements Analysis can be a long and arduous process. Analysts can employ serveral techniques to get the requirements from the customer. Historically this has included such things as holding interviews, or holding focus groups (more aptly named in this context as requirements workshops), creating requirements lists and prototyping. Hopefully, through a process employing many of these methods, exactly what the user needs will be established, so that a system which meets their needs may be produced.

User Interviews

User interviews are obviously necessary in requirement specification. However, in any large system a number of individuals need to be interviewed, which increases the time and cost; but more importantly almost always this reveals major discrepancies with regard to how the existing business procees works and how it should work in the future. Also different users might have differing or even contradictory requirements.

Requirement workshops

Therefore where systems are complex the usual method is to use requirement workshops, where the analyst brings the main stakeholders in the system together in order to analyse the system and develop the solution.

Such workshops are ideally carried out off site, so that the stakeholders are not distracted. They usually have a facilitator to keep the process focused, a scribe to document the discussion, and usually make use of a projector and diagramming software. Often multiple workshops are required to bring the process to a successful conclusion.

Requirements workshops are considered to be a very useful technique which can save significant time. However, it can be hard to get all the required stakeholders together at one time.

While they are an excellent technique for modelling the existing system, they are not so useful for gaining agreement on the nature of the solution.

Contract style requirement lists

The most common way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages. In addition, these requirements lists do not lend themselves to application. Such lists provide a checklist for the eventual system; but they do not help in system design.

Such lists are very much out of favour in modern analysis; but they are still seen to this day.

Prototypes

In the mid-1980s, prototyping became seen as the solution to the requirements analysis problem. Prototypes are mock ups of the screens of an application which allow users to visualize the application that isn't yet constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. When they were first introduced the initial results were considered amazing. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of the screens led to fewer changes later and hence reduced overall costs considerably.

However, over the next decade, while proving a useful technique, it did not solve the requirements problem:

Managers once they see the prototype have a hard time understanding that the finished design will not be produced for some time.
Designers often fill compelled to use the patched together prototype code in the real system, because they are afraid to 'waste time' starting again.
Prototypes principally help with design decisions and user interface design. However, they can't tell you what the requirements were originally.
Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process.

This is an Article on Requirements analysis. Page Contains Information, Facts Details or Explanation Guide About Requirements analysis