Lecture 2: Basics of RE: Steve Easterbrook University of Toronto

University of Toronto Department of Computer Science University of Toronto Department of Computer Science
Lecture 2: Basics of RE
Last Week:
INTRO
Syllabus
Requirements Engineering: Course Goals
Literature on RE
Requirements Elicitation This Week:

Basics of RE
(Basics of RE, Elicitation I, Elicitation II) RE in the lifecycle
Types of problem domain
Processes, methods & techniques
A little systems theory
Steve Easterbrook
University of Toronto
Next Week:
Elicitation (I)
Traditional approaches
Interviews & Questionnaires
Prototyping
2001, Steve Easterbrook 1 2000-2003, Steve Easterbrook
2
Importance of RE: background Solutions??

Problems No Silver Bullet (Brooks)
Increased reliance on software Software is complex for its size
E.g. cars, dishwashers, cell phones, web services,
Software is invisible and abstract
Software now the biggest cost element for mission critical systems
No fabrication step; hence software is modifiable(!)
E.g. Boeing 777
Wastage on failed projects But: Early modeling and analysis is important
E.g. 1997 GAO report: $145 billion over 6 years on software that was never
delivered Defects are cheaper to remove the earlier they are found (Boehm)
High consequences of failure Requirements defects are more likely to be safety-related (Lutz)
E.g. Ariane 5: $500 million payload E.g. Voyager and Galileo
E.g. Intel Pentium bug: $475 million
Early modeling and analysis is not enough
Key factors: Need to communicate requirements to everyone
Certification costs Need to seek agreement from all stakeholders
E.g. Boeing 777: >40% of software budget spent on testing
Need to understand the context for the system
Re-work from defect removal
Need to understand the context for the development process
E.g. Motorola: 60-80% of software budget (was) spent on re-work
Need to keep up to date as the requirements evolve
Changing Requirements
E.g. California DMV system
2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook Refs: Brooks 1987, Boehm 1981, Lutz 1993
3 4
Basic Definitions The essential requirements process

What is a Requirement? Understand the problem
Real World
Something that someone needs to solve a problem or achieve an objective: elicitation, requirements
acquisition, etc.
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 Formally describe the
imposed document. The set of all requirements forms the basis for subsequent
development of the system or system component. [IEEE Std] problem
specification, modelling, etc.
What is Requirements Engineering?
Validation

Correspondence
Problem
...Requirements Engineering is the branch of systems engineering concerned
Attain agreement on the
Verification
Statement
Correctness
with real-world goals for, services provided by, and constraints on software nature of the problem
systems. Requirements Engineering is also concerned with the relationship of validation, conflict resolution,
these factors to precise specifications of system behaviour and to their negotiation
evolution over time and across system families... [Zave94] requirements management -
maintain the agreement!
... RE is concerned with identifying the purpose of a software system, and Implementation
the contexts in which it will be used. Hence, RE acts as the bridge between Statement
the real world needs of users, customers, and other constituencies affected
by a software system, and the capabilities and opportunities afforded by
software-intensive technologies. [RE01 CfP]
System
2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook Source: Adapted from Loucopoulos & Karakostas, 1995, p20 and Blum, 1992
5 6
Types of RE project Software Types

Source of Requirements: Information Systems
Customer-driven software to support organizational work
involve a specific customer who needs a system to solve a specific problem includes files/databases as well as applications
Market-driven
involve a developer who needs to develop a system to be sold in the market More than 70% of all software falls in this category, written in languages
Hybrid such as COBOL, RPG and 4GLs.
developed for a specific customer, but want to market the software eventually Examples: Payroll, Employee Records, Accounts payable/receivable, Customer
records, Transaction records
Nature of the Product Embedded Systems
One-off (bespoke) vs. Packaged (shrink wrapped)
Single system vs. Product Family (product line) software that drives some sort of a hardware process
New system vs. Upgrade to existing system Examples: industrial plant, an elevator system, or a credit card machine.
These questions affect the role of Requirements: Generic Services

as a statement of the problem to be solved systems that provide some form of generic service
as a contract between customer and developers Examples: many internet applications, e.g. search engines, stock quote services,
credit card processing, etc.
for communication between designer, customer and end-users
Such systems will be developed using a variety of languages and middleware,
to support system evolution
including Java, C++, CORBA, HTML/XML etc.
to support design validation
2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

7 8
What vs. How What are requirements about?

Traditionally, Requirements Application Domain Machine Domain
should specify what without
specifying how System
But this is not always easy to distinguish: Require- What
What does a car do? ments
What does a web browser do?
What does an operating system do? Sub- Some distinctions:
How Design
The how at one level of abstraction forms system Domain Properties are things in the application domain that are true whether or not we
the what for the next level Require- ever build the proposed system
What Requirements are things in the application domain that we wish to be made true by
Jacksons work provides a ments
delivering the proposed system
A specification is a description of the behaviours the program must have in order to
clearer distinction Unit
How Design meet the requirements
What refers to a systems purpose Two verification criteria:
it is external to the system Require-
What The Program running on a particular Computer satisfies the Specification
it is a property of the application domain ments The Specification, in the context of the given Domain properties, satisfies the
How refers to a systems structure and Requirements
behavior How Design
Two validation criteria:
it is internal to the system Did we discover (and understand) all the important Requirements?
it is a property of the machine domain
Did we discover (and understand) all the relevant Domain properties?

Source: Adapted from Jackson, 1995, p207 9 Source: Adapted from Jackson, 1995, p170-171 10
Validation Example Another Example

Requirement R: Requirement R:
Reverse thrust shall only be enabled when the aircraft is moving on the The database shall only be accessible by authorized personnel
runway
Domain Properties D:
Domain Properties D: Authorized personnel have passwords
Wheel pulses on if and only if wheels turning Passwords are never shared with non-authorized personnel
Wheels turning if and only if moving on runway
Specification S:
Specification S: Access to the database shall only be granted after the user types an
Reverse thrust enabled if and only if wheel pulses on authorized password
S + D imply R S + D imply R
But what if the domain model is wrong? But what if the domain assumptions are wrong?

Source: Adapted from Jackson, 1995, p172 11 Source: Adapted from Jackson, 1995, p172 12
RE is all about Description Examples

A designation Designations:
singles out a phenomena of interest Parent(x,p) denotes that p is the genetic parent of x
tells you how to recognize it and gives it a name Female(x) denotes that x is biologically female
A designation is always informal,
it maps from the fuzzy phenomena to formal language
A definition Definitions:
gives a formal definition of a term that may be used in other descriptions mother(x,m) Parent(x,m) and Female(m)
Note: definitions can be more or less useful, but never right or wrong.
sister(x,y) Female(x) and mother(x,m) and mother(y,m) and
A refutable description father(x,f) and father (y,f)
states some property of a domain that could in principle be refuted
Might not be practical to refute it, but refutation should be conceivable
Refutable Description:
For all m and x, Parent(x, p) implies not(Parent(m, p))
Refutability depends on an appeal to the designated phenomena of the
domain being described A rough sketch
A rough sketch Everyones related somehow
is a tentative description that is being developed

Source: Adapted from Jackson, 1995, p58-59 13 Source: Adapted from Jackson, 1995, p58-59 14
Requirements are optative Phenomena

Traditionally, requirements contain the word shall A little Philosophy:
(and contractually, will means its optional!) Phenomenology
The distinction in English is subtle: the study of the things that appear to exist when you observe the world
I shall drown. No one will save me Ontology
I will drown. No one shall save me the study of what really does exist (independently from any observer)
Epistemology
Mood (of a verb): the study of what people are capable of knowing (or what they believe)
Indicative: asserts a fact (you sing) Weltanschauung
Interrogative: asks a question (are you singing) a world view that defines the set of phenomena that an observer is willing (likely)
Imperative: conveys a command (Sing!) to observe (viewpoint)
Subjunctive: states a possibility (I might sing) Each method has its own Weltanschauung
Optative: expresses a wish (may you sing)
Examples:
For requirements engineering: OO sees the world as objects with internal state that respond to stimuli
SA sees the world as processes that transform data
use the indicative mood for domain properties Natural language also defines a viewpoint
use the optative mood for requirements Each method restricts the set of phenomena you can describe
Never mix moods in the same description. ...and therefore what you can model
Anyway, mood changes as development progresses! :-) Choose a method that emphasizes the appropriate kinds of phenomena

Source: Adapted from Jackson, 1995, p125-127 15 Source: Adapted from Jackson, 1995, p143, and Blum 1996, chapter 2 16
What is a system?
can you RAIN, RAIN Definition of a System:
stop the GO AWAY! Some part of reality that can be observed to interact with its environment
RAIN? Separated from its environment by a boundary
A system receives inputs from the environment & send outputs to the environment
A system usually have subsystems
Systems that endure have a control mechanism
Systems have interesting emergent properties
Examples:
cars, cities, houseplants, rocks, spacecraft, buildings, weather,...
operating systems, DBMS, the internet, an organization
Non-examples (there arent many!):
numbers, truth values, letters.
its what is it you A closed system doesnt interact with its environment (there arent many!)
snowing! really want?
Systems might have no physical existence
Only manifestations are symbolic/analogical representations of the system
Such systems are social constructs: they exist because we agree on ways to
observe them

17 Source: Adapted from Wieringa, 1996, p10 18
Hard vs. Soft Systems Lecture 3: Requirements Elicitation I

Hard Systems: Soft Systems: Last Week:
Approaches to RE
The system is The system Processes, methods & techniques
precise, is hard to define precisely Importance of Description
well-defined is an abstract idea Role of modeling
quantifiable depends on your perspective
No disagreement about: Not easy to get agreement

Where the boundary is The system doesnt really exist
What the interfaces are Calling something a system helps us This Week:
The internal structure to understand it Elicitation (I)
Control mechanisms Identifying the boundaries, Traditional approaches
The purpose (??) interfaces, controls, helps us to Interviews & Questionnaires
predict behaviour Scenarios, Goals and Use-Cases
Examples The system is a theory of how
? some part of the world operates
Examples:
All human activity systems Next Week:
(what else?) Elicitation (II)
Cognitive approaches
Contextual approaches
Ethnography

19 20
Requirements Elicitation The four worlds

Starting point
Some notion that there is a problem that needs solving
e.g. dissatisfaction with the current state of affairs How info about Subject How the machine
e.g. a new business opportunity the application domain represents info about
e.g. a potential saving of cost, time, resource usage, etc. World
is used by the system the application domain
A Requirements Engineer is an agent of change
The requirements engineer must:

identify the problem/opportunity
Which problem needs to be solved? (identify problem Boundaries) W6H Usage User System
Where is the problem? (understand the Context/Problem Domain)
The Interfaces
Whose problem is it? (identify Stakeholders) World World
Why does it need solving? (identify the stakeholders Goals) journalists
How might a software system help? (collect some Scenarios) technique:
When does it need solving? (identify Development Constraints) What?
What might prevent us solving it? (identify Feasibility and Risk) Where?
elicit enough knowledge Who? Design
...sufficient to analyze requirements for validity, consistency, Justification of Development
completeness, etc. Why? development goals World Decisions
i.e. become an expert in the problem domain When?
although ignorance is important too [Berry] How?
(Which?)

21 Source: Adapted from Loucopoulos & Karakostas, 1995, p73 22
Difficulties of Elicitation Importance of links with customer(s)

Thin spread of domain knowledge Successful projects tend to have more links with
The knowledge might be distributed across many sources
It is rarely available in an explicit form (I.e. not written down)
customer(s)
There will be conflicts between knowledge from different sources From Keil & Carmel, CACM May 1995
People have conflicting goals 80
People have different understandings of the problem packages custom s/w
Links used as a percentage of all

70
Tacit knowledge (The say-do problem)
More Successful Projects
60 Less Successful Projects
People find it hard to describe knowledge they regularly use
possible links
Descriptions may be inaccurate rationalizations of expert behaviour 50
Limited Observability 40
The problem owners might be too busy solving it using the existing system 30
Presence of an observer may change the problem 20
E.g. the Probe Effect and the Hawthorne Effect
10
Bias 0
People may not be free to tell you what you need to know
major
financial
s/w div
of h/w co.
manuf. of
medium
CASE tool
manuf.
major
prog. env.
s/w devel.
s/w devel.
company
company
hotel chain
elec. goods
beverage co.
UNIX tool
office
developer
auto. devel
airline
a telecoms
tool devel.
large comp.
software
supplier
developer
P1 P2 P3 P5 P8 P9 P10 P11 C1 C2 C3 C4 C5 C6
Political climate & organisational factors matter
People may not want to tell you what you need to know Company
The outcome will affect them, so they may try to influence you (hidden agendas)

23 Source: Adapted from Keil and Carmel, 1995, p37 24
Elicitation Techniques Questionnaires

Traditional Approaches Contextual (social) Advantages
Introspection approaches Can quickly collect info from large numbers of people
Existing Documents Ethnographic techniques Can be administered remotely
Data Analysis Participant Observation
Interviews Enthnomethodology
Can collect attitudes, beliefs, characteristics
Discourse Analysis
Disadvantages
Open-ended
Structured Conversation Analysis
Surveys / Questionnaires Speech Act Analysis Simplistic (presupposed) categories provide very little context
This
Group elicitation Participatory Design No room for users to convey their real needs
Focus Groups week Sociotechnical Methods
Brainstorming
JAD/RAD workshops
Soft Systems Analysis Watch for:
Prototyping Cognitive approaches Bias in sample selection
Task analysis Bias in self-selecting respondents
Representation-based Next
Protocol analysis Small sample size (lack of statistical significance)
approaches week
Knowledge Acquisition Techniques Leading questions (have you stopped beating your wife?)
Goal-based Card Sorting
Laddering Appropriation (What is this a picture of?)
Scenario-Based
Repertory Grids Ambiguous questions (I.e. not everyone is answering the same question)
Use Cases Proximity Scaling Techniques Questionnaires MUST be prototyped and tested

25 Source: Adapted from Goguen and Linde, 1993, p154. 26
Interviews Group Elicitation Techniques

Types: Types:
Structured - agenda of fairly open questions Joint/Rapid Application Development (JAD/RAD) Workshops
Open-ended - no pre-set agenda Focus Groups
Brainstorming
Advantages
Rich collection of information Advantages
More natural interaction between people than formal interview
Disadvantages Can gauge reaction to stimulus materials (e.g. mock-ups, storyboards, etc)
Large amount of qualitative data can be hard to analyze
Hard to compare different respondents Disadvantages
Interviewing is a difficult skill to master May create unnatural groups (uncomfortable for participants)
Watch for Danger of Groupthink
Unanswerable questions (how do you tie your shoelaces?) May only provide superficial responses to technical questions
Tacit knowledge (and post-hoc rationalizations) Requires a highly trained facilitator
Removal from context Watch for
Interviewers attitude may cause bias (e.g. variable attentiveness)
sample bias
dominance and submission

Source: Adapted from Goguen and Linde, 1993, p154. 27 28
Hard Data Collection Use Cases

Identify Collections of Hard Data What is a use case?
Facts and figures, financial information, Each different way that an actor interacts with a system is a use case
a description of a sequence of actions that a system performs that yields an
Reports used for decision making, observable result of value to a particular actor [Booch]
Survey results, marketing data, All the use cases need to be enumerated (or the requirements will not be
complete)
Sampling A description of a set of possible scenarios, with a common purpose
Sampling used to select representative set from a population Typically written in natural language
Purposive Sampling - choose the parts you think are relevant without worrying No internal description of the system; just the interaction.
about statistical issues
Simple Random Sampling - choose every kth element
Stratified Random Sampling - identify strata and sample each
Combining use cases
Clustered Random Sampling - choose a representative subpopulation and sample it extends/uses
Sample Size is important
balance between cost of data collection/analysis and required significance
Advantages & Disadvantages
detailed characterization of all possible interaction with the system
helps in drawing system boundary, and scoping the requirements
Use cases do not capture domain knowledge!!
Dont confuse use cases with a precise specification!

29 Source: Adapted from Rumbaugh 1997, p123-124 30
Scenarios Goal-based Approaches

Scenarios Approach
Specific sequence of interaction between actor and system Focus on why systems are constructed
Tend to be short (e.g between 3 and 7 steps) Express the why as a set of stakeholder goals
May be: Use goal refinement to arrive at specific requirements
positive (i.e. required behavior) Goal analysis
negative (i.e an undesirable interaction) document, organize and classify goals
May be indicative or optative Goal evolution
refine, elaborate, and operationalize goals
Advantages Goal hierarchies show refinement and obstacle relationships between goals
Very natural: stakeholders tend to use them spontaneously
Short scenarios very good for quickly illustrating specific interactions Advantages
Reasonably intuitive
Disadvantages Explicit declaration of goals provides sound basis for conflict resolution
Lack of structure: need use cases or task models to provide higher level
view Disadvantages
Hard to cope with evolution of goals
Can regress forever up (or down) the goal hierarchy

Source: Adapted from Dardenne, 1993. 31 Source: Adapted from Anton, 1996. 32
Lecture 4: Requirements Elicitation II Knowledge Elicitation Techniques in RE

Last Week: Background
Elicitation (I) Knowledge elicitation is concerned with
Traditional approaches discovering expert knowledge
Interviews & Questionnaires Grew out of Expert Systems work in the Example Techniques
Scenarios, Goals and Use-Cases 80s Eliciting domain knowledge
Originally focussed on deriving experts Card Sorting
rules for Rule-based Systems Laddering
Proximity Scaling Techniques
More recently, focussed on problem
solving methods Eliciting performance knowledge
This Week: Protocol Analysis
Elicitation (II) But KE is hard Using Multiple Experts
Delphi Technique
Cognitive approaches Separation of domain knowledge from
Focus Groups
performance knowledge
Contextual approaches Modeling problems
Repertory Grids
Automated Techniques
Ethnography as an RE technique Brittleness
Machine Learning
Assumption of rationality
Representational Problem
epistemological inadequacy
expressiveness vs. acquirability
Next Week: Expert Bias
Modeling and Analysis (I)
Modeling Goals
Modeling Organisations
Modeling Non-Functional Reqs

33 34
Why is KE so hard? Knowledge Elicitation Techniques

Experts are not used to describing what they do. Protocol Analysis
Three stage model of learning: based on vocalising behaviour
1) cognitive - verbal rehearsal of tasks; Think aloud vs. retrospective protocols
2) associative - reinforcement through repetition, verbal mediation disappears Advantages
3) autonomous - compiled, no conscious awareness of performance. Direct verbalisation of cognitive activities
Procedural and declarative are different mechanisms Embedded in the work context
Declarative knowledge becomes procedural with repeated application - experts lose Good at revealing interaction problems with existing systems
awareness of what they know and cannot introspect reliably Disadvantages
Experts have little or no introspective access to higher order cognitive processes Essentially based on introspection, hence unreliable
No social dimension
Representational Problems
Experts dont have the language to describe their knowledge Proximity Scaling Techniques
No spoken language offers the necessary precision Given some domain objects, derive a set of dimensions for classifying them:
Knowledge Engineer and Expert must work together to create a suitable language step 1: pairwise proximity assessment among domain elements
Different knowledge representations are good for different things step 2: automated analysis to build multi-dimensional space to classify the objects
Epistemological adequacy: does the formalism express expert's knowledge well? Advantages
help to elicit mental models, where complex multivariate data is concerned
Brittleness good for eliciting tacit knowledge
Knowledge is created, not extracted. Disadvantages
Knowledge models are abstractions of reality and hence are unavoidably selective Requires an agreed on set of objects
Brittleness is caused by the simplifying assumptions - instead of adding more Only models classification knowledge (no performance knowledge)
knowledge, a better (more comprehensive) model is needed.

35 Source: Adapted from Hudlicka, 1996. 36
more KE techniques Expert Bias

What is bias? Sources of Bias
Card Sorting Laddering Bias only exists in relation Social pressure
For a given set of domain Uses a set of probes (types of to some reference point response to verbal and non-verbal cues from an interviewer
can there ever be no Group think
objects, written on cards: question) to acquire structure bias? (reflects reality or response to reactions of other experts
Expert sorts the cards into and content of stakeholders truth)
groups... Impression management
knowledge. We cannot perceive reality response to imagined reactions of managers, clients, etc.
...then says what the criterion Interview the expert. directly:
was for sorting, and what the Wishful thinking
Use questions to move up and It is interpreted through a
groups were. filter of mental models response to hopes or possible gains.
down a conceptual hierarchy Misinterpretation
Advantages Advantages
mediated by our senses
Analyst selectively interprets to support what she currently
and neural pathways.
simple, amenable to automation deals with hierarchical believes.
All decision making is based
elicits classification knowledge knowledge, including poly- Misrepresentation
partly on personal value
Problems hierarchies (e.g., goal trees, systems. expert cannot accurately fit a response into the requested
suitable entities need to be is-a taxonomies). response mode
identified with suitable semantic knowledge is represented in Types of bias: anchoring
spread across domain. standardised format contradictory data is ignored once an initial solution is
Motivational bias available
No performance knowledge can elicit structural knowledge the expert makes
suitable for automation. accommodations to please inconsistency
the interviewer or some assumptions made earlier are forgotten
Disadvantages other audience availability
assumes hierarchically arranged Cognitive bias some data are easier to recall than others
knowledge. the expert does not follow underestimation of uncertainty
objective rules or standards tendency to underestimate by a factor of 2 or 3.

37 38
KA from Multiple Experts The Ethnomethodolgists View

Delphi technique
Used where contact between experts is difficult:
Requirements elicitation is a social activity:
Each expert submits their judgement Because it involves people-to-people communication (through discussions,
All judgements are circulated anonymously to all experts observation, etc.)
Each expert then submits a revised judgement Because it involves negotiation in bringing about consensus when there is
Iterate until judgements converge disagreement.
Because it affects and changes human activity systems
Focus Groups
A technique derived from marketing: The domain of application is often a social world
Assemble experts together and discuss the problem Need techniques that uncover the order of the social world
Discussion may be structured (e.g. debate) or unstructured social order might not be immediately obvious or describable
social order cannot be assumed to have an a priori structure
Repertory Grids (based on Kellys Personal Construct Theory) Social order can only be understood through immersion
Used to detect terminological differences social order is constructed by the participants actions
Get the experts to agree a set of entities need to witness the unfolding of social phenomena
Each expert provides attributes and values cannot just collect data using pre-given categories
For each attribute in expert A's grid, find the closest match in expert B's grid. Need to consider
(i.e. are there attributes which have the same discriminatory function?)
How meanings develop and evolve within context
Experts then rate the entities using each other's attributes
The methods people use to make sense of the world around them

39 40
Ethnomethodology Participant Observation

Basis Approach
Social world is ordered Observer spends time with the subjects, joining in, long enough to become a
The social order may not be immediately obvious, nor describable from member of the group (longitudinal studies)
common sense
The social order cannot be assumed to have an a priori structure Advantages
I.e. social order emerges only when an observer immerses herself in it. Contextualized;
Emphasizes the importance of natural setting Reveals details that other methods cannot
Categories Disadvantages
Most conventional approaches assume preexisting categories Extremely time consuming!
This may mislead the observer (appropriation) Resulting rich picture is hard to analyze
Ethnography attempts to use the subjects own categories Cannot say much about the results of proposed changes
Related to postmodern deconstruction: there is no grand narrative
Watch for
Measurement going native!
No scientific objectivity, so use the subjects own measurement theory

Source: Adapted from Goguen and Linde, 1993, p158. 41 42
University of Toronto Department of Computer Science
An RE Methods Classification (after Lyotard)
Modern Post-Modern
societies are based on
local language games and
cannot be unified or neatly
allow for
divided into parts
assume a multiple views Pluralistic
single within society
objective Unitary
reality
Divisive Cooperative
Hard Soft Dual Democratic

an organization a system can based on the Critical seek to involve Network
is a rational serve marxist
seek all viewpoints
system multiple conflict; RE evolutionary
alternatives to in a democratic
objectives must take approaches
existing social style
sides
conditions
2000-2003, Steve Easterbrook
43

Lecture 2: Basics of RE: Steve Easterbrook University of Toronto

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Lecture 2: Basics of RE: Steve Easterbrook University of Toronto

Hochgeladen von

Copyright:

Verfügbare Formate

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Requirements Elicitation This Week:

Importance of RE: background Solutions??

Basic Definitions The essential requirements process

Types of RE project Software Types

These questions affect the role of Requirements: Generic Services

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

What vs. How What are requirements about?

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

Validation Example Another Example

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

RE is all about Description Examples

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

Requirements are optative Phenomena

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

Hard vs. Soft Systems Lecture 3: Requirements Elicitation I

No disagreement about: Not easy to get agreement

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

Requirements Elicitation The four worlds

The requirements engineer must:

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

Difficulties of Elicitation Importance of links with customer(s)

Links used as a percentage of all

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

Elicitation Techniques Questionnaires

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

Interviews Group Elicitation Techniques

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

Hard Data Collection Use Cases

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

Scenarios Goal-based Approaches

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

Lecture 4: Requirements Elicitation II Knowledge Elicitation Techniques in RE

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

Why is KE so hard? Knowledge Elicitation Techniques

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

more KE techniques Expert Bias

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

KA from Multiple Experts The Ethnomethodolgists View

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

Ethnomethodology Participant Observation

2000-2003, Steve Easterbrook 2000-2003, Steve Easterbrook

University of Toronto Department of Computer Science

An RE Methods Classification (after Lyotard)

Hard Soft Dual Democratic

Das könnte Ihnen auch gefallen