1. Requirements Engineering
FYP Preparation
Requirements Engineering

2. What is Requirements Engineering?
“An investigation and description of the problem domain and requirements. Followed by the design and documentation of the characteristics for a solution system that will meet those requirements” [Bray, 2002]
Kovitz provides a similar definition when he describes requirements engineering as “the process of converting an open-ended problem into a well defined problem” with an appropriate solution.[Kovitz, 1999]

3. Why is Requirements Engineering so Important?
Appropriate requirements engineering is fundamental to the success of any software engineering project because it provides the foundation upon which the rest of the project is built.
Inaccuracies, errors and omissions during this pivotal stage can result in problems that can significantly increase the cost and duration of the project.
 A project designed and built around an incorrect understanding of the original problem domain, will result in the production of a system that does not fulfil the needs of the planned user group or client.

4. Examples
Performing Rights Society. (PROMS) Project. This project was abandoned in 1992 after £11 million had been invested. Poor requirements engineering was the key factor. It was reported that the system requirements were produced in such a way that the user group could not understand or check the planned functionality.
London Stock Exchange TAURUS Project. Cancelled in 1993 with an estimated total failure cost of £480 million. It was determined that failure to reconcile conflicting system requirements was at the root of the project breakdown.
London Ambulance Service Despatch System. Closed down in 1992 after two days of operation. Sutcliffe identified the major problem with the project as a poor requirements analysis. [Sutcliffe, 1998]

5. Why is Requirements Engineering so Difficult?
We can assume, in its simplest form, that requirements engineering is about solving problems.
Logically, this implies that in order to solve the problem appropriately we must first fully understand what the problem is.
Thus the task of requirements engineering is doubly difficult, as the engineer needs to:-
Gather the domain of knowledge from a variety of sources, for any given system and superimpose this upon the expertise required for the requirements engineering itself.
The best source of domain knowledge will usually be the existing or potential system users, this also introduces the difficulties of communication and knowledge transfer.

6. Basic Terminology and Concepts
The problem domain
The problem domain can be defined as the part of the universe within which the problems exist.
It can equally be regarded as the part of the world within which the new system solution (or application) will operate in order to produce the required effects.
Example Problem: “We want a system to increase the effectiveness of our current stock control system, used to monitor the flow of stock coming in and out of our warehouse”

7. Basic Terminology and Concepts (contd..)
The Solution System
The solution system, is the system that will eventually be built to solve the problem(s) within the problem domain. (Also called the application or product)
The problem domain and the solution system are interfaced by the system specification.
Analysis concerns the problem domain and the problems that exist within it.
Specification concerns the interaction between the problem and the system solution.
Design (Not a part of the requirements engineering process) concerns the internal workings of the solution.

8. Basic Terminology and Concepts (contd..)
Requirements
“Requirements are the effects that the client wishes to be brought about in the problem domain.” [Bray, 2002]
“A condition or capability that must be met by the system to solve a problem or achieve an objective” [IEEE, 1984]
System solution requirements should include four key elements:-
Functional
Performance
Design
Commercial Constraints 

9. The Requirements Engineering Process
The requirements engineering process can be divided into the five sub-tasks.
Elicitation
Analysis
Specification
Human Computer Interface Design
Validation

10. Elicitation
Elicitation concerns the gathering of information. It is also known as requirements gathering or requirements acquisition.
During this sub-tasks the following considerations must be examined:-
What information should be gathered?
From what sources can the information be collected?
What techniques should be used to gather the required information?

11. 1) The information to elicit
In order to ensure that system requirements and subsequent specifications are correct the following key areas should be explored:-
A full description of the problem domain.
A list of problems that require a solution. (The requirements)
Any client-imposed constraints that are to be imposed upon the system.

12. 2) Sources of information
The principle sources of information about the problem domain are:-
The Client (Authorises or commissions the system)
Client specifications (Any documents produced by the client listing their requirements).
Any pre-existing solution system for a similar domain.
Existing system users.
Potential users of the solution system.
Other products on the market, including competitors products.
Problem domain experts.
Existing system documentation/user manuals/etc.
Relevant technical standards and legislation. (e.g Data Protection Act)
Some of these sources will not be available for every project.

13. 3) Elicitation Techniques
a) BACKGROUND READING
Documents such as business plans, operational procedures, technical manuals and user manuals are a valuable source of problem domain information.
Examine the material and make concise notes that summarise the relevant information. (Much of the material may be irrelevant)

14. b) INTERVIEWING
Interviews are the most commonly used elicitation technique.
The main strengths of interviews include:-
It provides a rich vein of communication. (Verbal and body language)
Flexible (topics can be pursued on the fly, based on subsequent questioning)
It provides the scope to obtain all the required information.

15. c) QUESTIONNAIRES
Questionnaires can be regarded as the ultimate development of the structured interview plan. Every question is pre-planned and then presented with no possibility of elaboration or deviation.
It is thus vital to ensure that questions are constructed carefully, to maximise comprehension and minimise ambiguity.
Whilst the inflexibility is a constraint, it is not always of great significance where questions can be well established in advance.
It is particularly useful when the views of a large number of users are required.
The advantages of interviews can be summarised as, cost effective, capable of reaching a large population and having results that are relatively easy to analyse.
The main disadvantages are the less flexible/probing nature of this technique and the fact that the questions have to be very carefully planned to ensure understanding

16. d) TASK OBSERVATION
Task observation relates to the observation of someone performing a particular task.
From a requirements engineering perspective it is likely to involve watching the users of an existing system and recording what activities they perform within the existing system.

17. e) REQUIREMENTS STRIPPING
This technique is used when a client or user group has supplied a requirements specification document.
The purpose of this activity is to turn generally low quality requirements into requirements of the required level of detail and quality.
During this technique the following activities are carried out:-
The extraction of relevant information and the removal of irrelevant material.
Identification of omissions in the original document.
Using this technique can be very useful in producing a first cut list of system requirements and identifying areas that will require additional investigation.

18. f) LADDERING Laddering is another commonly used elicitation technique.
Comparing the Characteristics of Elicitation Techniques
One of the most difficult considerations for the requirements engineer is deciding which elicitation technique should be used for a given scenario.
The evaluation of characteristics of each approach can help when making a decision as to which technique(s) to employ.