Post on 27-Dec-2015
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
Requirements Engineering TechniquesRequirements Engineering Techniques
People
Documents
Languages – Notations
Technologies – Tools
Management
Culture
Standardization
Legislation
Rules
What
Why
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
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.
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
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
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
Requirements ElicitationRequirements Elicitation
Customer
FinancialInstitution
RetailInstitution
Perform Card Transaction
Process CustomerBill
Manage Account
Credit Card System
Manage Account
Use Case ExamplesUse Case Examples
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
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
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
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
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:
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
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
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”
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
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
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
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
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
Open DiscussionOpen Discussion
Beginning of software process
End of software process
Requirements Engineering ?
Software Engineering
When When Requirements Engineering ?
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