Introduction to Requirements Engineering

1
Introduction toRequirements Engineering

• 28.10.2001
• Marjo Kauppinen
• Qure Project
• Software Business and Engineering Institute
  (SoberIT)
• Helsinki University of Technology (HUT)

2
Agenda

• Basics of Requirements Engineering (RE)
• Requirements
• User Requirements Document
• Requirements Definition Process
• Summary

3
Basics of Requirements Engineering (1/2)
specification design coding testing
acceptance testing
requirements definition
requirements management
4
Basics of Requirements Engineering (2/2)

• Requirements engineering (RE)
  means that
  requirements for a system are defined, managed
  and tested systematically.
• Requirements engineering
• covers all of the activities involved in
  discovering, documenting, and maintaining a set
  of requirements for a system. The term
  engineering implies that systematic and
  repeatable techniques should be used to ensure
  that system requirements are complete,
  consistent, relevant etc. Som97

5
What are Requirements? (1/4)
user and customer requirements for SYSTEM
technical requirements for SYSTEM
User/customer requirements documents
Technical specifications
Project plan
requirements for PROJECT
6
What are Requirements? (2/4)
User/Customer Requirements Document
Technical Specifications
Requirements Definition
Design
Specification
7
What are Requirements? (3/4)
user/customer requirements
business requirements
technical requirements
requirements definition process
specification process
How?
Why?
What?
8
What are Requirements? (4/4)

• User The person who operates directly with the
  system IEE93.
• Customer The person who pays for the system and
  usually (but not necessarily) decides the
  requirements IEE93 .
• Requirement A function, constraint or other
  property that the system must provide to fill
  the needs of the systems intended user(s)
  Abb86.
• Constraints and properties are also called
  non-functional requirements or quality
  requirements.

9
What are User Requirements? (1/7)

• Why are user requirements important?
• If a system doesnt satisfy users requirements,
  it is useless.
• In the worst case, the system is not taken into
  use at all.
• The most successful systems exceed users
  expectations.

10
What are User Requirements? (2/7)
user group A
user group B

• User requirements tell WHAT the system shall do
  from users point of view.
• We are interested in only those functions and
  properties visible to the users.
• The system is seen as a black box.

11
What are User Requirements? (3/7)

• Functional requirement A requirement that
  specifies a function or service that a system
  must be capable of performing from users point
  of view.
• Non-functional requirement A requirement that
  describes the property of the system including
  performance, reliability and usability.

12
What are User Requirements? (4/7)
13
What are User Requirements? (5/7)
14
What are User Requirements? (6/7)

• Characteristics of a good user requirement
• One requirement per one sentence.
• Clear structure
• Functional requirement The user shall do
  something.
• Property The minimum font size shall be 14.

15
What are User Requirements? (7/7)

• Characteristics of a good user requirement
• Correct A requirement contributes to a real user
  need.
• Understandable A reader can easily understand
  the meaning of the requirement.
• Unambiguous A requirement has only one possible
  interpretation.
• Verifiable A requirement can be tested.

16
User Requirements Document (1/18)

• is official statements of user requirements
• says what the system should do without specifying
  how.

17
User Requirements Document (2/18) Contents

• Introduction Short description of the system and
  goals/benefits of the system
• Glossary Short descriptions of the special terms
  used in the document
• Overview of the system
• Users
• Functional requirements
• Non-functional requirements Performance,
  reliability, usability etc.
• Constraints Standards, software and hardware
  constraints required by customer

18
User Requirements Document (3/18) Contents
Overview of the system

• Main functions (services) of the system
• Use case diagrams are a good way to describe the
  main functions and the users of the system.
• Basic principle The system is seen as a black
  box. We are interested in only those functions
  visible to the users.

19
User Requirements Document (4/18) Contents
Overview of the system Example of Use Case
Diagram Handling Emergency Alarm Call
Konect System
Making Emergency Alarm Call
passenger
service center operator
Dispatching Job
Helping Passenger out of Elevator
Reporting
serviceman
Kone Research Center has given a permission to
present this use case diagram as an example.
20
User Requirements Document (5/18) Contents
Overview of the system Checklist for Use Case
Diagrams

• Are the actor names consistent and unambiguous?
• Is it clear which use cases are inside and which
  outside the system?
• Are the use cases written from the users point
  of view not from the systems point of view?
• Does the use case diagram have too many use cases
  (not more than 8)?
• Is the use case diagram clear and easy to read
  (not a spiders net)?

21
What Is the Contents of User Requirements
Document? (6/18)
Users
Name of user group Description Number of users
Passengers Passengers are persons that use an elevator. Tens of thousands
Service operators Service operators are persons that monitor the status of the elevators. 50
Servicemen Servicemen are persons that make both regular service visits and call up (fault) visits. 3000
22
User Requirements Document (7/18) Contents
Functional Requirements

• Use cases are a good way to document functional
  requirements.
• Use cases originally developed by Jacobson and
  Rumbaugh Rum94.
• Rum94 J. Rumbaugh, Getting Started Using Use
  Cases to Capture Requirements, JOOP, September
  1994.

23
User Requirements Document (8/18) Contents
Functional RequirementsTemplate for Use Case
Description

• Use Case Name of the use case
• Summary Short description of the use case
• Actors List of users and other systems that
  interacts directly with a system
• Preconditions Description of start situation
  and goals of the users
• Basic sequence Descriptions of the main actions
  of the user
• Exceptions Descriptions of special situations
• Postconditions Description of end situation

24
User Requirements Document (9/18) Contents
Functional RequirementsExample for Use Case
Description

• Use Case Making Emergency Alarm Call
• Preconditions An elevator has stopped between
  floors and there is a passenger in the elevator.
  The passenger wants to get out of the elevator
  safely and as fast as possible.
• Actors Passenger and service center operator
• Summary An entrapped passenger pushes the
  emergency alarm button in order to get help. A
  service center operator receives the emergency
  alarm call and informs the passenger that a
  serviceman will come and let the passenger out of
  the elevator.
• Kone Research Center has given a permission to
  present this use case as an example.

25
User Requirements Document (10/18) Contents
Functional RequirementsExample for Use Case
Description

• Basic sequence
• Step 1 The passenger presses the emergency alarm
  button.
• Step 2 The service center operator gets a
  visible notification about the emergency alarm
  call on the screen with an optional audio signal.
• Step 3 The service center operator accepts the
  emergency alarm call to be handled.
• Step 4 The system opens voice connection between
  the service center operator and the passenger.
• Step 5 The system indicates the service center
  operator and the passenger that voice connection
  is open.
• Step 6 The system guides the service center
  operator what information to ask from the
  passenger.
• Step 7 The service center operator informs the
  system that the emergency alarm call is correct.

26
User Requirements Document (11/18) Contents
Functional RequirementsExample for Use Case
Description

• Exceptions
• Step 1 If an entrapped passenger does not push
  the alarm button long enough (less than 3
  seconds), the system alerts the passenger with
  voice announcement.
• Step 7 If the passenger has pressed the
  emergency alarm button by accident, the service
  center operator informs the system that the
  emergency alarm call is false. The system resets
  the emergency alarm call.
• Postconditions The entrapped passenger knows
  that service center operator will contact a
  serviceman who will be helping the passenger out
  of the elevator safely and as soon as possible.

27
User Requirements Document (12/18) Contents
Functional RequirementsChecklist for Use Case
Descriptions

• Is the use case description too long (not more
  than 15 actions)?
• Is the use case description logical from users
  point of view?
• Does the use case describe the functions from the
  users point of view?
• Is the use case described using users language
  not computer slang?
• Does the use case contain no design and
  implementation information?

28
User Requirements Document (13/18)Characteristics
29
User Requirements Document (14/18)Characteristics
30
User Requirements Document (15/18) Purpose

• to describe what a system does from the users
  point of view
• to get feedback from users and customers
• to guide design
• to guide testing
• to guide project planning and follow-up
• to provide material for user manuals
• to provide material for marketing and selling

31
User Requirements Document (16/18) Stakeholders
users
designers
User Requirements Document
customers
testers
marketing and sales personnel
user manual writers
project manager
32
User Requirements Document (17/18) Objectives
33
User Requirements Document (18/18) Objectives
Quality of Software Product
Quality of Software Project
Quality of Requirements Document
Quality of Requirements Engineering Processes
34
Requirements Definition Process (1/14)
specification design coding testing
acceptance testing
requirements definition
requirements management
35
Requirements Definition Process (2/14)
user requirements document
business requirements
requirements definition process
requirements elicitation
requirements analysis
requirements representation
requirements validation
36
Requirements Definition Process (3/14)

• Elicitation is the process of discovering the
  requirements for a system
• through consultation with users, customers and
  other stakeholders
• from system documents, domain knowledge and
  market studies
• through brain storming.

37
Requirements Definition Process (4/14)

• Realities of requirements elicitation
• Stakeholders do not often know what they want.
• Users and customers use a language of their own.
• Different stakeholders have different viewpoints.
• The business environment is dynamic.

38
Requirements Definition Process (5/14)

• Requirements elicitation practices
• Identify and consult all stakeholders.
• Record requirements sources.
• Record requirements rationale.
• Prototype poorly understood requirements.
• Define users processes.

39
Requirements Definition Process (6/14)

• Analysis is the process of establishing an agreed
  set of requirements and discovering
• missing requirements
• requirements conflicts
• ambiguous requirements
• overlapping requirements
• unrealistic requirements.

40
Requirements Definition Process (7/14)

• Realities of requirements analysis
• Conflicting requirements require negotiations.
• Proper analysis requires hard thinking, time and
  effort.

41
Requirements Definition Process (8/14)

• Requirements analysis practices
• Use checklists for requirements analysis.
• Plan conflict resolution.
• Prioritise requirements.
• Assess requirements risks.

42
Requirements Definition Process (9/14)

• Representation is the process of describing
  individual requirements in a
• concise,
• understandable, and
• unambiguous way.

43
Requirements Definition Process (10/14)

• Realities of requirements representation
• Requirements are read more often than they are
  written.
• Readers of requirements come from diverse
  backgrounds.
• Writing clearly and concisely is not easy.

44
Requirements Definition Process (11/14)

• Requirements representation practices
• Use standard templates for describing
  requirements.
• Use simple and consistent language.
• Use diagrams.
• Specify requirements quantitatively.

45
Requirements Definition Process (12/14)

• Validation is the process of checking the
  requirements for
• omissions,
• conflicts, and
• ambiguities and
• for ensuring that the requirements follow quality
  standards.

46
Requirements Definition Process (13/14)

• Realities of requirements validation
• The main problem of requirements validation is
  that there is no existing document which can be a
  basis for the validation.
• If you do not allow sufficient time for
  validation, you will almost certainly end up with
  requirements problems.

47
Requirements Definition Process (14/14)

• Requirements validation practices
• Organise formal requirements inspections.
• Use multi-disciplinary teams to review
  requirements.
• Use validation checklists.
• Write a draft user manual.
• Propose requirements test cases.

48
Summary (1/2)
Requirements Engineering
Design, coding and system testing
Acceptance testing
User requirements definition
User requirements management
Useful and Successful Products
49
Summary (2/2)

• There is huge potential for improvement in RE.
• RE is a big challenge and an opportunity for
  organisations and individuals.

50
References

• Abb86 R. Abbott, An Integrated Approach to
  Software Development, John Wiley, New York, 1986.
• Hsi93 P. Hsia, A. Davis and D. Kung, Status
  Report Requirements engineering, IEEE Software,
  pp. 75-79, November 1993
• IEE94 IEEE Recommended Practice for Software
  Requirements Specifications, IEEE Std 830-1993,
  the Institute of Electrical and Electronics
  Engineers, New York, 1994
• Kot98 G. Kotonya and I. Sommerville,
  Requirements Engineering - Processes and
  Techniques, John Wiley Sons, New York, 1998.
• Saw99 P. Sawyer, I. Sommerville and S. Villier,
  Capturing the Benefits of Requirements
  Engineering, IEEE Software, pp. 78-85,
  March/April 1999.
• Som97 I. Sommerville and P. Sawyer,
  Requirements Engineering - A Good Practice Guide,
  John Wiley Sons, New York, 1997.

51
Literature

• S. Robertson, J. Robertson and G. Weinberg,
  Mastering the Requirements Process,
  Addison-Wesley Pub Co, 1999
• G. Kotonya and I. Sommerville, Requirements
  Engineering - Processes and Techniques, John
  Wiley Sons, New York, 1998.
• G. Scheider and J. Winters, Applying Use Cases, A
  Practical Guide, Addison-Wesley Pub Co, 1998.
• A. Cockburn, Writing Effective Use Cases,
  Addison-Wesley Pub Co, 2001.
• D. Kulak and E. Guiney, Use Cases Requirements
  in Context, Addison-Wesley Pub Co, 2000.