Questions

Requirements Engineering •  Why does prototyping fall between waterfall and

agile?
•  What is the process model of the Software
Engineering Projects?
Mark van den Brand •  Does an agile process model deliver maintainable
Tom Verhoeff software? Give a couple of (motivated) arguments.

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 1

Requirements Engineering Domain Analysis

•  The process by which a software engineer learns

about the domain to better understand the problem:
•  The domain is the general field of business or
technology in which the clients will use the software
•  A domain expert is a person who has a deep
knowledge of the domain

•  Benefits of performing domain analysis:

•  Faster development
•  Better system
•  Anticipation of extensions

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 2 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 3
 Domain analysis Domain analysis

Domain analysis document: Example document:

http://www.site.uottawa.ca/~laganier/seg3700/cemdomain.htm
A. Introduction
B. Glossary
C. General knowledge about the domain
D. Customers and users
E. The environment
F. Tasks and procedures currently performed
G. Competing software
H. Similarities to other domains

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 4 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 5

Starting Point for Software Projects Defining Problem and Scope

•  A problem can be expressed as:

Requirements Clients have produced •  A difficulty the users or customers are facing,
must be determined requirements •  Or as an opportunity that will result in some benefit
such as improved productivity or sales.
New
development A B
green field project! •  The solution to the problem normally will entail
developing software
Evolution of
existing system C D
•  A good problem statement is short and succinct

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 6 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 7
 Defining the Scope Processes in requirements engineering

•  Narrow the scope by defining a more precise •  Requirements elicitation

problem •  Requirements specification
•  List all the things you might imagine the system doing •  Requirements validation and verification
−  Exclude some of these things if too broad •  Requirements negotiation
−  Determine high-level goals if too narrow
Specification
•  Example: A university registration system
Initial list of problems Narrowed Scope of
with very broad scope scope another system
Documentation &
Elicitation Validation
Management
browsing courses browsing courses
room allocation room allocation
registering registering
exam scheduling exam scheduling
fee payment fee payment Negotiation

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 8 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 9

What is a Requirement ? Types of Requirements

•  It is a statement describing either •  Functional requirements

•  1) an aspect of what the proposed system must do, •  Describe what the system should do
•  or 2) a constraint on the system’s development. •  Quality requirements
•  In either case it must contribute in some way towards •  Constraints on the design to meet specified levels of
adequately solving the customer’s problem; quality
•  the set of requirements as a whole represents a •  Platform requirements
negotiated agreement among the stakeholders. •  Constraints on the environment and technology of the
system
•  Process requirements
•  A collection of requirements is a requirements •  Constraints on the project plan and development
document. methods

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 10 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 11
 Functional Requirements Quality Requirements

•  What inputs the system should accept •  All must be verifiable

•  Examples: Constraints on
•  What outputs the system should produce •  Response time
•  Throughput
•  What data the system should store that other •  Resource usage
systems might use •  Reliability
•  Availability
•  What computations the system should perform
•  Recovery from failure
•  Allowances for maintainability and enhancement
•  The timing and synchronization of the above
•  Allowances for reusability

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 12 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 13

Vragen Conceptual modeling

•  Why is domain analysis crucial for good •  You model part of reality: the Universe of Discourse (UoD)
requirements?
•  Why is scoping important in problem definition? •  This model is an explicit conceptual model

•  What is the difference between functional and non-

•  People in the UoD have an implicit conceptual model of that
functional requirements? UoD
•  What is the relation between requirements and
testing? •  Making this implicit model explicit poses problems:
•  analysis problems
•  negotiation problems

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 14 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 15
 Conceptual modeling Conceptual modeling

•  Requirements engineering is difficult •  Beware of subtle mismatches:

•  Success depends on the degree with which we •  a library employee may also be a client
manage to properly describe the system desired •  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, ...

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 16 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 17

Conceptual modeling Conceptual modeling

•  Humans as sources of information: •  How we study the world around us:

•  people have a set of assumptions about a topic they study
(paradigm)
•  different backgrounds
•  this set of assumptions concerns:
−  how knowledge is gathered
•  short-term vs long-term memory
−  how the world is organized
•  this in turn results in two dimensions:
•  human prejudices
−  subjective-objective (wrt knowledge)
−  conflict-order (wrt the world)
•  limited capability for rational thinking •  which results in 4 archetypical approaches to requirements
engineering

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 18 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 19
 Conceptual modeling Elicitation techniques

•  Four approaches to RE: •  Asking: •  Others:

•  functional (objective+order): the analyst is the expert •  interview •  analysis of natural
who empirically seeks the truth •  Delphi technique language descriptions
•  social-relativism (subjective+order): the analyst is a •  brainstorming session •  domain analysis
`change agent’. RE is a learning process guided by the •  Observing •  Business Process
analyst Redesign (BPR)
•  task analysis
•  prototyping
•  radical-structuralism (objective+ conflict): there is a •  scenario analysis
struggle between classes; the analyst chooses for •  ethnography
either party •  form analysis
•  neohumanism (subjective+conflict): the analyst is kind •  synthesis from existing
of a social therapist, bringing parties together system

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 20 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 21

Interviewing Brainstorming

•  Conduct a series of interviews •  Appoint an experienced moderator

•  Ask about specific details •  Arrange the attendees around a table
•  Ask about the stakeholder’s vision for the future •  Decide on a ‘trigger question’
•  Ask if they have alternative ideas •  Ask each participant to write an answer and pass
•  Ask for other sources of information the paper to its neighbour
•  Ask them to draw diagrams ! !

! !
!

•  Joint Application Development (JAD) is a technique based on

intensive brainstorming sessions

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 22 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 23
 Observation Task Analysis

•  Read documents and discuss requirements with •  Task analysis is the process of analyzing the way
users people perform their jobs: the things they do, the
•  Shadowing important potential users as they do things they act on and the things they need to know.
their work •  The relation between tasks and goals: a task is
•  ask the user to explain everything he or she is doing performed in order to achieve a goal.
•  Session video taping •  Task analysis has a broad scope.

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 24 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 25

Task Analysis Scenario-Based Analysis

•  Task analysis concentrates on the current situation. •  Provides a more user-oriented view perspective on
However, it can be used as a starting point for a new the design and development of an interactive
system: system.
•  users will refer to new elements of a system and its •  The defining property of a scenario is that it projects
functionality a concrete description of an activity that the user
•  scenario-based analysis can be used to exploit new engages in when performing a specific task, a
possibilities description sufficiently detailed so that the design
implications can be inferred and reasoned about.

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 26 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 27
 Scenario-Based Analysis (example) Scenario-Based Analysis

•  first shot:
•  check due back date Scenario view Standard view
•  if overdue, collect fine •  concrete descriptions •  abstract descriptions
•  record book as being available again •  focus on particular instances •  focus on generic types
•  put book back •  work-driven •  technology-driven
•  open-ended, fragmentary •  complete, exhaustive
•  as a result of discussion with library employee: •  informal, rough, colloquial •  formal, rigorous
•  what if person returning the book is not registered as a client? •  envisioned outcomes •  specified outcomes
•  what if the book is damaged?
•  how to handle in case the client has other books that are overdue,
and/or an outstanding reservation?

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 28 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 29

Form analysis Prototyping

Proceedings request form: •  The simplest kind: paper prototype.

Client name …………… •  a set of pictures of the system that are shown to users
Title …………… in sequence to explain what would happen

Editor …………… •  The most common: a mock-up of the system’s UI

•  Written in a rapid prototyping language
Place ……………
•  Does not normally perform any computations, access
Publisher …………… any databases or interact with any other systems
Year …………… •  May prototype a particular aspect of the system

Certainty vs uncertainty

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 30 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 31
 Questions Use case analysis

•  Which problems can arise when making explicit the •  Determine the classes of users that will use the
implicit model in conceptual modeling? facilities of this system (actors)
•  What is the purpose of requirements elicitation? •  Determine the tasks that each actor will need to do
•  Name a number of elicitation techniques? with the system

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 32 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 33

Use-Cases: describing how the user will

Use cases
use the system

•  A use case is a typical sequence of actions that a •  A use case should

user performs in order to complete a given task •  Cover the full sequence of steps from the beginning of
•  The objective of use case analysis is to model the a task until the end.
system from the point of view of •  Describe the user’s interaction with the system ...
… how users interact with this system −  Not the computations the system performs.
… when trying to achieve their objectives. •  Be written so as to be as independent as possible from
It is one of the key activities in requirements analysis any particular user interface design.
•  A use case model consists of •  Only include actions in which the actor interacts with
−  a set of use cases the computer.
−  an optional description or diagram indicating how −  Not actions a user does manually
they are related

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 34 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 35
 Scenarios How to describe a single use case
A.  Name: Give a short, descriptive name to the use case.
•  A scenario is an instance of a use case B.  Actors: List the actors who can perform this use case.
•  A specific occurrence of the use case C.  Goals: Explain what the actor or actors are trying to achieve.
−  a specific actor ... D.  Preconditions: State of the system before the use case.
−  at a specific time ... E.  Summary: Give a short informal description.
−  with specific data. F.  Related use cases.
G.  Steps: Describe each step using a 2-column format.
H.  Postconditions: State of the system in following completion.

•  A and G are the most important

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 36 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 37

The modeling processes: Choosing use

Use case diagrams
cases on which to focus

Register in Course •  Often one use case (or a very small number) can be
Add Course Offer ing identified as central to the system
•  The entire system can be built around this particular
use case
Registr ar Actor Add Course
•  There are other reasons for focusing on particular
Enter Grade
for Cour se use cases:
Student
•  Some use cases will represent a high risk because for
some reason their implementation is problematic
Find information about course •  Some use cases will have high political or commercial
value
Pr ofessor Actor

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 38 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 39
 The benefits of basing software Use cases must not be seen as a
development on use cases panacea

•  They can •  The use cases themselves must be validated

•  Help to define the scope of the system •  Using the requirements validation methods.

•  Be used to plan the development process •  Some aspects of software are not covered by use
case analysis.
•  Be used to both develop and validate the requirements
•  Innovative solutions may not be considered.
•  Form the basis for the definition of test cases

•  Be used to structure user manuals

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 40 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 41

Requirement documents Requirement documents

•  An informal outline of the requirements using a few •  Level of required detail

paragraphs or simple diagrams •  The size of the system
•  requirements definition •  The need to interface to other systems
•  A long list of specifications that contain thousands •  The readership
of pages of intricate detail •  The stage in requirements gathering
•  requirements specification •  The level of experience with the domain and the
technology
•  Requirements documents for large systems are •  The cost that would be incurred if the requirements
normally arranged in a hierarchy were faulty

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 42 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 43
 Prioritizing requirements (MoSCoW) Prioritizing requirements (Kano model)

•  Must haves: top priority requirements •  Attractive: more satisfied if +, not less satisfied if –
•  Must-be: dissatisfied when -, at most neutral
•  Should haves: highly desirable •  One-dimensional: satisfaction proportional to
number
•  Could haves: if time allows •  Indifferent: don’t care
•  Reverse: opposite of what analyst thought
•  Won’t haves: not today •  Questionable: preferences not clear

One dimensional

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 44 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 45

Kano model Requirements specification

•  readable
•  understandable
•  non-ambiguous
•  complete
•  verifiable
•  consistent
•  modifiable
•  traceable
•  usable
•  …

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 46 / Faculteit Wiskunde en Informatica 03-05-12 PAGE 47
 IEEE Standard 830 IEEE Standard 830 (cntd)

1. Introduction 2. General description 3. Specific requirements 3.2. Functional requirements

3.1. External interface 3.2.1. User class 1
1.1. Purpose 2.1. Product perspective requirements 3.2.1.1. Functional req. 1.1
1.2. Scope 2.2. Product functions 3.1.1. User interfaces 3.2.1.2. Functional req. 1.2
1.3. Definitions, acronyms and 2.3. User characteristics 3.1.2. Hardware interfaces ...
abbreviations 2.4. Constraints 3.1.3. Software interfaces 3.2.2. User class 2
3.1.4. Comm. interfaces …
1.4. References 2.5. Assumptions and
3.3. Performance requirements
1.5. Overview dependencies
3.4. Design constraints
3. Specific requirements 3.5. Software system attributes
3.6. Other requirements

SE, Requirements Engineering, Hans van Vliet, ©2007 48 SE, Requirements Engineering, Hans van Vliet, ©2007 49

Requirements management Requirements management

•  Requirements identification (number, goal-hierarchy

too early numbering, version information, attributes)
freeze
•  Requirements change management (CM)
•  Requirements traceability:
requirements stability

•  Where is requirement implemented?

•  Do we need this requirement?
•  Are all requirements linked to solution elements?
requirements •  What is the impact of this requirement?
creep
•  Which requirement does this test case cover?
•  Related to Design Space Analysis
time

SE, Requirements Engineering, Hans van Vliet, ©2007 50 SE, Requirements Engineering, Hans van Vliet, ©2007 51
 Functional vs. Non-Functional
The 7 sins of the analyst
Requirements

•  functional requirements: the system services which

•  noise are expected by the users of the system.
•  silence •  non-functional (quality) requirements: the set of
•  overspecification constraints the system must satisfy and the
standards which must be met by the delivered
•  contradictions system.
•  ambiguity •  speed
•  forward references •  size
•  wishful thinking •  ease-of-use
•  reliability
•  robustness
•  portability
SE, Requirements Engineering, Hans van Vliet, ©2007 52 SE, Requirements Engineering, Hans van Vliet, ©2007 53

Reviewing requirements Validation of requirements

•  Each individual requirement should •  Inspection of the requirement specification w.r.t.

−  Have benefits that outweigh the costs of development correctness, completeness, consistency, accuracy,
−  Be important for the solution of the current problem readability, and testability.
−  Be expressed using a clear and consistent notation •  Some aids:
−  Be unambiguous
•  structured walkthroughs
−  Be logically consistent
•  prototypes
−  Lead to a system of sufficient quality
−  Be realistic with available resources •  simulation
−  Be verifiable •  use cases and scenarios analysis
−  Be uniquely identifiable •  develop a test plan
−  Does not over-constrain the design of the system •  tool support for formal specifications

/ Faculteit Wiskunde en Informatica 03-05-12 PAGE 54 SE, Requirements Engineering, Hans van Vliet, ©2007 55
 Requirements Review Checklist
Requirements Review Checklist
(continued)
1. Does the (software) product have a succinct name, and a clearly 8.  Are all unstable requirements marked as such? (TBC=`To Be Confirmed',
TBD=`To Be Defined')
described purpose? 9.  Is each requirement verifiable (in a provisional acceptance test)?
2. Are the characteristics of users and of typical usage mentioned? (No (Measurable: where possible, quantify; capacity, performance, accuracy)
user categories missing.) 10. Are the requirements consistent? (Non-conflicting.)
11. Are the requirements sufficiently precise and unambiguous? (Which
3. Are all external interfaces of the software explicitly mentioned? (No interfaces are involved, who has the initiative, who supplies what data, no
interfaces missing.) passive voice.)
4. Does each specific requirement have a unique identifier? 12. Are the requirements complete? Can everything not explicitly constrained
indeed be viewed as developer freedom? Is a product that satisfies every
5. Is each requirement atomic and simply formulated? (Typically a requirement indeed acceptable? (No requirements missing.)
single sentence. Composite requirements must be split.) 13. Are the requirements understandable to those who will need to work with
them later?
6. Are requirements organized into coherent groups? (If necessary, 14. Are the requirements realizable within budget?
hierarchical; not more than about ten per group.) 15. Do the requirements express actual customer needs (in the language of the
problem domain), rather than solutions (in developer jargon)?
7. Is each requirement prioritized? (Is the meaning of the priority levels
clear?)

Chapter 4: Chapter 4:
© Lethbridge/Laganière 2005 56 Developing © Lethbridge/Laganière 2005 57 Developing
requirements requirements

Requirements documents... Requirements document...

•  The document should be: A. Problem

−  sufficiently complete B. Background information
−  well organized C. Environment and system models
−  clear D. Functional Requirements
−  agreed to by all the stakeholders E.Non-functional requirements

•  Traceability:
Re quirements
document
rationale Design
1.1 XXXX
document
.... bec ause
1.2 YYYY
....due to
requirement 1.2

Chapter 4: Chapter 4:
© Lethbridge/Laganière 2005 58 Developing © Lethbridge/Laganière 2005 59 Developing
requirements requirements
 Managing Changing Requirements
•  Requirements change because:
•  Business process changes
•  Technology changes
•  The problem becomes better understood

•  Requirements analysis never stops

•  Continue to interact with the clients and users
•  The benefits of changes must outweigh the costs.
−  Certain small changes (e.g. look and feel of the UI) are
usually quick and easy to make at relatively little cost.
−  Larger-scale changes have to be carefully assessed
−  Forcing unexpected changes into a partially built system
will probably result in a poor design and late delivery
•  Some changes are enhancements in disguise
−  Avoid making the system bigger, only make it better

Chapter 4:
© Lethbridge/Laganière 2005 60 Developing
requirements