Upload
thai-mozhi-tamil
View
49
Download
7
Embed Size (px)
DESCRIPTION
Chapter 3
Citation preview
SCSJ 2253: REQUIREMENTS ENGINEERING &
SOFTWARE MODELLING
Semester 2, 2014/205 Noraini Ibrahim
Chapter 1: IntroducEon & FoundaEon
Recap - DeniEon of Requirement
(1) A condition or capability needed by a problem or achieve an objective.
(2) A condition or capability that must be met or possessed by a system or system component, to satisfy a contract, standard, specification, or other formally imposed documents.
(3) A documented representation of a condition or capability as in (1) or (2).
IEEE Std. 610.12-1990
Recap Requirements Engineering
A systematic and disciplined approach to the specification and management of requirements
Recap Stakeholder
a person, group of people or an organisation who has directly or indirectly influence on the requirements
of the regarded system
Functions Requirements Are not implemented, but limit the solution space
Big influence on
system architecture
Team
Norms
Standards
R e q u i r e m e n t concerning a result of behaviour that shall be provided by a function of the system.
Requirement that pertains to a quality concern that is not covered by a functional requirement. Requirement that limits the
solution space beyond what is necessary for meeting the given functional and quality requirements.
Non-functional Requirements
Constraints (organisational, technical)
Development Process Budget Deadlines
Legislation
Guidelines
Operations
Quality Requirements
Details of Functionality (Security, Accuracy)
Reliability Usability Efficiency Maintainability Portability
Functional Requirements
Functionality (Use Cases) Business Rules Data State Error handling Interfaces
Recap Types of Requirements
Chapter 2: System & Context Boundaries
Grey zone of the system boundary not relevant
System boundary
Context Grey zone of the context
Scope within the system boundary
System
Recap Context & System
Recap System boundary & interfaces
Business process
Document (ex. Law)
System Hardware system
Software system
context System
Event System boundary
Chapter 3: Requirements ElicitaEon
Outline
1. Deni
DEFINITION OF ELICITATION
What is Requirement elicitaEon?
The art of determining the needs of stakeholders
The process of discovering the requirements
for a system by communicaEon with stakeholders and through the observaEon of
them in their domain
DeniEon of Requirements elicitaEon
The process of seeking, capturing and consolida0ng requirements from available requirements sources. May include the re-construc7on or crea7on of requirements. (Pohl and Rupp, 2011)
Synonym: Requirements discovery
REQUIREMENTS SOURCES
Sources of requirements
Stakeholders
Documents
Systems in opera
#1 Sources of requirements
People of organiza
#2 Sources of requirements
Contain important informa
#3 Sources of requirements
Examples: Exis
Roles for collaboraEon Stakeholder obligaEons
Introduce the requirements engineer to the applica
Roles for collaboraEon Requirements engineer obligaEons
Speaks the language of the stakeholder
Becomes thoroughly familiar with the applica
ELICITATION TECHNIQUES Working with the stakeholders
The Kano Model : Stakeholders saEsfacEon
Satisfaction very satisfied
Performance factors (Satisfiers)
Excitement factors (Delighters)
complete Coverage insufficient Basic factors
(Dissatisfiers)
Change in time
unsatisfied
Pohl & Rupp (pg.23)
The Kano Model : 1) Basic Factors
Satisfaction very satisfied
complete Coverage
insufficient Basic factors (Dissatisfiers) - Must be fulfilled by the system - Stakeholders take it for granted - Stakeholder nearly not aware anymore - never communicated (goes without saying) unsatisfied
Performance factors (Satisfiers)
Excitement factors (Delighters)
The Kano Model : 1) Basic Factors
Satisfaction very satisfied
complete Coverage
insufficient Basic factors (Dissatisfiers)
unsatisfied
Performance factors (Satisfiers)
Excitement factors (Delighters)
ElicitaEon techniques : ObservaEon & Document-centric
The Kano Model : 2) Performance factors
Satisfaction very satisfied
Performance factors (Satisfiers) - in focus of stakeholders - conscious and intended - explicitly communicated
Excitement factors (Delighters)
complete Coverage
insufficient Basic factors (Dissatisfiers)
unsatisfied
The Kano Model : 2) Performance factors
Satisfaction very satisfied
Performance factors (Satisfiers)
Excitement factors (Delighters)
complete Coverage
insufficient Basic factors (Dissatisfiers)
unsatisfied
ElicitaEon technique : Survey
The Kano Model : 3) Excitement factors
Satisfaction very satisfied
Performance factors (Satisfiers)
Excitement factors (Delighters) - unexpected for stakeholders - not yet conscious - never communicated
complete Coverage
insufficient Basic factors (Dissatisfiers)
unsatisfied
The Kano Model : 3) Excitement factors
Satisfaction very satisfied
Performance factors (Satisfiers)
Excitement factors (Delighters)
complete Coverage
insufficient Basic factors (Dissatisfiers)
unsatisfied
ElicitaEon technique : CreaEvity-based
Human influences Organizational influences
Domain knowledge Communication skills Homogeneity of interests Group dynamics Implicit knowledge Cultural differences
Processes and structures System landscape Given Budget Availability of
Stakeholders Resources
Function-content influences Risk
factors Damage to humans & nature Contract penalty System criticality Damage to reputation
Domain (complexity) System size Norms and Standards
Required level of detail
Inuencing factors on elicitaEon technique choices
Requirements elicitaEon techniques
Numerous techniques can be employed Many types of informa
Requirements elicitaEon techniques
Interviews Workshops/ Brainstorm Focus groups
Observa
Requirements elicitaEon techniques
Interviews Ques
Survey technique - Interview
The stakeholders can be ques
Survey technique - QuesEonnaire
Form with mul
Requirements elicitaEon techniques
Interviews Ques
Group-based & CreaEve technique Workshop/Brainstorming
Group with moderator, 5 to 10 people Par
Group-based & CreaEve technique Focus group
A representa
Requirements elicitaEon techniques
Interviews Ques
Group-based & ObservaEon technique Field observaEon
Observa
Requirements elicitaEon techniques
Interviews Ques
Document-centric technique System interface analysis
How other systems connects to Reveals data exchange and services between systems
Strengths Independent of the stakeholders The exis
Document-centric technique User interface analysis
Synonym to system archeology Explora
Document-centric technique Document analysis
Examining any exis
Requirements elicitaEon techniques
Interviews Ques
Other support technique Prototyping
An ini
Types of prototyping 1. Throw-away prototyping
intended to help elicit and develop the system requirements. The requirements which should be prototyped are those which cause
most dicul
Technique Basic factor Performance factor
Excitement factor
Interviews + ++ + Ques
Summary
1. Deni
Problem solving
Based on the previous Vision and Scope document for Cafeteria Ordering System: 1. Iden
References
K. Wiegers and J. Beawy, Sohware Requirements, 3rd Edi