Requirements

Engineering for Software

rd
and Systems, 3 Edition
Lecture 1: Introduction to
Requirements Engineering
 Today’s Topics
➢ What is requirements engineering?
➢ What are requirements?
➢ Requirements engineering activities
➢ The requirements engineer
➢ Requirements engineering paradigms
➢ Problems with traditional requirements
engineering

Requirements Engineering 3rd Edition, Lecture 1 2

 What is Requirements
Engineering?
“Requirements engineering is the branch of
software engineering concerned with the real-
world goals for, functions of, and constraints
on software systems. It is also concerned with
the relationship of these factors to precise
specifications of software behavior, and to
their evolution over time and across software
families.” (Zave, 1997)

Requirements Engineering 3rd Edition, Lecture 1 3

 What are Requirements?

➢ Can range from a high-level, abstract

statements and back of the napkin sketches
to a formal specification
➢ Stakeholders have needs at different levels,
hence, different abstraction representations
➢ Stakeholders have varying abilities to make
and read these representations (e.g. a
business customer versus a design engineer)

Requirements Engineering 3rd Edition, Lecture 1 4

Requirements Classification

➢ Sommerville (2005) suggests three

levels of abstraction
⚫ User requirements

⚫ System requirements

⚫ Software design specifications

Requirements Engineering 3rd Edition, Lecture 1 5

 User Requirements
➢ Abstract statements written in natural
language with accompanying informal
diagrams.
➢ Specify what services (user
functionality) the system is expected to
provide and any constraints.
⚫ “The system should be able to handle 20
bags per minute”
➢ User stories can play this role.
Requirements Engineering 3rd Edition, Lecture 1 6
 System Requirements
➢ Detailed descriptions of the services and
constraints.
➢ Should be structured and precise.
➢ Acts as contract between client and
contractor.
➢ Sometimes referred to as functional
specification or technical annex.
➢ Derived from analysis of the user
requirements.
➢ Use cases can play this role
Requirements Engineering 3rd Edition, Lecture 1 7
 Software Specifications
➢ The analysis and design
documentation used as basis for
implementation by developers.
➢ Derived from analysis of the system
specification.
➢ This is the “contractual” Software
Requirements Specification that we
most often talk about
Requirements Engineering 3rd Edition, Lecture 1 8
Baggage Handling Example
➢ User requirement
⚫ “The system should be able to handle 20 bags per minute”
➢ System Requirement
⚫ Each bag processed shall trigger a baggage event.
⚫ The system shall be able to handle 20 baggage events per
minute
➢ Software specification
⚫ 1.2 The system shall be able to process 20 baggage events
per minute in operational mode
⚫ 1.2.1 If more than 20 baggage events occur in an a one
minute interval, then the system shall…
⚫ 1.2.2 More exception handling…

Requirements Engineering 3rd Edition, Lecture 1 9

 Pet Store POS Example
➢ User requirement
⚫ The system shall accurately compute sale totals including
discounts, taxes, refunds, and rebates; print an accurate receipt;
and update inventory counts accordingly.
➢ System Requirement
⚫ Each sale shall be assigned a sale id.
⚫ Each sale may have one or more sales items
⚫ Each sale may have one or more rebates
⚫ Each sale may have only one receipt printed
➢ Software specification
⚫ 1.2 The system shall assign a unique sales id number to each sale
transaction.
⚫ 1.2.1 Each sales id may have zero or more sales items associated
to it, but each sales item must be assigned to exactly one sales id

Requirements Engineering 3rd Edition, Lecture 1 10

 Software Requirements
Specifications Include
➢ Functional requirements

➢ Non-functional requirements (NFRs)

➢ Domain requirements

Requirements Engineering 3rd Edition, Lecture 1 11

Functional Requirements
➢ The services the system should provide.
➢ How it will react to inputs.
➢ Need to explicitly state what the system
should not do.
➢ Can be high-level and general (user
requirements) or detailed, expressing
inputs, outputs, exceptions, etc. (system
requirements).
➢ Many forms of representation from NL,
visual models, to formal methods.
Requirements Engineering 3rd Edition, Lecture 1 12
 Functional Requirements
(Baggage Handling System)
➢ 1.1 The system shall handle up to 20 bags per
minute
➢ 1.4 When the system is in idle mode, the
conveyor belt shall not move
➢ 1.8 If main power fails, the system shall shut
down in an orderly fashion within 5 seconds
➢ 1.41 If the conveyor belt motor fails, the system
shall shut the input feed mechanism within 3
seconds

Requirements Engineering 3rd Edition, Lecture 1 13

 Functional Requirements
(Pet Store POS)
➢ 4.1 When the operator presses the “total”
button, the current sale enters the closed
out.
➢ 4.1.1 When a sale enters the closed out
state a total for each non-sale item is
computed as number of items times the list
price of the item
➢ 4.1.2. When a sale enters the closed out
state a total for each sale item is
computed…

Requirements Engineering 3rd Edition, Lecture 1 14

Non-functional Requirements
➢ Requirement imposed by the environment
in which the system is to exist.
➢ This includes timing constraints, quality
properties, standard adherence,
programming languages to be used, etc.
➢ Some of these non-functional
requirements are counter intuitive (e.g.
timing).

Requirements Engineering 3rd Edition, Lecture 1 15

Non-functional Requirement Types
(Sommerville)
Non-functional
requirements

Product Organisational External

requirements requirements requirements

Portability
Efficiency Reliability Interoperability Ethical
requirements
requirements requirements requirements requirements

Implementatio
Usability Delivery Standards Legislative
n
requirements requirements requirements requirements
requirements

Performance Space Privacy Safety

requirements requirements requirements requirements

Requirements Engineering 3rd Edition, Lecture 1 16

 Non-functional Requirements
(Baggage Handling System)
➢ Product requirements
⚫ Efficiency
• Performance (e.g. number of bags per minute)
• Space (e.g. physical size of system, amount of memory, power consumption)
⚫ Reliability (MTBF, MTFF)
⚫ Portability (e.g. can it be used with other hardware?)
⚫ Usability (amount of training required)
➢ Organizational requirements
⚫ Delivery (e.g. date of delivery, fully operational, training sessions, updates)
⚫ Implementation (e.g. full capability in first roll-out or phased?)
⚫ Standards (if there are industry standards for baggage handling systems)
➢ External requirements
⚫ Interoperability (e.g. with other equipment, communications standards, etc.)
⚫ Ethical (e.g. security clearance for REs, professional certification)
⚫ Legislative
• Privacy (e.g. HIPPA, FERPA)
• Safety (OSHA)

Requirements Engineering 3rd Edition, Lecture 1 17

 Non-functional Requirements
(Pet Store POS System)
➢ Product requirements
⚫ Efficiency
• Performance (e.g. time to finalize a sale transaction)
• Space (e.g. physical size of system, amount of memory, power consumption)
⚫ Reliability (MTBF, MTFF)
⚫ Portability (e.g. can it be used with other hardware?)
⚫ Usability (amount of training required)
➢ Organizational requirements
⚫ Delivery (e.g. date of delivery, fully operational, training sessions, updates)
⚫ Implementation (e.g. full capability in first roll-out or phased?)
⚫ Standards (if there are industry standards for POS systems)
➢ External requirements
⚫ Interoperability (e.g. with other equipment, communications standards, etc.)
⚫ Ethical (e.g. professional certification for sales associates)
⚫ Legislative
• Privacy (e.g. general laws governing credit card transactions)
• Safety (OSHA)

Requirements Engineering 3rd Edition, Lecture 1 18

 Requirements and Testing
Levels
User Acceptance
Requirements Testing

System Integration
Requirements Testing

System Design Unit Testing

Specifications

Artifact
System Engineering
development
Development Activity
sequence
Sequence

Requirements Engineering 3rd Edition, Lecture 1 19

Goals versus Requirements
➢ Some NFRs are difficult to define precisely making
them difficult to verify.
➢ Should distinguish goals from NFRs
⚫ Goal – a general intention of a stakeholder

The system should be easy to use by experienced

operators

➢ Verifiable NFR – statement using some objective

measure.
Experienced operators shall be able to use all the
system functions after 2 hours of training

Requirements Engineering 3rd Edition, Lecture 1 20

Goals versus Requirements

Requirements Engineering 3rd Edition, Lecture 1 21

 Domain Requirements
➢ Derived from the application
domain.
➢ May be:
⚫ New functional requirements.

⚫ Constraints on existing functional

requirements.
⚫ Specify how particular

computations must be performed.

Requirements Engineering 3rd Edition, Lecture 1 22
 Domain Requirements (Baggage)
➢ For
the baggage handling system, various
domain realities create requirements.
⚫ Industry standards (you wouldn’t want the
new system to under perform versus other
airlines’ systems)
⚫ Constraints imposed by existing hardware
available (e.g. conveyor systems)
⚫ Union contracts (there may be constraints
based on collective bargaining agreements)

Requirements Engineering 3rd Edition, Lecture 1 23

 Domain Requirements (Pet Store)
➢ Forthe Pet Store POS system, domain
requirements are imposed by the
conventional store practices.
⚫ Handling of cash, credit cards, coupons
⚫ Display interface and receipt format
⚫ Conventions in the pet store industry
(frequent buyer incentives?)
⚫ Sale of items by the pound (e.g. horse feed)
versus by item count
Requirements Engineering 3rd Edition, Lecture 1 24
 Requirements Engineering
Activities
➢ Requirements elicitation/discovery
➢ Requirements analysis and reconciliation
➢ Requirements representation/modeling
➢ Requirements verification and validation
➢ Requirements management
➢ There are others, but these are the “major”
ones

Requirements Engineering 3rd Edition, Lecture 1 25

Requirements Elicitation/Discovery
➢ Involves uncovering what the customer
needs and wants
➢ It’s not picking apples! Requirements have
to be found and/or teased out
➢ Also involves discovering who the
stakeholders are (hidden stakeholders?)
➢ Don’t forget non-functional requirements!

Requirements Engineering 3rd Edition, Lecture 1 26

 Requirements Analysis and
Reconciliation
➢ Raw requirements don’t always make sense.
➢ Raw requirements often contradict one another
(and not always obviously so).
➢ Raw requirements are inconsistent
➢ Raw requirements are incomplete
➢ Raw requirements are vague or just wrong
➢ Raw requirements interact and are dependent
on each other
➢ Requirements analysis and reconciliation
involves techniques to deal with these problems.
Requirements Engineering 3rd Edition, Lecture 1 27
 Requirements Representation
➢ Converting the requirements processed raw
requirements into some model (usual natural language,
math, and visualizations)
➢ Facilitates communication of requirements and
conversion into a system architecture and design
➢ Uses techniques that are
⚫ Informal (e.g. natural language, diagrams)
⚫ Formal (mathematically sound representation)
⚫ Semi-formal (convertible to a sound representation or is partially
rigorous)
➢ Usually some combination of these are employed in
requirements representation

Requirements Engineering 3rd Edition, Lecture 1 28

 Requirements Validation
➢ Validation : “Am I building the right
system”
➢ Verification: “Am I building the system
right?”
➢ Requirements validation involves various
semi-formal and formal methods, text
based tools, visualizations, inspections,
and so on

Requirements Engineering 3rd Edition, Lecture 1 29

 Requirements Management
➢ Managing the realities of changing requirements
over time
➢ Fostering traceability through appropriate
aggregation and subordination of requirements
➢ Communicating changes in requirements to
those who need to know
➢ Intelligently providing “push back” when scope
creep ensues
➢ Using tools to track changes and maintain
traceability

Requirements Engineering 3rd Edition, Lecture 1 30

 The Requirements Engineer
➢ What skills should a requirements
engineer have?
➢ Christensen and Chang suggest that the
RE should be:
⚫ Organized
⚫ Have experience throughout the SWE
lifecycle
⚫ Maturity to know when to be general and
when to be specific – and be able to stand up
to the customer when necessary
Requirements Engineering 3rd Edition, Lecture 1 31
 The Requirements Engineer
➢ Christensen and Chang further suggest that the
RE should be:
⚫ Be a good manager (to manage the process)
⚫ Good listener
⚫ Fair
⚫ Good negotiator
⚫ Understand the problem domain
⚫ Multidisciplinary (e.g. traditional hard sciences and
engineering augmented with communications and
management skills)

Requirements Engineering 3rd Edition, Lecture 1 32

 The Requirements Engineer
➢ Gorla and Lam (2004) imply that
engineers should be “thinking,” “sensing,”
and “judging” in the Myers-Briggs sense
➢ We could interpret this to mean that REs
are structured and logical (thinking), focus
on information gathered and do not try to
interpret it (sensing), and seek closure
rather than leaving things open (judging)

Requirements Engineering 3rd Edition, Lecture 1 33

 Role of the Customer?
➢ Helping the RE understand what they need and want
(elicitation and validation)
➢ Helping the RE understand what they don’t want
(elicitation and validation)
➢ Providing domain knowledge when necessary
➢ Alerting the RE quickly and clearly when they discover
that they or the RE have made mistakes
➢ Alerting the RE quickly when they determine that
changes are necessary (really necessary)
➢ Controlling their urges to have “aha moments” that cause
major scope creep
➢ Sticking to all agreements
➢ The RE must manage customer’s expectations in these
regards.
Requirements Engineering 3rd Edition, Lecture 1 34
 RE Paradigms
➢ RE as Software Engineer
➢ RE as SME
➢ RE as architect
➢ RE as business process expert
➢ Ignorance as virtue?

Requirements Engineering 3rd Edition, Lecture 1 35

 RE as Software Engineer
➢ Wiegers notes that most REs are probably
formal software designers or developers.
➢ Unclear how often this is true.
➢ When this is true the RE can positively
influence downstream development of
models (i.e. the software design).
➢ Danger is that RE begins to do software
design when they should be developing
requirements specifications
Requirements Engineering 3rd Edition, Lecture 1 36
 RE as SME
➢ Thecustomer is looking to the RE for
expertise –
⚫ in helping to understand the problem domain
⚫ In understanding their own wants and desires
➢ RE isn’t always a SME – they are an
expert in RE
➢ In those cases where the RE is not an
SME consider joining forces with a SME

Requirements Engineering 3rd Edition, Lecture 1 37

 RE as Architect
➢ Building construction often used as a metaphor for
software construction.
➢ In my experience Architects and Landscape Architects
play similar roles to REs.
➢ Berry has written about this extensively.
⚫ Berry, D.M., ``Software and House Requirements Engineering:
Lessons Learned in Combatting Requirements Creep,''
Requirements Engineering Journal, 3:3&4, pp. 242--244, 1999
⚫ Berry, D.M., ``More Requirements Engineering Adventures with
Building Contractors,'' Requirements Engineering Journal, 2003
⚫ Berry notes that the analogous activities reduces scope creep and
better involves customer in RE process
⚫ My personal experience confirms these observations
➢ Zachman (1987) introduced an architectural metaphor for
information systems.
Requirements Engineering 3rd Edition, Lecture 1 38
 Home Building
Home Building Software/System Building
Architect meets with and interviews RE meets with customers and uses
clients. Tours property. Takes notes interviews and other elicitation
and pictures techniques.
Architect makes rough sketches RE makes models of requirements to
(shows to clients, receives feedback show to customers (e.g. prototypes,
draft SRS)
Architect makes more sketches (e.g. Architect refines requirements and
elevations) and perhaps more adds formal and semi-formal elements
sophisticated models (e.g. cardboard, (e.g. UML). More prototyping is used.
3D-virtual models, fly-through
animations)
Architect prepares models with RE uses information determined
additional detail (floor plans) above to develop complete SRS
Future models (e.g. construction Future models (e.g. software design
drawings) are for contractors’ use documents) are for developers’ use
Requirements Engineering 3rd Edition, Lecture 1 39
RE as Business Process Expert
➢ Requirements engineering is problem
solving – the customer has a problem and
our system must solve it
➢ Often involves RE advising changes in
business processes often to simplify
expression of system behavior

Requirements Engineering 3rd Edition, Lecture 1 40

 Ignorance as Virtue
➢ Berry (1995) suggests having both novices and
experts in the problem domain involved in the
RE process.
➢ The “ignorant” people ask the “dumb” questions
➢ The experts answer these questions.
➢ Berry also notes that using formal methods in
requirements engineering is a form of ignorance
because a mathematician is generally ignorant
about an application domain before he or she
starts modeling it.

Requirements Engineering 3rd Edition, Lecture 1 41

 Problems with Traditional RE
➢ Natural language problems (e.g. ambiguity, imprecision)
➢ Domain understanding
➢ Dealing with complexity (especially temporal behavior)
➢ Difficulties in enveloping system behavior
➢ Incompleteness (missing functionality)
➢ Over-completeness (gold plating)
➢ Overextension (dangerous “all”)
➢ Inconsistency
➢ Incorrectness
➢ And more

Requirements Engineering 3rd Edition, Lecture 1 42

 Four Dark Corners (Zave and
Jackson)
➢ (1) “All the terminology used in
requirements engineering should be
grounded in the reality of the environment
for which a machine is to be built.”

Requirements Engineering 3rd Edition, Lecture 1 43

 Four Dark Corners (Zave and
Jackson)
➢ (2) “It is not necessary or desirable to
describe (however abstractly) the machine
to be built.
⚫ Rather, the environment is described in two
ways as it would be without or in spite of the
machine and as we hope it will become
because of the machine.”
⚫ Specifications are the what to be achieved by
the system, not the how.

Requirements Engineering 3rd Edition, Lecture 1 44

 Four Dark Corners (Zave and
Jackson)
➢ (3) “Assuming that formal descriptions focus on
actions, it is essential to identify which actions
are controlled by the environment, which actions
are controlled by the machine, and which
actions of the environment are shared with the
machine.
⚫ All types of actions are relevant to requirements
engineering, and they might need to be described or
constrained formally.
⚫ If formal descriptions focus on states, then the same
basic principles apply in a slightly different form.”

Requirements Engineering 3rd Edition, Lecture 1 45

 Four Dark Corners (Zave and
Jackson)
➢ (4) “The primary role of domain knowledge
in requirements engineering is in
supporting refinement of requirements to
implementable specifications .
⚫ Correct specifications, in conjunction with
appropriate domain knowledge, imply the
satisfaction of the requirements.”
⚫ Failure to recognize the role of domain
knowledge can lead to unfilled requirements
and forbidden behavior.

Requirements Engineering 3rd Edition, Lecture 1 46

 Danger of “All” in specifications
➢ Requirement specification sentences usually
involve some universal quantification (e.g. “all
users shall be able to access…”)
➢ “All” specifications are dangerous because they
are usually not true (Berry, 2000).
➢ Related to “all” specifications are ``never'',
``always'', ``none'', and ``each'‘ (because they
can be formally equated to universal
quantification)
➢ Be careful when using the above words or their
mathematical equivalents in specifications

Requirements Engineering 3rd Edition, Lecture 1 47

 Forbidden Behavior
Desired system behavior

Behavior
specified
Missing
functionality

Undesirable
+ some
desirable
behavior

Unwanted
Universe of all possible system behaviors behavior and
desirable
behavior not
Requirements Engineering 3rd Edition, Lecture 1 specified 48
 “Thou Shalt Not”
➢ The “software shall not…”
➢ Sometimes called “hazards” or “forbidden
behavior”
➢ Known “shall nots” not problem, what about
unknown forbidden behavior?
➢ George Costanza and the cleaning lady story –
“was I not supposed to do that?”
➢ “When the ‘conveyor jam’ signal is set to the
high state, the feed mechanism shall not permit
additional items to enter the conveyor system”

Requirements Engineering 3rd Edition, Lecture 1 49

 Complexity
➢ Difficulty
in describing even the simplest of
“repeatable” human endeavors
➢ Consider the task of waking up in the
morning
➢ Consider the task of cutting the lawn
➢ Consider the task of food shopping
➢ Now consider a complex information
system
Requirements Engineering 3rd Edition, Lecture 1 50
 Wicked Problems
➢ Wicked problems have ten characteristics: (Rittel
and Webber 1974)
1. There is no definitive formulation of a wicked problem.
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not true-or-false but
good-or-bad.
4. There is no immediate and no ultimate test of a solution
to a wicked problem.
5. Every solution to a wicked problem is a "one-shot
operation"; because there is no opportunity to learn by
trial-and-error, every attempt counts significantly
Requirements Engineering 3rd Edition, Lecture 1 51
 Wicked Problems
6. Wicked problems do not have an enumerable (or an
exhaustively describable) set of potential solutions, nor
is there a well-described set of permissible operations
that maybe incorporated into the plan
7. Every wicked problem is essentially unique.
8. Every wicked problem can be considered a symptom
of another problem.
9. The existence of a discrepancy representing a wicked
problem can be explained in numerous ways. The
choice of explanation determines the nature of the
problem's resolution
10. The planner (designer) has no right to be wrong.

Requirements Engineering 3rd Edition, Lecture 1 52

 Dealing with Wicked Problems
➢ Ritteland Webber mean wicked problems
to be of an economic, political and societal
nature (e.g. hunger, drug abuse, peace in
the Middle East…)
➢ Therefore, they offer no appropriate
solution strategy for RE
➢ Nevertheless, it is helpful to view RE as a
wicked problem

Requirements Engineering 3rd Edition, Lecture 1 53