Lecture 5: Requirements Engineering

1
Lecture 5 Requirements Engineering

• Dr Valentina Plekhanova
• University of Sunderland, UK

http//www.cet.sunderland.ac.uk/cs0vpl/SE-Com185.
htm
2
What is a Requirement? Pfleeger, 1998

• A requirement is a feature of the system or a
  description of something the system is capable of
  doing in order to fulfil the systems purpose.

3
What is a Requirement?

• It may range from a high-level abstract statement
  of a service or of a system constraint to a
  detailed mathematical functional specification.
• May be the basis for a bid for a contract -
  therefore must be open to interpretation.
• May be the basis for the contract itself -
  therefore must be defined in detail.
• Both these statements may be called requirements.

4
Wicked Problems Sommerville Vliet

• Originally this term was defined by Rittel and
  Webber, in 1973.
• A wicked problem" is a complex problem, i.e.
  this problem is very difficult to define and/or
  identify (e.g. define related entities,
  definitive problems specification).
• In general, no one can accurately predict
  where/when we can expect the problem and what
  effect it will have on the software production,
  etc.
• The problem can be tackled after it has happened.

5
Wicked Problems

• Most large software systems address wicked
  problems.
• Problems which are so complex that they can never
  be fully understood and where understanding
  develops during the system development.
• Therefore, requirements are normally both
  incomplete and inconsistent.

6
A Stakeholder ..!!!

• The notion of stakeholder is used to refer to
  anyone who should have some influence on the
  system requirements, e.g. end-users, engineers,
  business managers, domain experts, etc.

7
Some Reasons for Inconsistency

• Different stakeholders have different
  requirements and they may define these in
  different ways.
• There is a constantly shifting compromise in the
  requirements...
• Different people may negotiate different parts.

8
Some Reasons for Incompleteness

• Requirements can be interpreted differently.
• Many requirements can be identified clearly only
  after some experience with the system.
• Too many details would need to be specified.
• Customer asks for too little.
• The world changes.
• It is difficult to define the level of precision
  in the requirements statements.
• Informal language (e.g. natural language) does
  not help in requirements statements.

9
Requirements Functional and Non-Functional

• Functional requirements describe system services
  or functions.
• Non-functional requirements is a constraint on
  the system or on the development process, e.g.
  timing constraints, standards, etc.

10
Non-Functional Requirements
Non-Functional Requirements
Process Requirements standards, delivery,etc.
External Requirements ethical, legislative
Efficiency Requirements efficiency, reliability,
portability,usability
11
Requirements Engineering

• The process of establishing the services that
•  
• the customer requires from a system
• under the constraints with which it operates ...
• and is developed!

12
The Requirements Engineering Process
Feasibility Study
Requirements Validation
Requirements Definition
1
5
3
2
4
Requirements Analysis
Requirements Specification
13
1. Feasibility study
1

• Find out if the current user needs can be
  satisfied given the available technology and
  budget?
• A definition of the problems.
• Alternative solutions and their expected
  benefits.
• Required resources, costs, time and delivery
  dates for each alternative solution.

14
2. Requirements Analysis
2

• Find out what system stakeholders require from
  the system.

15
3. Requirements Definition 4. Requirements
Specification

• .
• The ultimate purpose of the requirements-related
  activities is
• To understand the goals of the system
• To document the requirements to be met
• To specify the qualities required of the software
  solution functionality, performance,
  reliability, etc.

16
3. Requirements Definition
3

• A statement in natural language plus diagrams of
  the services the system provides and its
  operational constraints.
• Define the requirements in a form understandable
  to the customer.
• It represent an understanding between the
  customer and developer of what the customer
  needs/wants.
• It is usually written jointly by the customer and
  developer.
• Written for customers.

17
4. Requirements Specification
4

• A structured document setting out detailed
  descriptions of the system services.
• Define the requirements in detail.
• It uses technical terms to define the system
  services a very precise, even mathematical
  description but it must be understandable by
  the client.
• Written as a contract between client and
  contractor.

18
Software Specification

• A detailed software description which can serve
  as a basis for a design or implementation.
• Written for developers.

19
An Example of Requirements Document Structure
(1)

• Introduction
• Describe need for the system and how it fits with
  business objectives.
• Glossary
• Define technical terms used.
• System models
• Define models showing (high level architectural)
  system components and relationships.

20
Requirements Document Structure (cont 2)

• Non-functional requirements definition
• Define constraints on the system and the
  development process.
• System evolution
• Define fundamental assumptions on which the
  system is based and anticipated changes.
• Requirements specification
• Detailed specification of functional requirements.

21
Requirements Document Structure (cont 3)

• Appendices
• System hardware platform description.
• Database requirements (as an ER model perhaps).
• Index
• More examples of requirements document can be
  found in Pfleeger, 1998 Sommerville

22
5. Requirements Validation
5

• Concerned with demonstrating the requirements
  define the system that the customer really wants.
•  
• Requirements error costs are high so validation
  is very important ...
•  
• Fixing a requirements error after delivery may
  cost up to 100 times the cost of fixing an
  implementation error.
•  
• Prototyping is an important technique of
  requirements validation.

23
Requirements Checking

• Validity Does the system provide the functions
  which best support the customers needs?
• Consistency Are there any requirements
  conflicts?
• Completeness Are all functions required by the
  customer included?
• Realism Can the requirements be implemented
  given available budget and technology?

24
Key Points

• It is very difficult to formulate a complete and
  consistent requirements specification.
• A requirements definition, a requirements
  specification and a software specification are
  ways of specifying software for different types
  of reader.
• The requirements document is a description for
  customers and developers.
• Requirements errors are usually very expensive to
  correct after system delivery.
• Reviews involving client and contractor staff are
  used to validate the system requirements.
• Stable requirements are related to core
  activities of the customer for the software. 
• Volatile requirements are dependent on the
  context of use for the system.

25
Week 8 24.04.2003-28.04.2003Project Control
Session

• Tutorial Time 10 minutes for each Team
• Students will present project file, particularly
  Schedule, plus any project documentation.
• Students will describe where they are in the
  project and any problems encountered.
• During the discussion reviewers will ask to see
  evidence of deliverables for any tasks that are
  complete to determine whether they have in fact
  been done.