Requirements Engineering
Lecture 2
1Chapter 4 Requirements engineering
Requirements engineering (RE)
 Requirements are descriptions of system services and
constraints under which the system operates and is
developed.
 It may range from a high-level abstract statement of a service
or of a system constraint to a detailed mathematical functional
specification.
 Requirements engineering is the process of
establishing requirements.
2Chapter 4 Requirements engineering
Outline
 Requirements and their types
 Requirements engineering process
 Requirements elicitation and analysis
 Requirements validation
 Requirements management
 UML Use Case diagram
3Chapter 4 Requirements engineering
Requirements and their Types
Lecture 2/Part 1
4Chapter 4 Requirements engineering
Types of requirements
 User requirements
 Statements of the services the system provides to the users and
its operational constraints.
• In natural language and/or diagrams.
 For client managers, client engineers and system architects.
 System requirements
 Detailed descriptions of the system’s functions, services and
operational constraints. Define what should be implemented.
• In structured document and/or diagrams.
 For client engineers, system architects and system developers.
 Which of them are more abstract/concrete?
5Chapter 4 Requirements engineering
User and system requirements
6Chapter 4 Requirements engineering
Functional and non-functional requirements
 Functional requirements
 Statements of services the system provides, how the system
should react to particular inputs and how the system should
behave in particular situations.
 E.g. A user shall be able to search the appointments lists for all
clinics.
 Non-functional requirements
 Properties and constraints on the services offered by the
system such as timing, reliability and security constraints,
constraints on the development process, platform, standards, etc.
 E.g. The system shall be available on Mon–Fri, 8 am – 5 pm,
with downtime not exceeding five seconds in any one day.
 Can you think of more examples of the two types?
7Chapter 4 Requirements engineering
Requirements quality criteria
 Precise
 Is there only one interpretation for the requirement in the
system context?
 Complete
 Are all functions required by the customer included?
 Consistent
 Are there any requirements conflicts or contradictions?
8Chapter 4 Requirements engineering
Additional quality criteria
 Comprehensibility
 Are all requirements properly understood?
 Realism
 Can the requirements be implemented given available budget
and technology?
 Verifiability
 Can the requirements be checked?
 Traceability
 Is the origin of the requirement clearly stated?
 Adaptability
 Can the req. be changed without a large impact on other req.?
9Chapter 4 Requirements engineering
Key points
 Requirements = services + constraints
 Types of requirements
 Vertically – user vs. system requirements
 Horizontally – functional vs. non-functional requirements
 Quality criteria
 Precision, completeness, consistency.
 Comprehensibility, realism, verifiability, traceability, adaptability.
10Chapter 4 Requirements engineering
Requirements Engineering Process
Lecture 2/Part 2
11Chapter 4 Requirements engineering
Outline
 Requirements elicitation and analysis
 Requirements validation
 Requirements management
12Chapter 4 Requirements engineering
Requirements engineering processes
 The processes used for RE vary widely depending on
the application domain, the people involved and the
organisation developing the requirements.
 However, there are a number of generic activities
common to all processes
 Requirements elicitation and analysis;
 Requirements validation;
 Requirements management.
 In practice, RE is an iterative activity in which these
processes are interleaved.
 Is there a relation to Boehm’s model from Lecture 1?
13Chapter 4 Requirements engineering
Requirements elicitation and analysis
 Software engineers work with system stakeholders:
 end-users, managers, maintenance engineers, domain experts,
trade unions, etc.
 To find out about:
 the application domain,
 the services that the system should provide,
 the required system performance,
 hardware constraints,
 other systems, etc.
 As far as possible, it should set of WHAT the system
should do rather than HOW it will do (implement) it.
Chapter 4 Requirements engineering 14
The requirements elicitation and analysis
process
15Chapter 4 Requirements engineering
+ Requirements verification
and validation
Where shall this activity come?
Process activities
 Requirements discovery
 Interacting with stakeholders and studying existing processes
and needs to discover their requirements.
 Requirements classification and organisation
 Groups related requirements and organises them into clusters.
 Prioritisation and negotiation
 Prioritising requirements and resolve stakeholder conflicts.
 Requirements specification
 Requirements are documented and input into the next iteration.
 Requirements verification and validation
 Identify and resolve requirements quality problems
Requirements discovery
 Questionnaires
 Interviews
 Small number of software engineers and stakeholders
 Workshops
 Large group of interested parties; free brainstorming
 Ethnography
 Observe existing processes
 Is there a recommended order if the techniques are
combined?
Chapter 4 Requirements engineering 17
Interviews and workshops
 Formal or informal interviews with stakeholders are part
of most RE processes.
 Types of interview
 Closed interviews based on pre-determined list of questions
 Open interviews where various issues are explored
 Workshops with brainstorming of all involved stakeholders
 Effective interviewing
 Be open-minded, avoid pre-conceived ideas about the
requirements and are willing to listen to stakeholders.
 Prompt the interviewee to get discussions going using a
springboard question, a requirements proposal, or by working
together on a prototype system.
Chapter 4 Requirements engineering 18
Ethnography
 A social scientist 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.
19Chapter 4 Requirements engineering
Requirements classification and
prioritisation
 MoSCoW criteria
 Must have – mandatory requirement fundamental to the system
 Should have – important requirement that may be omitted
 Could have – truly optional requirement
 Want to have – requirement that can wait for later releases
 RUP attributes
 Status – Proposed/Approved/Rejected/Incorporated
 Benefit – Critical/Important/Useful
 Effort – number of person days/functional points/etc.
 Risk – High/Medium/Low
 Stability – High/Medium/Low
 Target Release – future product version
Requirements specification
Notation Description
Naturallanguage Numbered sentences in natural language, each sentence expressing one
requirement. E.g.Project assignment.
Structured natural
language
The requirements are written in natural language on a standard form or
template. Each field provides information about an aspect of the requirement.
E.g.Textual specificationofUML use cases.(the table view)
Design description
languages
This approach uses a language like a programming language, but with more
abstract features to specify the requirements by defining an operational model
of the system.E.g. Main flow in the UML UC textual specification.
Graphical
notations
Graphical models, supplemented by text annotations, are used to define the
functional requirements for the system. E.g. UML use case and activity
diagrams.
Mathematical
specifications
Notations based on mathematical concepts; E.g. finite-state machines or sets.
Although they can reduce the ambiguity in a requirements document, most
customers don’t understand them and are reluctant to accept it as a system
contract
21Chapter 4 Requirements engineering
 When shall we choose mathematical specification?
Requirements verification and validation
 Requirements verification
 Concerned with checking requirements precision, completeness,
consistency, comprehensibility, realism, verifiability, traceability,
and adaptability (to the expected extent).
 Requirements validation
 Concerned with checking that the requirements define the
system that the customer reallywants.
 Requirements error costs are high so verification and
validation is very important
 Fixing a requirements error after delivery may cost up to 100
times the cost of fixing an implementationerror.
22Chapter 4 Requirements engineering
Requirements validation techniques
 Requirements reviews
 Systematic manual analysis of the requirements.
 Both client and contractor staff should be involved.
 Reviews may be formal (with completed documents) or
informal (relying on good communications between developers,
customers and users).
 Prototyping
 Using an executable model of the system to check customer
satisfaction.
23Chapter 4 Requirements engineering
Requirements management
 Requirements management is the process of managing
changing requirements during the requirements
engineering process and system development.
 New requirements emerge as a system is being
developed and tested by the users. Some due to
business, organizational and technical changes.
 Traceability and maintenance of links between
dependent requirements is important to assess the
impact of requirements changes.
 We may need a formal process for making change
proposals and linking these to system requirements.
24Chapter 4 Requirements engineering
Requirements evolution
25Chapter 4 Requirements engineering
 Each requirements change should be analysed before
deciding whether to accept it.
 Analyse the problem, check the validity of the change proposal
 Asses the effects of the change, via traceability information
 Integrate the change in the specification documents
Decide what changes shall
be accepted
Key points
 Requirements engineering is an iterative activity.
 Requirements discovery
 Questionnaires, interviews, workshops, ethnography
 Requirements prioritization
 MoSCoW, RUP attributes
 Requirements specification
 Requirements verification and validation
 Requirements management and evolution
Chapter 4 Requirements engineering 26
UML Use Case Diagram
Lecture 2/Part 3
27Chapter 4 Requirements engineering
Outline
 Use Case modelling
 System boundary – subject
 Use cases
 Actors
 Textual Use Case specification
 Advanced Use Case modelling
 Actor generalisation
 Use case generalisation
 «include»
 «extend»
28Chapter 4 Requirements engineering
© Clear View Training 2010 v2.6 29
The purpose of Use Case modelling
 Use case modelling is a form of requirements
engineering
 Use case modelling proceeds as follows:
 Find the system boundary
 Find actors – who or what uses the system
 Find use cases – what functions the system should offer
 Specify use cases – with textual specification or UMLActivity
Diagrams
© Clear View Training 2010 v2.6 30
The subject
 We create a Use Case model containing:
 Subject – the edge of the system
• also known as the system boundary
 Actors – who or what uses the system
 Use Cases – things actors do with the
system; functions the system should
offer to its users
 Relationships – between actors and
use cases
 Can there be a direct relationship
between actors?
SystemName
subject
© Clear View Training 2010 v2.6 31
What are actors?
 An actor is anything that interacts directly
with the system
 Actors identify who or what
uses the system and so indicate
where the system boundary lies
 Actors are external
to the system
 An Actor specifies a role that some external entity
adopts when interacting with the system
 Can one actor represent two physical persons?
 Can one physical person match to two actors?
 Can there be two actors with the same name in the model?
Customer
«actor»
Customer
© Clear View Training 2010 v2.6 32
Identifying Actors
 When identifying actors ask:
 Who or what uses the system?
 What roles do they play in the interaction?
 Who installs the system?
 Who starts and shuts down the system?
 Who maintains the system?
 What other systems use this system?
 Who gets and provides information to the system?
 Does anything happen at a fixed time?
 What if the actor is not a human? What can it be?
Time
© Clear View Training 2010 v2.6 33
What are use cases?
 A use case is something an actor needs the system to
do. It is a “case of use” of the system by a specific actor.
 Use cases are always started by an actor
 The primaryactor triggers the use case
 Zero or more secondaryactors interact with the use case in
some way
 Does the UC diagram tell me which actor is primary/secondary?
 Use cases are always written from the point of view of
the actors.
PlaceOrder GetStatusOnOrder
© Clear View Training 2010 v2.6 34
Identifying use cases
 Start with the list of actors that interact with the system
 When identifying use cases ask:
 What functions will a specific actor want from the system?
 Does the system store and retrieve information? If so, which
actors trigger this behaviour?
 What happens when the system changes state (e.g. system start
and stop)?Are any actors notified?
 Are there any external events that affect the system? What
notifies the system about those events?
 Does the system interact with any external system?
 Does the system generate any reports?
© Clear View Training 2010 v2.6 35
The use case diagram
MailOrder System
PlaceOrder
SendCatalogue
CancelOrder
CheckOrderStatusCustomer
ShipProduct
ShippingCompany
Dispatcher
communication
relationship
actor
subjectname
system boundary
MailOrder System use case diagram
use case
© Clear View Training 2010 v2.6 36
Textual use case specification
Use case:PaySalesTax
Primary actors:
Time
Preconditions:
1. It is the end of the businessquarter.
Postconditions:
1.The Tax Authority receivesthe correctamountof Sales Tax.
Main flow:
The use case starts when it is the end of the business quarter.
The system determinesthe amountof Sales Tax owed to the Tax
Authority.
The system sendsan electronic paymentto the Tax Authority.
1.
2.
3.
use case name
the actors involved in the
use case
the system state before
the use case can begin
the actualsteps of the use
case
the system state when the
use case has finished
Alternative flows:
None.
alternative flows
ID: 1use case identifier
Brief description:
Pay Sales Tax to the Tax Authority at the end of the business quarter.
brief description
implicittime actor
Secondary actors:
TaxAuthority
© Clear View Training 2010 v2.6 37
Naming use cases
 Use cases describe something that happens
 They are named using verbs or verb phrases
 Naming standard 1: use cases are named using
UpperCamelCase e.g. PaySalesTax
1 UML 2 does not specify any naming standards.
All naming standards here are based on industry best practice.
© Clear View Training 2010 v2.6 38
Pre and postconditions
 Preconditions and postconditions
are constraints.
 Preconditions constrain the state
of the system before the use case
can start
 Postconditions constrain the state
of the system after the use case
has executed
 What pre/postconditions does a
delete of a product have?
 What about if the deletion is not
successful?
Preconditions:
1. A valid user has logged on to the
system
Postconditions:
1. The order has been marked
confirmed and is saved by the system
Use case: PlaceOrder
© Clear View Training 2010 v2.6 39
Main flow
 The flow of events lists the steps in a use case
 It always begins by an actor doing something
 A good way to start a flow of events is:
1) The use case starts when an <actor> <function>
 The flow of events should be a sequence of short steps that are:
 Declarative
 Numbered,
 Time ordered
 The main flow is always the happy day scenario
 Everything goes as expected, without errors, deviations and interrupts
 Alternatives can be shown by branching or by listing under Alternative
flows (see later)
<number> The <something> <some action>
© Clear View Training 2010 v2.6 40
Branching within a flow: IF
 Use the keyword IF to
indicate alternatives
within the flow of events
 There must be a
Boolean expression
immediately after IF
 Use indentation and
numbering to indicate
the conditional part of
the flow
 Use ELSE to indicate
what happens if the
condition is false
Use case: ManageBasket
Primary actors:
Customer
Preconditions:
1. The shopping basket contents are visible.
Postconditions:
None.
Main flow:
The use case starts when the Customer selects an item in the
basket.
IF the Customer selects "delete item"
IF the Customer types in a new quantity
1.
2.
3.
The system removes the item from the basket.2.1
The system updates the quantity of the item in the basket.3.1
ID: 2
Brief description:
The Customer changes the quantity of an item in the basket.
Alternative flows:
None.
Secondary actors:
None.
© Clear View Training 2010 v2.6 41
Repetition within a flow: FOR
 We can use the
keyword FOR to
indicate the start of a
repetition within the
flow of events
 The iteration
expression immediately
after the FOR
statement indicates the
number of repetitions of
the indented text
beneath the FOR
statement.
ID: 3
Actors:
Customer
Preconditions:
None.
Main flow:
1. The use case starts when the Customer selects "find product".
2. The system asks the Customer for search criteria.
3. The Customer enters the requested criteria.
4. The system searches for products that match the Customer's criteria.
5. FOR each product found
5.1. The system displays a thumbnail sketch of the product.
5.2. The system displays a summary of the product details.
5.3. The system displays the product price.
Postconditions:
None.
Alternative flows:
NoProductsFound
Use case: FindProduct
Brief description:
The system finds some products based on Customer search criteria and
displays them to the Customer.
© Clear View Training 2010 v2.6 42
Repetition within a flow: WHILE
 We can use the
keyword WHILE to
indicate that something
repeats while some
Boolean condition is
true
ID: 4
Primary actors:
Customer
Preconditions:
None.
Main flow:
1. The use case starts when the Customer selects "show company details".
2. The system displays a web page showing the company details.
3. WHILE the Customer is browsing the company details
4. The system searches for products that match the Customer's criteria.
4.1. The system plays some background music.
4.2. The system displays special offers in a banner ad.
Postconditions:
1. The system has displayed the company details.
2. The system has played some background music.
3. The systems has displayed special offers.
Alternative flows:
None.
Use case: ShowCompanyDetails
Brief description:
The system displays the company details to the Customer.
Secondary actors:
None
© Clear View Training 2010 v2.6 43
Branching: Alternative flows
 Alternative flows capture
errors, branches, and
interrupts
 They can often be
triggered at any time
during the main flow
 Alternative flows never
return to the main flow
main flow
alternative flows
Use case
Only document enough alternative flows to
clarify the requirements!
© Clear View Training 2010 v2.6 44
Referencing alternative flows
 List the names of the
alternative flows at the
end of the use case
 Find alternative flows
by examining each
step in the main flow
and looking for:
 Alternatives
 Exceptions
 Interrupts
Alternative
flows
Main flow:
Use case: CreateNewCustomerAccount
Preconditions:
None.
Brief description:
The system creates a new account for the Customer.
Postconditions:
1. A new account has been created for the Customer.
Alternative flows:
InvalidEmailAddress
InvalidPassword
Cancel
The use case begins when the Customer selects "create
new customer account".
WHILE the Customer details are invalid
The system creates a new account for the Customer.
The system asks the Customer to enter his or her details
comprising email address, password and password
again for confirmation.
The system validates the Customer details.
1.
2.
3.
2.1.
2.2
ID: 5
Primary actors:
Customer
Secondary actors:
None.
© Clear View Training 2010 v2.6 45
Advanced Use Case modelling
 We have studied basic use case analysis, but there are
relationships that we have still to explore:
 Actor generalisation
 Use case generalisation
 «include» – between use cases
 «extend» – between use cases
© Clear View Training 2010 v2.6 46
Actor generalization - example
 The Customer and the
Sales Agent actors are
very similar
 They both interact with
List products, Order
products,Accept payment
 They both can play the
purchaser role.
 Can we always generalize
two actors sharing some
use cases?
Sales system
ListProducts
OrderProducts
AcceptPayment
CalculateCommission
Customer
SalesAgent
© Clear View Training 2010 v2.6 47
Actor generalisation
 If two actors share the same
sub-role, which makes them
communicate with the same
set of use cases
 The descendent actors inherit
the roles and relationships
to use cases held by the
ancestor actor
 We can substitute a
descendent actor anywhere
the ancestor actor is expected.
This is the substitutability
principle
 Can we always generalize two
actors sharing some use
cases?
Sales system
ListProducts
OrderProducts
AcceptPayment
CalculateCommission
Purchaser
SalesAgentCustomer
ancestor
or parent
descendents orchildren
generalisation
abstractactor
Use actor generalization when it simplifies
the model
© Clear View Training 2010 v2.6 48
Use case generalisation
 The ancestor use case
must be a more general
case of one or more
descendant use cases
 Child use cases are more
specific forms of their
parent
 They can inherit, add and
override features of their
parent
Sales system
FindProduct
FindBook FindCD
Customer
© Clear View Training 2010 v2.6 49
«include»
 When use cases share
common behaviour we
can factor this out into
a separate inclusion use
case and «include» it in
base use cases
 Base use cases are
not complete without
the included use
cases
 Inclusion use cases may
be complete use cases,
or they may just specify a
fragment of behaviour
for inclusion elsewhere
Personnel System
FindEmployeeDetails
ChangeEmployeeDetails
DeleteEmployeeDetails
Manager
ViewEmployeeDetails
«include»
«include»
«include»
base use case
inclusion
use caseinclude
relationship
BA
«include»
© Clear View Training 2010 v2.6 50
«include» example
Use case:ChangeEmployeeDetails
Primary actors:
Manager
Preconditions:
1.The Manageris logged on to the system.
Postconditions:
1.The employee details have beenchanged.
Main flow:
include(FindEmployeeDetails).
The system displays the employee details.
The Managerchangesthe employee
details.
1.
2.
3.
ID: 1
Brief description:
The Managerchangesthe employee details.
Alternative flows:
None.
Use case:FindEmployeeDetails
Primary actors:
Manager
Preconditions:
1.The Manageris logged on to the system.
Postconditions:
1.The system has found the employeedetails.
Main flow:
The Managerenters the employee'sID.
The system finds the employee details.
1.
2.
ID: 4
Brief description:
The Managerfinds the employee details.
Alternative flows:
None.
Seconday actors:
None
Seconday actors:
None
© Clear View Training 2010 v2.6 51
«extend»
 The extension use case
inserts behaviour into the
base use case.
 The base use case provides
extension points, but does
not know about the
extensions.
 The base use case is
complete already without the
extensions.
 There may be multiple
extension points and multiple
extending use cases.
Library system
IssueFineBorrowBook
FindBook
Librarian
ReturnBook
«extend»
base use case
extend
relationship extension
use case
BA
«extend»
BA
«include»
© Clear View Training 2010 v2.6 52
<<extend>> example
 Extension points are notnumbered,
as they are not part of the flow
Use case: ReturnBook
Secondary actors:
None.
Preconditions:
1. The Librarian is logged on to the system.
Postconditions:
1. The book has been returned.
Main flow:
The Librarian enters the borrower's ID number.
The system displays the borrower's details including the list of
borrowed books.
The Librarian finds the book to be returned in the list of books.
The Librarian returns the book.
…
1.
2.
3.
4.
ID: 9
Brief description:
The Librarian returns a borrowed book.
Alternative flows:
None.
ReturnBook
extension points
overdueBook
IssueFine
«extend»
(overdueBook)
extension point: overdueBook
extension
point
base use case
extension use case
extension
point name
Primary actors:
Librarian
© Clear View Training 2010 v2.6 53
Requirements tracing
There is a many-to-many relationship between
requirements and use cases:
 One use case covers many individual functional
requirements
 One functional requirement may be realised by
many use cases
 Requirements Traceability Matrix can help us
to trace if all requirements are covered by our
use case model
R1
R2
R3
R4
R5
U1 U2 U3 U4
Use cases
Requirements
Requirements
Traceability
Matrix
© Clear View Training 2010 v2.6 54
Key points
 Use cases describe system behaviour from the point of
view of actors. They are the best choice when:
 The system is dominated by functional requirements
 The system has many types of user to which it delivers different
functionality
 The system has many interfaces
 We have discussed:
 Actors, use cases and their textual specification
 Actor and use case generalization
 Advanced relationships between use cases (include, extend)
 Use advanced features only where they simplify the
model!