1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course...

23
1 Introduction to Requirements Introduction to Requirements Engineering Engineering COMP SCI: Software Engineering Group COMP SCI: Software Engineering Group Project Course Project Course School of Computer Science School of Computer Science The University of Adelaide The University of Adelaide For For Part 2: Requirements Engineering Techniques

Transcript of 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course...

Page 1: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

1

Introduction to Requirements EngineeringIntroduction to Requirements Engineering

COMP SCI: Software Engineering Group Project COMP SCI: Software Engineering Group Project

CourseCourse

School of Computer ScienceSchool of Computer Science

The University of AdelaideThe University of Adelaide

ForFor

Part 2: Requirements Engineering Techniques

Page 2: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements Engineering TechniquesRequirements Engineering Techniques

People

Documents

Languages – Notations

Technologies – Tools

Management

Culture

Standardization

Legislation

Rules

What

Why

Page 3: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirementselicitation

Requirementsanalysis andnegotiation

Requirementsdocumentation

Requirementsvalidation

Requirementsdocument

User needsdomain

information,existing system

information,regulations,

standards, etc.

AgreedrequirementsSystem

specification

Requirements Engineering ProcessRequirements Engineering Process

Major Phases in the Process

Requirements Management

Requirements Engineering Techniques

Page 4: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements Engineering Techniques Requirements Engineering Techniques

A lot of techniques can be used in the requirements elicitation A lot of techniques can be used in the requirements elicitation process:process:

• Interviews - the most commonly used technique. Interviews - the most commonly used technique. • Focus groupFocus group• Ethnography - adopted from sociology and includes the Ethnography - adopted from sociology and includes the

observation of users. observation of users. • Contextual query. It is a knowledge acquisition approach. Contextual query. It is a knowledge acquisition approach. • Use cases (Scenarios) Use cases (Scenarios) • Goal-based techniques. Goal-based techniques. • Quality Function Deployment (QFD)Quality Function Deployment (QFD)• PrototypePrototype

Requirements ElicitationRequirements Elicitation

These techniques can only be used in the later stages of requirements

elicitation.

Page 5: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements Elicitation TechniquesRequirements Elicitation Techniques

Definition:Definition:

A technique for eliciting detailed information from stakeholders A technique for eliciting detailed information from stakeholders

Type of interview:Type of interview:

• Unstructured interviewUnstructured interview

Ask more general question or open-end questionsAsk more general question or open-end questions

• Structured interviewStructured interview

Ask more specific question based on the analysis of the results from the Ask more specific question based on the analysis of the results from the

unstructured interview – close end questionsunstructured interview – close end questions

• Group interview Group interview

Technique 1:Technique 1: Interview - Basic Interview - Basic

Page 6: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements ElicitationRequirements Elicitation

Consists of four phases: Consists of four phases: • Identifying candidates Identifying candidates • PreparationPreparation

Arranging the interview Arranging the interview Schedule the interview in advance Schedule the interview in advance Create a set of goals Create a set of goals Set the length of the interview Set the length of the interview Request or give the interviewee the necessary materials Request or give the interviewee the necessary materials Confirm the interview 1 - 2 days in advance Confirm the interview 1 - 2 days in advance

Preparing the questions Preparing the questions Context-free Product Questions (open, close)Context-free Product Questions (open, close) Context-specific Product Questions (open, close)Context-specific Product Questions (open, close)

• Conducting the interview Conducting the interview • Follow-up Follow-up

Interview processInterview process

Page 7: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements ElicitationRequirements Elicitation

A use case is a unit of functionality expressed as a transaction among A use case is a unit of functionality expressed as a transaction among

actors and the subject. actors and the subject.

Use case is one of the useful technique for requirement elicitation (later Use case is one of the useful technique for requirement elicitation (later

stage), analysis, documentation, verification and validationstage), analysis, documentation, verification and validation

A use case can be defined in various level of detail (very controversial A use case can be defined in various level of detail (very controversial

in practice.)in practice.)

A use case shall be defined according to specific template to ensure the A use case shall be defined according to specific template to ensure the

completeness, precise, verifiable, traceable of the requirements completeness, precise, verifiable, traceable of the requirements

Technique 2:Technique 2: Use case

Page 8: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements ElicitationRequirements Elicitation

Customer

FinancialInstitution

RetailInstitution

Perform Card Transaction

Process CustomerBill

Manage Account

Credit Card System

Manage Account

Use Case ExamplesUse Case Examples

Page 9: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements ElicitationRequirements Elicitation

Customer

Checking account

Saving account

Investment account

A Use Case Example - A Use Case Example - Decomposition of the Manage Account Use Case

Page 10: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements ElicitationRequirements Elicitation

Customer

Manage checking account

Manage saving account

Manage investment account

A Use Case Example - A Use Case Example - Decomposition of the Manage Account Use Case

Page 11: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements ElicitationRequirements Elicitation

A scenario is a sequence of actions that illustrates behavior. A scenario is a sequence of actions that illustrates behavior.

• can be used to illustrate an interaction or the execution of a use can be used to illustrate an interaction or the execution of a use

case instance.case instance.

Scenario

A use case

Scenario 1

Scenario n

……

Includes

Includes

Includes

Page 12: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements ElicitationRequirements Elicitation

An Example of A Scenario

Use case: Users zoom in or out on the large map area

Basic Flow

1. User Starts a new instance of a Map and the system displays the map.

2. The user presses zoom in button.

3. The content in the large map zooms in 20% with fixed center.

Alternatives1 The user press zoom out button.2 The content in the large map zooms out 20% with fixed center 3. Map reached maximum of 140% for zoom in 4. Map reached minimum of 60% for zoom out

Page 13: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements ElicitationRequirements Elicitation

A use case template

Use Case ID:Use Case ID: Normal Flow:Normal Flow:

Use Case Name:Use Case Name: Alternative Flows:Alternative Flows:

Created By:Created By: Exceptions:Exceptions:

Date Created:Date Created: Includes:Includes:

Last Updated By:Last Updated By: Priority:Priority:

Date Last Updated:Date Last Updated: Frequency of Use:Frequency of Use:

Actors:Actors: Business Rules:Business Rules:

Description:Description: Special Requirements:Special Requirements:

Trigger:Trigger: Assumptions:Assumptions:

Preconditions:Preconditions: Notes and Issues:Notes and Issues:

Postconditions:Postconditions:

Page 14: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements ElicitationRequirements Elicitation

Focus Groups provide another approach for engineers-user interaction.

In this approach, a group of users is brought together with engineers to discuss their work in a free-form discussion atmosphere.

Steps: a. Planning (what is the focus of the meeting) b. Recruitment.

Compatibility , Group Size and Number, Selection, Making Contact to the participants

c. Moderation Setting up the session , Preparing and

planning questions, recording the data Moderator or facilitator play essential role

d. Analyzing and reporting

Technique 3:Technique 3: - Focus groups Facilitator

Page 15: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements ElicitationRequirements Elicitation

A social scientists spends a considerable time observing and analysing how people actually work.

• People do not have to explain or articulate their work.

• Social and organisational factors of importance may be observed.

• Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models.

Requirements that are derived from the way that people actually work

Requirements that are derived from cooperation and awareness of other people’s activities.

Technique 4:Technique 4: - Ethnography

Page 16: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements Analysis and NegotiationRequirements Analysis and Negotiation

Unified Modelling Language (UML) – A tool for OOADUnified Modelling Language (UML) – A tool for OOAD• A collection of techniques for modeling requirements, software or systems. A collection of techniques for modeling requirements, software or systems.

Structured Analysis and Structured Design (SASD)Structured Analysis and Structured Design (SASD)• Uses a set of different techniques such as Uses a set of different techniques such as

Functional decomposition technique, Functional decomposition technique, Data-flow diagram and Data-flow diagram and Data dictionary. Data dictionary.

Goal-based techniquesGoal-based techniques Specification and Description Language (SDL). Specification and Description Language (SDL).

• SDL is a relatively mature requirements description and definition languageSDL is a relatively mature requirements description and definition language Petri Nets. Petri Nets.

• Good at modeling state transition and Good at modeling state transition and control flowcontrol flow in an a in an asynchronous systemsynchronous system where there are a lot of parallel and asynchronous events where there are a lot of parallel and asynchronous events

WinWin negotiation technique [WinWin negotiation technique [Boehm, 1994 Boehm, 1994 ]]

Techniques

You have to stay in “what stage”

Page 17: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements Analysis and Requirements Analysis and Negotiation TechniquesNegotiation Techniques

Informal language: Informal language: • Natural language is the most typical and widely used informal modeling Natural language is the most typical and widely used informal modeling

technique. technique. It has an intuitive syntax and semantics, and can be easily understood and used. It has an intuitive syntax and semantics, and can be easily understood and used. Easily cause ambiguity and inconsistency of requirements.Easily cause ambiguity and inconsistency of requirements.

Semi-formal language: Semi-formal language: • Such a language has a formal syntax but informal semantics. Such a language has a formal syntax but informal semantics.

e.g. Conceptual Modeling Language (CML) and UMLe.g. Conceptual Modeling Language (CML) and UML Formal language: Formal language:

• Has a well-defined formal syntax and semantics. Has a well-defined formal syntax and semantics. • Built on sound mathematical theory, such as set, logic or algebra theory, or Built on sound mathematical theory, such as set, logic or algebra theory, or

a mixture of them. a mixture of them. • e.g. SDL and Petri Nets e.g. SDL and Petri Nets • Advantages: it enables automatic analysis and verification of requirements. Advantages: it enables automatic analysis and verification of requirements. • Problems: hard to be used in practice (learning curve, time of usage)Problems: hard to be used in practice (learning curve, time of usage)

Notations Used in the Analysis Techniques

Even if the system is documented in a formal notation, an informal document Even if the system is documented in a formal notation, an informal document is usually also required to improve understandability of the SRSis usually also required to improve understandability of the SRS

Page 18: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements Verification and ValidationRequirements Verification and Validation

The techniques used most often for this process are:

• Formal requirements inspection. Inspection is used for

identification of incompleteness, inconsistency,

ambiguity and conflict in the requirements

specification [Fagan, 1999].

• Requirements testing. This technique is used to

examine the implementability and understandability of

the requirements through writing test cases for

requirements [Kotonya, 1998].

• Requirements checklist. This technique is used to

examine a list of common concerns in requirements

specifications [Kotonya, 1998]. Automated VerificationVerification

Page 19: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements ManagementRequirements Management

Requirements management • Is the process of identifying, organizing, documenting and tracking

changing requirements in a project as well as the impact of these changes.

• It is an ongoing task throughout the whole RE process and might span the whole software lifecycle.

Most often used techniques:Most often used techniques:• Traceability management (traceability matrix)Traceability management (traceability matrix)• Reuse managementReuse management• Change control and management Change control and management

Tool support is essential. Tool support is essential. • Examples of toolsExamples of tools

• Any documentation system, Word, Any documentation system, Word, LaTeXLaTeX • Commercial good tools: DOOR, Rational RequisitePro Commercial good tools: DOOR, Rational RequisitePro

• Useful websiteUseful website• http://www.paper-review.com/tools/rms/read.php http://www.paper-review.com/tools/rms/read.php

From INCOSE: From INCOSE: International Council on Systems EngineeringInternational Council on Systems Engineering

Page 20: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Requirements EngineeringRequirements Engineering

Requirements Interaction Management• Requirements can interact and/or conflict with each other, successfully Requirements can interact and/or conflict with each other, successfully

resolve the problem is challenging resolve the problem is challenging Requirement ReuseRequirement Reuse

• Software product lines and software product family Software product lines and software product family • A software product line (SPL) is a set of software-intensive systems

that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

• A software product family is a collection of products that share common requirements, features, architectural concepts, and code, typically in the form of software components

COTS (Commercial-Off-The-Shelf ) EngineeringCOTS (Commercial-Off-The-Shelf ) Engineering Requirements for safety-critical systemRequirements for safety-critical system

Other Interesting Topics

Page 21: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

In project:

• What techniques to use in order to get requirements

• How to analyze and document your requirements

• Principles

Relevance to Your ProjectRelevance to Your Project

Page 22: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Open DiscussionOpen Discussion

Beginning of software process

End of software process

Requirements Engineering ?

Software Engineering

When When Requirements Engineering ?

Page 23: 1 Introduction to Requirements Engineering COMP SCI: Software Engineering Group Project Course School of Computer Science The University of Adelaide For.

Various techniques needed in the RE processVarious techniques needed in the RE process Requirements elicitation and analysis is iterative involving Requirements elicitation and analysis is iterative involving

domain understanding, requirements collection, domain understanding, requirements collection, classification, structuring, prioritisation and validationclassification, structuring, prioritisation and validation

Social and organisation factors influence system Social and organisation factors influence system requirements.requirements.

Requirements validation is concerned with checks for Requirements validation is concerned with checks for validity, consistency, completeness, realism and verifiability.validity, consistency, completeness, realism and verifiability.

Business changes inevitably lead to changing requirements.Business changes inevitably lead to changing requirements. Requirements management includes planning and change Requirements management includes planning and change

management.management.

Key pointsKey points