CS 560: Software Engineering

Requirements Engineering

Dr. Mohammed Ayoub Alaoui Mhamdi

Bishop's University
Sherbrooke, Qc, Canada
[email protected]
Requirements Engineering
 the first step in finding a solution for a data processing
problem
 the results of requirements engineering is a
requirements specification
 requirements specification
 contract for the customer
 starting point for design

2
Natural language specs’ challenges
“All users have the same control field”

 the same value in the control field?

 the same format of the control field?

 there is one (1) control field for all users?

3
Requirements engineering, main
steps

1. understanding the problem: elicitation

2. describing the problem: specification

3. agreeing upon the nature of the problem: validation

and verification

4. agreeing upon the boundaries of the problem:

negotiation

This is an iterative process

4
Framework for RE process

specification

elicitation doc & mgt validation

negotiation

5
Conceptual modeling
 you model part of reality: the Universe of Discourse
(UoD)

 this model is an explicit conceptual model

 people in the UoD have an implicit conceptual model

of that UoD

 making this implicit model explicit poses problems:

 analysis problems
 negotiation problems
6
Requirements engineering is difficult
Success depends on the degree with which we manage
to properly describe the system desired

Software is not continuous!

7
Beware of subtle mismatches
 a library employee may also be a client

 there is a difference between `a book` and `a copy of a

book`

 status info `present` / `not present` is not sufficient; a

(copy of a) book may be lost, stolen, in repair, ...

8
Humans as information sources
 different backgrounds

 short-term vs long-term memory

 human prejudices

 limited capability for rational thinking

9
Negotiation problems
 existing methods are “Taylorian”

 they may work in a “technical” environment, but

many UoDs contain people as well, and their models
may be irrational, incomplete, inconsistent,
contradictory

 as an analyst, you cannot neglect these aspects; you

participate in shaping the UoD

10
Point to ponder #1

 how do you handle conflicts during requirements

engineering?

11
How we study the world around us
 people have a set of assumptions about a topic they
study (paradigm)
 this set of assumptions concerns:
 how knowledge is gathered
 how the world is organized
 this in turn results in two dimensions:
 subjective-objective (wrt knowledge)
 conflict-order (wrt the world)
 which results in 4 archetypical approaches to
requirements engineering

12
 Four approaches to RE
 functional (objective+order): the analyst is the expert
who empirically seeks the truth
 social-relativism (subjective+order): the analyst is a
`change agent’. RE is a learning process guided by the
analyst
 radical-structuralism (objective+ conflict): there is a
struggle between classes; the analyst chooses for
either party
 neohumanism (subjective+conflict): the analyst is
kind of a social therapist, bringing parties together

13
 Elicitation techniques
 interview  synthesis from existing
 Delphi technique system
 brainstorming session  domain analysis

 task analysis  Business Process Redesign

 scenario analysis (BPR)

 prototyping
 ethnography
 form analysis
 analysis of natural language
descriptions

14
Task Analysis
 Task analysis is the process of analyzing the way
people perform their jobs: the things they do, the
things they act on and the things they need to know.
 The relation between tasks and goals: a task is
performed in order to achieve a goal.
 Task analysis has a broad scope.

15
Task Analysis (cntd)
 Task analysis concentrates on the current situation.
However, it can be used as a starting point for a new
system:
 users will refer to new elements of a system and its
functionality
 scenario-based analysis can be used to exploit new
possibilities
 See also the role of task analysis as discussed in the
context of user interface design (chapter 16)

16
Scenario-Based Analysis
 Provides a more user-oriented view perspective on the
design and development of an interactive system.
 The defining property of a scenario is that it projects a
concrete description of an activity that the user
engages in when performing a specific task, a
description sufficiently detailed so that the design
implications can be inferred and reasoned about.

17
Scenario-Based Analysis (example)
 first shot:
 check due back date
 if overdue, collect fine
 record book as being available again
 put book back

 as a result of discussion with library employee:

 what if person returning the book is not registered as a
client?
 what if the book is damaged?
 how to handle in case the client has other books that are
18 overdue, and/or an outstanding reservation?
 Scenario-Based Analysis (cntd)
The scenario view The standard view

 concrete descriptions  abstract descriptions

 focus on particular instances  focus on generic types
 work-driven  technology-driven
 open-ended, fragmentary  complete, exhaustive
 informal, rough, colloquial  formal, rigorous
 envisioned outcomes  specified outcomes

19
Scenario-Based Analysis (cntd)
 Application areas:
 requirements analysis
 user-designer communication
 design rationale
 sofware architecture (& its analysis)
 software design
 implementation
 verification & validation
 documentation and training
 evaluation
 team building
 Scenarios must be structured and managed
20
Form analysis (example
Proceedings request form:
Client name ……………
Title ……………
Editor ……………
Place ……………
Publisher ……………
Year ……………

Certainty vs uncertainty

21
 Types of links between customer and
developer

 facilitated teams  observational study

 intermediary  user group
 support line/help desk  trade show
 survey  marketing & sales
 user interface prototyping
 requirements prototyping
 interview
 usability lab

22
Direct versus indirect links
 lesson 1: don’t rely too much on indirect links
(intermediaries, surrogate users)
 lesson 2: the more links, the better - up to a point
value add. link

# of links

23
Structuring a set of requirements
1. Hierarchical structure: higher-level reqs are
decomposed into lower-level reqs

1. Link requirements to specific stakeholders (e.g.

management and end users each have their own set)

In both cases, elicitation and structuring go hand in

hand

24
Goal-driven requirements
engineering
serving
cust.
why? how?

search
search
book
why?

search search
book news

25
Conflicting viewpoints
cash fines asap
John

e -to supports
r e s p o ns Pos A Arg A
issue:
fine
Pos B Arg B

taken-by

Mary
cash fines later
26
Prioritizing requirements
(MoSCoW)
Must haves: top priority requirements

Should haves: highly desirable

Could haves: if time allows

Won’t haves: not today

27
Prioritizing requirements (Kano
model)
Attractive: more satisfied if +, not less satisfied if –
Must-be: dissatisfied when -, at most neutral
One-dimensional: satisfaction proportional to number
Indifferent: don’t care
Reverse: opposite of what analist thought
Questionable: preferences not clear

28
 Kano diagram
satisfied

one-dimensional
attractive

dysfunctional functional
must-be

29
dissatisfied
COTS selection
COTS: Commercial-Off-The-Shelf
Iterative process:
Define requirements
Select components
Rank components
Select most appropriate component, or iterate
Simple ranking: weight * score (WSM – Weighted
Scoring Method)

30
Crowdsourcing
1. Go to LEGO site
2. Use CAD tool to design your favorite castle
3. Generate bill of materials
4. Pieces are collected, packaged, and sent to you

1. Leave your model in LEGO’s gallery

2. Most downloaded designs are prepackaged

 No requirements engineers needed!

 Gives rise to new business model

31
Requirements specification
 readable
 understandable
 non-ambiguous
 complete
 verifiable
 consistent
 modifiable
 traceable
 usable
 …
 ...

32
 IEEE Standard 830
1. Introduction 2. General description
1.1. Purpose 2.1. Product perspective
1.2. Scope 2.2. Product functions
1.3. Definitions, acronyms and 2.3. User characteristics
abbreviations 2.4. Constraints
1.4. References 2.5. Assumptions and
1.5. Overview dependencies
3. Specific requirements

33
 IEEE Standard 830 (cntd)
3. Specific requirements 3.2. Functional requirements
3.1. External interface 3.2.1. User class 1
requirements 3.2.1.1. Functional req. 1.1
3.1.1. User interfaces 3.2.1.2. Functional req. 1.2
3.1.2. Hardware interfaces ...
3.1.3. Software interfaces 3.2.2. User class 2
3.1.4. Comm. interfaces …
3.3. Performance requirements
3.4. Design constraints
3.5. Software system attributes
3.6. Other requirements

34
Requirements management
Requirements identification (number, goal-hierarchy
numbering, version information, attributes)
Requirements change management (CM)
Requirements traceability:
Where is requirement implemented?
Do we need this requirement?
Are all requirements linked to solution elements?
What is the impact of this requirement?
Which requirement does this test case cover?
Related to Design Space Analysis

35
The 7 sins of the analyst
 noise
 silence
 overspecification
 contradictions
 ambiguity
 forward references
 wishful thinking

36
Functional vs. Non-Functional
Requirements
 functional requirements: the system services which are
expected by the users of the system.
 non-functional (quality) requirements: the set of
constraints the system must satisfy and the standards
which must be met by the delivered system.
 speed
 size
 ease-of-use
 reliability
 robustness
 portability

37
Validation of requirements
 inspection of the requirement specification w.r.t.
correctness, completeness, consistency, accuracy,
readability, and testability.

 some aids:
 structured walkthroughs
 prototypes
 develop a test plan
 tool support for formal specifications

38
Summary
 goal: a maximally clear, and maximally complete,
description of WHAT is wanted
 RE involves elicitation, specification, validation and
negotiation
 modeling the UoD poses both analysis and negotiation
problems
 you must realize that, as an analyst, you are more than
an outside observer
 a lot is still done in natural language, with all its
inherent problems

39