Introduction to Requirements Engineering

SoberITSoftware Business and Engineering Institute

HELSINKI UNIVERSITY OF TECHNOLOGY

Introduction toRequirements Engineering

28.10.2001

Marjo KauppinenQure Project

Software Business and Engineering Institute (SoberIT)Helsinki University of Technology (HUT)



Agenda

• Basics of Requirements Engineering (RE)

• Requirements

• User Requirements Document

• Requirements Definition Process

• Summary



Basics of Requirements Engineering (1/2)

requirements definition

specification & design & coding &

testing

acceptance testing

requirements management



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]



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




User/Customer Requirements

Document

Specification DesignRequirements

Definition

Technical

Specifications




requirements definition process

specification process

business requirementsuser/customer requirements technical requirements

Why? What? How?




• 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 system’s intended user(s) [Abb86].

• Constraints and properties are also called non-functional requirements

or quality requirements.



What are User Requirements? (1/7)

Why are user requirements important?

• If a system doesn’t satisfy users’ requirements, it is useless.

• In the worst case, the system is not taken into use at all.

• The most successful systems exceed user’s expectations.




• User requirements tell WHAT the system shall do from user’s point of view.

• We are interested in only those functions and properties visible to the users.

• The system is seen as a black box.

user group A user group B




• Functional requirement – A requirement that specifies a

function or service that a system must be capable of

performing from user’s point of view.

• Non-functional requirement – A requirement that describes

the property of the system including performance, reliability

and usability.




Requirement Analysis: Good user requirement?

The system shall be ready by the end of 2002.

Project requirement

The system shall print a component order on paper.

Poor user requirement. Compare the next requirement.

The user shall be able to print a component order on paper.

Relatively good user requirement. The user is doing something

The user shall be able to send a component order to the factory by email or by fax.

Poor user requirement, because two requirements in one sentence.




Requirement Analysis: Good user requirement?

The system shall be user friendly.

Poor user requirement: Too general, not possible

The component orders shall be stored into the database.

Technical requirement.

The user shall be able to open an existing component order in 3 seconds.

Good user requirement.




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.




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.



User Requirements Document (1/18)

• is official statements of user requirements

• says what the system should do without specifying how.




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




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.




Contents: Overview of the system

Example of Use Case Diagram*: Handling Emergency Alarm Call

passenger service center operator

serviceman

* Kone Research Center has given a permission to present this use case diagram as an example.

Making Emergency Alarm Call

Dispatching Job

Reporting

Konect System

Helping Passenger out of Elevator




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 user’s point of view not from the

system’s 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 spider’s net)?



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




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.




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”




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.





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.





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.




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 user’s point of view?

• Does the use case describe the functions from the users’ point of view?

• Is the use case described using user’s language not computer slang?

• Does the use case contain no design and implementation information?




Characteristics

Correctness Every requirement contributes to a real need.

Unambiguity Every requirement has only one possible interpretation.

Understandability Readers can easily comprehend the meaning of all requirements with a minimum of explanation.

Verifiable Every requirement can be tested.




Characteristics

Consistency No subset of individual requirement conflict.

Completeness Everything that the system is supposed to do is included in the requirements document.

Traceability Every requirement has a unique number.

Modifiability A document’s structure and style are such that any changes are made easily, completely, and consistently.



User Requirements Document (15/18) Purpose

• to describe what a system does from the user’s 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




Stakeholders

User Requirements

Document

users

customers

marketing and sales personnel

designers

testers

user manual writersproject manager




Objectives

Objective ofUser Requirements Documents

Quality Aspect

To be an agreement between the customers andsuppliers on what the system is to do

Product Quality

To provide the basis for software specification anddesign.

Product Quality

To support verification and validation of the system Product Quality

To avoid later redesign, recoding and retesting Project Quality

To support a preliminary effort estimation Project Quality




Objectives

Quality of Requirements Engineering Processes

Quality of Software Product

Quality of Software Project

Quality of Requirements Document



Requirements Definition Process (1/14)

requirements definition

specification & design & coding &

testing

acceptance testing

requirements management




requirements definition process

business requirementsuser requirements

document

requirements elicitation

requirements analysis

requirements representation

requirements validation




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”.




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.




Requirements elicitation practices:

• Identify and consult all stakeholders.

• Record requirements sources.

• Record requirements rationale.

• Prototype poorly understood requirements.

• Define users’ processes.




Analysis is the process of establishing an agreed set of requirements and discovering

• missing requirements

• requirements conflicts

• ambiguous requirements

• overlapping requirements

• unrealistic requirements.




Realities of requirements analysis

• Conflicting requirements require negotiations.

• Proper analysis requires hard thinking, time and effort.




Requirements analysis practices

• Use checklists for requirements analysis.

• Plan conflict resolution.

• Prioritise requirements.

• Assess requirements risks.




Representation is the process of describing individual requirements in a

• concise,

• understandable, and

• unambiguous way.




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.




Requirements representation practices

• Use standard templates for describing requirements.

• Use simple and consistent language.

• Use diagrams.

• Specify requirements quantitatively.




Validation is the process of checking the requirements for

• omissions,

• conflicts, and

• ambiguities and

• for ensuring that the requirements follow quality

standards.




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.




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.



Summary (1/2)

User requirements

definitionUser requirements management

Design, coding and system testing

Acceptance testing

Requirements Engineering

Useful and Successful Products



Summary (2/2)

• There is huge potential for improvement in RE.

• RE is a big challenge and an opportunity for organisations

and individuals.



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.



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.