Requirements Engineering: A Practicum

MB
Full day Tutorial
11/11/2013 8:30 AM

"Requirements Engineering:
A Practicum"
Presented by:
Erik van Veenendaal
Improve IT Services BV

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073
888 268 8770 904 278 0524 sqeinfo@sqe.com www.sqe.com

Erik van Veenendaal
Improve IT Services BV
A leading international consultant, trainer, and recognized expert in
software testing, Erik van Veenendaal (erikvanveenendaal.nl) is the
founder of Improve IT Services BV, a company that specializes in testing,
requirements engineering, and quality management. Erik is the author of a
number of books and papers, one of the core developers of the TMap
testing methodology and the TMMi improvement model, a participant in
working parties of the International Requirements Engineering Board, and
currently on the TMMi Foundation board. He is a frequent speaker at
international testing conferences. For his major contribution to the field of
testing, Erik received the 2007 European Testing Excellence Award.

Requirements Engineering
Quality makes products
which do not return and
customers who do

Erik van Veenendaal
www.erikvanveenendaal.nl

Do not put content
on the brand
signature area

Requirements Engineering: A Practicum
•  08:30 – 09:15 Introduction to Requirements Engineering
09:15 – 10:00 Kick-off Phase
10:00 – 10:15 Requirements Gathering
•  10:30 – 11:15 Requirements Gathering - cont.
11.15 – 12.00 Requirements Specification
•  13.00 – 13.30 Exercise Radio Watch (1)
13.30 – 14.15 Requirements Specification – cont.
14.15 – 14.45 Exercise Radio Watch (2)
•  15:00 – 15:45 Verification and Validation
16.05 – 16.30 IREB, Evaluation and Closure
Improve Quality Services B.V.

2

Do not put content
on the brand
signature area

Learning Objectives
Learning by thinking and doing

!  Understand the importance of requirements
!  Have an overview of requirements engineering
process
!  Learn a structured approach for writing good
requirements in a natural language
!  Provide practical ideas for writing better
requirements
!  Be able to organize and participate in requirements
reviews
!  Note: in Agile requirements come as user stories
Improve Quality Services BV

3

Erik van Veenendaal
www. erikvanveenendaal.nl

!  Founder and major shareholder ImproveQS
!  In testing since 1989 working for many
different clients and in many different roles
!  Author “TMap”, “TMMi”, “ISTQB Foundation”
and many other books and papers
!  Vice-President International Software Testing
Qualifications Board (ISTQB) 2005 - 2008
!  Supporting member IREB board
!  Keynote speaker, e.g., EuroSTAR, STAR
!  Winner of the European Testing Excellence
Award (2007)

4

www. improveqs.nl

! Service organisation in the area of
Testing, Requirements Engineering and
Quality Management
! Consultancy, Subcontracting and Training
Testing (TMap, TMMi)
Agile Testing (CAT)
Test Process Improvement
Certification (ISTQB)
Inspections / Reviews

SW Process Improvement
Quality Level Management
IT-Auditing
Requirements Engineering
& management (IREB)
5

How I got involved?
! Tester:
“Can’t test this, not clear, not unambiguous”
! Requirements engineer:
“What is a good testable requirement?”
! Tester:
“Uuuuhhhh…. SMART”
! Requirements engineer:
“Let’s define ‘what are the requirements for
requirements?’”

6

Understanding Requirements


7

The Challenge
!  To capture the need “completely” and
“unambiguously” without resorting to specialist
jargon, thus understandable by our stakeholders
!  Requirements are the basis for:
- Project (sprint) planning
- Trade-off (priority setting)
- Development
- Acceptance testing


8

Outsourcing !?

Why?

!  Most significant contributors to project failure relate
to requirements (Standish Group CHAOS report)
!  Most frequently named cause of total project failure
was changing requirements (Study Computer Industry
Daily of 500 IT managers USA &UK)

"  Note: Agile much more capable of managing this

!  Requirements Engineering & Management seen as
biggest problem in software development processes
(EU Survey)


9

Project Success Factors….
Reliable Estimates

Formal methodology
Standard software
infrastructure

Executive
support

Minimized scope

6% 5%
10%

8%

12%

18%

16%
Experienced
Project Manager

14%
5%

6%

Clear
business
objectives
User
involvement

Firm basic requirements

Other

Source: “Extreme Chaos” The Standish Group. www.standishgroup.com

10

44%

More facts and figures
Req.

GD

DD

Impl.

Test

Oper.

!  Investing less than 5% in gathering and processing
requirements will lead to budget overruns of
approximately 80% - 200%
!  50% of the defects reported during system and
acceptance testing can be traced to requirements
engineering
!  Requirements defects are the most important
- defects have the characteristic to multiply themselves
top-down
- cost of rework rise (exponentially)

11

Importance of Requirements
Different stakeholders

Different objectives

!  User/Customer

# State their needs

!  Agile Team

# Develop sprint planning

!  Project Manager

# Develop budget/schedule

!  System Engineers

# Develop architecture

!  Testers

# Specify test plan & cases

!  Software Engineers # Define work to be done


12

What is a Requirement?
A requirement is a condition or capability
to which the system must conform
… a capability needed by the user to solve a
problem or achieve an objective
… a capability that must be met or possessed by a
system to satisfy a contract, specification,
standard or other formally imposed
documentation
… a statement of intent that describes something
the system needs to do for some user
.


13

Three Types of Requirements
!  Functional requirements are things the product must do
-The product shall produce an updated schedule

- As a <student>, I want <to be able to buy a parking pass> so I can
<get to school quickly>

!  Non-functional requirements (e.g., ISO9126) are the
properties that the product must have
-  The product shall determine ... in less than 0.25 seconds
-  As a <member of the public> I want <the website to adequately cope
with high loads> so I can <purchase a ticket quickly for a highly
subscribed event>

!  A constraint is a restriction on the scope or design of the
product
- The product shall run on the ... platform

14

A main principle…….
How much documentation is enough?

"  Requirements process is context dependent
!  User requirements – problem domain
- State what the stakeholders want to achieve through
use of the system. Avoid reference to any particular
solution. “The user shall be able to…..”
!  System requirements – solution domain
- State abstractly how the system will meet the
stakeholder requirements. Avoid reference to any
particular design. “The product shall …..”
!  Agile / V-model / Outsourcing
!  Business / Project / Product / Human factors

15

More Definitions….
! Requirements Engineering
- A systematic approach to gathering, organizing,
and documenting the requirements of the system

! Requirements Management
- A process that establishes and maintains
agreement between the customer and the project
on the changing requirements of the system
- Agile: Managing the Backlog by Product Owner

16

Requirements Proces (1)
1 2 3 4 5
1.  Kick-off phase
! 

Objective, scope, stakeholders, business case

! 

Check: Are things clear enough to start?

2.  Requirements gathering (quantity-based)
! 

Functional, Non-functional, Constraints

! 

Various gathering / elicitation techniques

3.  Requirements specification (quality-based)
! 

Templates, Rule set

! 

Multiple levels, level of detail needed


17

Requirements Proces (2)
4.  Verification and Validation

1 2 3 4 5

! 

Checking requirements

! 

Different types (walkthrough, pair-inspection)

! 

Use rules and checklists

5.  Requirements management
! 

Identification and traceability

! 

Use attributes, e.g., source

! 

Change management

! 

Relates to the entire proces


Note, in Agile
this is not a
lineair process

18


19

Kick-off, What is needed?
1.  The purpose of the product
2.  Customers and other stakeholders
3.  Users of the product
4.  Scope of the product (context diagram)
5.  Glossary: naming conventions, abbreviations

and definitions

6.  Relevant facts and assumptions
7.  References


20

The purpose of the product
PRINCE-2 “Business Case”
RuP “Vision document”

!  The user problem (no more than 1 page)
- A short description of the situation that triggered the
development effort
- Describe the work that should be improved

!  Goals of the project
- What will the product do? (purpose)
- What is the business advantage?
- How will you measure the advantage?
- Statement of needs on a high-level

Get stakeholders commitment on this !!
21

Purpose Example (A’dam Metro)
Purpose: To sell metro tickets more
efficiently (faster) than currently.
Rational: To increase sales and reduce
cueing while buying metro tickets.
Acceptance Criteria: The product will
hand out ticket 30% faster than the
current system. This improvement shall
be achieved on all priority 1 stations at
peak hours.

22

Stakeholders
!  A stakeholder is anyone who is interested in the
product
!  Stakeholders may use it, are affected by it, have
specific knowledge on it, or develop the product
" Brainstorm a list of stakeholders
" Document the knowledge area of the
stakeholders (e.g. typical use cases, nonfunctional or other requirements)
" Forgotten stakeholders means forgotten req.’s !!

23

Users of the Product
!  The purpose of identifying the users, so that you
can understand the work that they do
and the product you must build for them
!  For the users, describe all the known and
potential users and their attributes
!  The roles (actors) for the user stories (use cases)
to be defined later
" Forgotten users means forgotten req.’s !!


24

Context of Use
! 

! 

The functionality and usability of a product is
effected by its context of use
Context is characterized by :
- the users of the product
- the tasks they carry out
- the working environment
-…

!  Tool : Context of Use
checklist MuSIC

25

The Scope of the Requirements
!  The context defines the extent of the work
!  … also what is NOT included
!  The context is provided by the services provided
by the work
!  … and the needs of the outside world
!  Defines the scope of the work by showing the
connections to the adjacent systems
!  Includes all desired capabilities


26

At system level
adjacent systems

Context diagram
Adjacent
Process

Adjacent
Process
Work to
be studied
(functionalities
and data)

Adjacent
Process

Services provided
by the product

Needed by the product
to provide the services
27

Naming conventions/definitions
!  Misunderstood terms cause problems
!  Start a list of important terms used by the
stakeholders
!  This will be enlarged and refined later
!  If your terms invoke the right meaning they save
hours of explanation
!  Check for internal and industry-standards
" Later….”Do all terms have a requirement? “

! Improve Quality Services BV

28

At the end of the Kick-off
!  How much do you know?
!  Enough to start gathering the req.’s?
!  Do you have a measurable purpose?
!  Do you know all the stakeholders and users?
!  Is the scope clearly defined?
!  Should you proceed or ask for more and better
information?


29

Discussion Exercise
1.  Become acquainted – introduce yourself
2.  State in keywords the most important
requirements issues in your projects /
organization
3.  How do you start the requirements process
in your organization?
4.  Consider the effect of a poor requirements
“kick-off” – Do you mitigate these risks?


30


31

Kano model: three categories
Not fulfilled

Basic factors

Must-be quality
Performance factors

Fulfilled

Extremely
dissatisfied

Not dissatisfied

Dissatisfied

Satisfied

Not dissatisfied

Extremely
satisfied

Expected quality
Excitement factors

Attractive quality

32

Requirements Gathering (1)
!  Finding conscious, unconscious and subconscious
requirements
!  Approach depends on:
- risk factors
- experience of the req. engineer
- time & budget
- availability stakeholders
-  granularity and the degree of detail needed
-  system context
-  availability of sources, e.g., systems / documentation
-  …

!  All about quantity not quality # building the backlog

33

Requirements Gathering (2)
!  Survey techniques

!  Observation techniques

- Interviews, questionnaires

!  Creativity techniques

−  Apprenticing, field
observation

!  Document-centric
techniques

- Brainstorming, change of
perspective, analogies,
role playing

−  System archaeology,
reuse of requirements

Combining different techniques for the best result …


34

Interview the stakeholders
!  Not the sole technique !!
- Users don’t know all the requirements….

!  Closed questions start with words like Do.. Is..
Can..Could..Will..Would..Shall..
-These usually get yes/no answers

!  Open questions start with words like
How..Why..When..Where..What..Who
- Are more likely to extract information

!  Use answers from one questions to ask a new
one

35

Interview the stakeholders (2)
!  How will you know if you have been successful?
What do you want to achieve?
- Prepare a checklist of topics to be discussed

!  Plan the venue of the interview: ideally the
stakeholder’s workplace
!  Plan the boundary of your interview (and make
this clear at the beginning)
!  Ask yourself: Why should the stakeholder care
about this interview?
!  At the end, of course, thank the stakeholder and
tell what you will do with the information….

36

Interview Process
People factors
are critical !!

1.  Getting acquainted
2.  Explain rules
3.  Gather requirements
- check your observations
- record draft requirements

4.  Summary
“have I missed anything?”

5.  Closure
“what can I do better next time?”

37

Questionnaire NF-requirements
!  In stakeholders’ (users’) language
!  Business characteristics
- objectives, process, users, software product
- two versions: information systems and technical
automation, e.g. embedded

!  Interview with various stakeholders
-1 hour per interview

!  Answers linked to quality attributes
- two dimensional matrices
-  business characteristics versus ISO 9126

!  Note NF-requirements are often on a system level

38

Examples Checklist Items
note, rationale becomes clear as well

!  Objectives
- Higher level of efficiency / productivity
  req.’s on usability and time-behaviour
- Continuity of information services
  req.’s on maintainability and portability

!  Business process
- Primary process with a high risk level
  req.’s on reliability
- Very dynamic process; the process has interrelationships with a
great number of other processes (complex)
  req.’s on maintainability and usability

39

Brainstorming
!  Requirements gathering is invention
!  Objective of brainstorming is to be as imaginative
as possible, and so generate as many ideas as
possible
!  List, discuss and group the ideas
- Initially five items and then discuss, next round …

!  Check the ideas with the project scope
!  Later turn them into requirements
!  Think about a facilitator

40

Brainstorming: simple rules
!  Wide range of disciplines and experience
!  Start with a well-defined, open ended statement of
the problem (e.g. context diagram)
!  Write every idea down (a piece of paper is never
big enough!), without censoring: any idea is a
good one!
!  Define subgroups to elaborate on a type or
functionality
!  Suspend judgment and evaluation
!  Piggyback on each others’ ideas
!  Use a separate section for project issues & design

41

Study the current situation
!  Understanding what we seek to change
!  Current system contains many of the needed
requirements (abstract from technology)
- Often implicit requirements
!  Ask “What is right with this system?”
!  Draw a model of the current system
!  Also include system from competitors
!  Practice apprenticing “Nobody can talk better
about what they do, and why they do it, than they
can while in the middle of doing it”

42

Supporting Tools
! Mind mapping
! Prototyping
! Use Case Workshops
! Etc.


43

Mind maps

www.visual-mind.com
www.freemind.com

!  Mind maps to explore ideas
!  Useful devices to organize your thoughts
!  You see the links between the various aspects of
the product that have been told about
!  Useful during interviewing users /stakeholders
and brainstorming
!  Improve sharing of thoughts and knowledge
!  Some use class diagrams as a basic structure

44

Prototypes
!  For information gathering
!  Some requirements are not obvious, or are not
fully elaborated yet
!  Some users have trouble articulating their desires
!  Give users the opportunity to use the requirements
!  Restrict the prototypes to most common tasks
!  Focus on the product, not the prototype
“The truth is almost never in the words”

45

Especially useful when ..
!  The product did not exist before
!  The users have no experience with the kind of
product
!  The users are stuck in the current way of working
!  The users have trouble stating their req.’s
!  The requirements analyst / developer has trouble
understanding what is required
" Low-fidelity vs. High-fidelity prototypes
46

Use Case Workshops / EPIC
Describing the bigger picture

!  Start with the context diagram
!  Use cases give users a convenient way to
partition the product
!  Describes the bigger picture
!  One or more use cases per business event
•  also consider ‘misuse cases’, e.g., for security req.

!  Six step scenario’s are a great starting point
•  Name

- Actor (user)

•  Short description (‘happy day scenario’)
•  Pre conditions

- Post conditions
47

Use Cases

use case

req.

! 

Use case: sequence of transactions in a dialogue
between a user and the product with a specified result

! 

EPIC: a large story that requires some level of
breakdown into smaller stories in order for the work to
be consumed in a single iteration.

! 

The use cases contain functional (and non-functional)
requirements
-  The requirements make up the work done by the use
case

!  Start by identifying the use case per business event
and actor

48

Hierarchy and Traceability

Context
diagram
Use
cases

Req.’s


EPICs

User
stories

Req.’s

User
stories

49

Use Case Example (A’dam Metro)
Use Case: Traveller buying a ticket.
Actor: Traveller
1.  The traveller offers destination, type of
ticket and payment to the product
2.  The product checks whether the payment
is ok for the chose n destination and type
of tickert
3.  The product checks whether the network
is operational for the chosen destination.
4.  The product submits ticket and if
necessary change.
5.  The product stores the transaction

50

Requirements Example (A’dam Metro)
Use Case step 2.: The product checks
whether the payment is ok for the chosen
destination and type of ticket
Requirements:
2.1 The product shall establish that the
payment consists of legally valid money .
2.2 The product shall calcuate the lowest
fare for the destination considering day of
week and time
2.3 The prodyct shall compare the travellers’
payment with the calculated payment
2.4 The product shall provide feedback in
case the payment is not sufficient.

51

SWOT analysis Techniques & Tools
Instruction:
Choose two elicitation techniques (or tool)
-  As a team what do you consider to be strong
points / selling items of that technique?
"  When to use!

-  And what do you consider to be problems / draw
backs / weaknesses of that technique?
"  When hard (or not) to use!


52


53

What is needed ….
!  If we could look into each others brains, we
wouldn’t need documentation …
!  Documentation helps us to communicate
Sender
Encodes

Message
Joint code

Receiver
Decodes

!  Be careful, words may not be enough!
- Formal / informal language
- Different interpretations

54

"I didn't say he killed his wife“
"I didn't say he killed his wife"

55

What are “good” requirements?
Identify at least five “rules” that determine
whether a requirement is a good
(or “poor”) requirement
Consider !!
!  Individual requirements
!  Requirements attributes


56

What is a good requirement?


57

Excercise Radio Watch (1)
•  Study the requirement specification for the
new Radio Watch
•  Make comments (find defects) based on
what you have learned so far
e.g., attributes, rules, guidelines….

+

58

Requirements cards
Requirement # :
Requirement Type :
Description :

Priority :
Use case :

Rationale :
Source :
Acceptance Criteria :

Size :
Supporting material : …annotation, conversation…

59

Requirements attributes (1)
! ID
- To allow traceability

! Requirements Type
- Allows req.’s to be sorted, grouping allows the requirements to be

checked on completeness and for conflicts, e.g., by non-functional,
by business process

! Use case
- For traceability and change control purposes

- Again for grouping etc.

! Description
- The intent of the requirement (may initially be ambiguous) - the

stakeholders’ whishes & needs


60

Requirements attributes (2)
!  Rationale
- Reason behind the requirement’s existence. Helps to clarify and

understand the requirement and to identify ‘gold plating’ req.’s.

!  Priority
-  Measure of the business value and importance. For negotiation,
but also for risk-based testing

!  Acceptance criteria
- To make the requirement measurable and testable

!  Source
- Name of the person who raised the requirement , or document.

!  Size
- Number of story points

61

Gold plating …..

“Well, we might as well put it on board – although I’m not sure what use
we’ll have for a box of rusty nails,62broken glas, and throwing darts.”


Acceptance Criteria
involve tester here

!  We have to be able to tell whether a solution
completely satisfies, or fits, a requirement
!  To make requirements measurable
!  In practice very important for non-functional
requirements
!  It is usually necessary to negotiate acceptance
criteria with the stakeholder, e.g.,
•  90% of the customers must be able to get the correct ticket from the
product in no more than 25 seconds


63

Example Acceptance Criteria
Requirement / User Story
- As a student, I want to be able to buy a parking pass so I
can get to school quickly
Acceptance Criteria
-  The student will not receive the parking pass if the
payment is insufficient
-  One can only buy a parking pass to the school parking lot
if the person is a registered student
-  The student can only buy one parking pass per month
-  …..

64

Writing Guidelines
To write simple is as difficult as to be good

!  Short and concise sentences and paragraphs
!  One requirement per sentence
- no compound requirements, a single verb

!  Consistent terminology (homonyms)
!  Avoid generalizations
!  Use ‘must’, ‘can’ and similar words carefully
- ‘shall’ is better, ‘can’ indicates options

!  No solutions or design
!  Directive language
!  No pronouns

65

Use Templates
www.requirementsengineering.info

!  The <stakeholder> shall be able to <capability>
-  The order clerk shall be able to raise an invoice

!  As a <role>, I want <activity> so that <business value>
- As a job seeker, I want to search for a job, so I can
advance my career

!  The <product> shall be able to <action> <entity>
- The launcher shall be able to launch missiles

!  The <product> shall <function> <object> every
<performance> <unit>
- The coffee machine shall produce a hot drink every 10
seconds

66

Requirements Rule Set
•  Usefull set of agreements
•  Specify the contents and format
of a requirement (and requirements
document)
•  More objective, less discussion
•  Applied during specification and reviewing
•  Organization specific
•  Rules for tracing, format and content

67

Examples of Rules (1)
!  Identification
!  Valuable / purpose
All forms of annotation, comments,
notes, suggestions, examples, or
!  Changes
other items not part of the formal
!  Grouping
requirement shall be clearly
indicated as such. This will be
!  Uniqueness
documented by using the attribute
!  Consistency
‘additional information’.
!  Annotation
!  Language
!  Knowledge responsible (source)

68

Examples of Rules (2)
!  Detail
!  Brief / Small
!  Unambiguous
!  Priority
!  Rationale
!  Compound
!  Independent

Req.’s shall be unambiguous to the
intended readership. Req.’s shall have
only one interpretation. For example the
word shall is used and not the word
should. Words like can shall only be used
when more than one option is available.
Directive language (active voice) shall be
used, e.g., specifies and not can specify.

!  Technically achievable
!  Testable

69

Interpretation: Unambiguous
!  To be part of the backlog
- The requirements shall be at the level of
unambiguousness to allow product team level decisions
to be taken.

!  To be part of the sprint planning
- The requirements shall be at the level of
unambiguousness to allow for estimation in terms of
effort and time.

!  To be part of the sprint
- The requirements shall provide enough information to
allow for the execution of individual deliverables and
tasks (e.g., detailed design, test design).

70

•  Select the rules that you will adhere too, and
attributes that you will use
•  Select a description template
•  Rewrite some of the requirements for the new
Radio Watch
•  Make concrete improvement suggestions
•  Watch out for fuzzy terms
•  Use the requirements card

71

Fuzzy Terms List
Mostly
Might
Appropriate
Graceful
Major
May be of use to
And/or
Various
Interface

As needed
Make sense
Might make sense
At minimum
Slowly
Including but not limited
Suitable
Clean and stable
Several
72

Prioritizing Requirements
!  Use the priority (business value) attribute
!  If this fails, sort the requirements / use cases
using (MoSCoW):
- Must have in next sprint
- Should have in next sprint
- Could have in next sprint
- Would like if possible
!  Prioritize “Should have” & “Could have” categories
!  Usually highly subjective and many discussions

73

Priority Factors from Practice
!  Selling item (marketing)
Customization
needed

!  Usage intensity
!  Business objectives
!  Customer value

Weightings
can be applied

!  Ease of implementation
!  Cost of implementation
!  Time-to-market

PRISMA®

!  Competition
!  External visibility

74

Stakeholders Involvement
!  Identify stakeholders (internal and external)
- product owner, end-user, business mgr., marketing,
service department, help-desk, accountant, etc.

!  Ask them to fill in the priority table
- “1 to 5” scale or “0 to 9” for more differentiation

!  Their views will differ
!  Note, this may change as the project progresses


75

Stakeholders Involvement (2)
9 : Critical
5 : High
3 : Moderate
1 : Low
0 : None

" Individual scoring
Selling
item
5

Item 2

4
5

Item 3

5
4
2
5

Item 5

Item 1

Item 4

they shall
make
choices

1
4
76

Usage ……
intensity

Consensus Meeting
!  Discuss issue list - first defects found !!
!  Result may influence development & test approach
Impact
Selling Item

Usage intensity

…

Priority Number

Item 1

5

4

1

10

Item 2

3

3

1

7

Item n

77

Achieving Consensus ….
decide / announce before the meeting

! Talking it out
! Use the highest rating
! Use the average rating
! Use the most applied rating
! Defer to one of the team members
- Let the “owner” decide

! Team voting
! Get an experts’ opinion

78

Or Play the Card Game
!  Poker Planning based …..

'Risk management in agile projects: the PRISMA approach‘
in: Professional Tester (June 2012)
downloadable from www.erikvanveenendaal.nl

79

The User Story Matrix
X

X
X

X

X

(Story

X

Size
Points)

X
Relative Business Value
80

X


Requirements Two Aspects
!  Needs to be readable
- The structure of the document, how it is organised and
how the flow supports the reader to place individual
requirements in context

!  Needs to be processable
- Qualities of individual requirements, clarity and
preciseness and how they are divided into single
traceable items
-  Word doesn’t provide attributes, identifiers etc. tools do
-  www.methods-tools.com / www.volere.co.uk/tools.htm

81

Readability: The Req.’s document
!  Three main sections

Putting together
what we have
gathered so far

- Introduction
- Overall description
•  Constraints

- Specific requirements
•  Functional requirements (grouped)
•  Non-functional requirements

!  Useful Templates - help to identify missing req.’s
- Volere (www.systemsguild.com) – business level
- IEEE 830 Software Requirements Specification

82


83

Core Agile Practice : Reviews
Communication & Feedback
Customer collaboration
!  Walkthrough / Pair Inspection /
Informal Reviews
!  Priority to the profitable
!  Apply review practices that
make the difference

84

Why Verification and Validation?
! Efficient and effective way to find defects
-

ambiguous, consistency, completeness, compound, ...

! Many defects have already been made
before design has started
-

50% “requirements related”

! Early defects are highly important
-

defects have the characteristic to multiply
themselves top-down

- cost of rework rises (exponentially)
Req.


Design

Coding

Testing

85

Requirements reviews - types
! Walkthrough (with stakeholders)

Validation

- product owner will guide the group through the
requirements
- common understanding, knowledge sharing,
consensus

! Inspection (with fellow engineers)
- formal check against rules
- individual process to find defects
- using checklists

86

Verification

Processing Requirements
information gathering
communication
consensus
approval

Walkthrough

Requirements
gathering

Use cases
Brainstorm
Interviewing
Mind mapping

Inspection

Requirements
(user stories)


87

Review Process Overview
Kick-Off

Planning

Preparation

Meeting


Rework

88

Exit

Walkthrough
•  Planning (scrum master): no formal entry criteria
•  Preparation (reading): preparing questions
•  Kick-off at the beginning of the meeting: objective
•  Meeting: author provides explanation
(e.g., scenario’s, prototypes, use cases)
•  Scribe to records findings
•  Scrum master manages the process (chair)

•  Rework/exit: not formal, author continues the work

89

User Scenarios
! A scenario is a story that illustrates the
action that the product will take for a specific
case
! A scenario might be the generic ‘normal
case’ story, or it would tell a specific story
! Think of “what if scenarios” !!
! Deals with one (or part of an) event / use
case
! Used to discover missing requirements !!

90

Pair Inspection
•  Planning/Kick-off: requirements, rules, objective
•  Preparation: individual, checking not reading
•  Meeting: defects explained, discussion,
logging? improvement suggestions?
•  Rework: by author, log as a ‘checklist’
•  Follow-up/Exit: check updated requirements
- 1 in10 defects is not addressed is correctly
(Source: Les Hatton)


91

Check for Conflicts
•  Look for pairs of requirements that are in
conflict with each other
•  Look at existence dependent requirements,
e.g., one product data that the other needs
•  Do any requirements cover the same
subject?
•  Is every use of terminology consistent with
conventions and definitions?
•  Real conflicts identify negotiation points

92

Checklist vs. Rules
! Derived from rules - objectives
! Most frequent / important defects
! One page
! Dynamic document, not static
! Question form, “NO” means a defect
! Shall be company specific


93

Juran’s F-Test “The Game Rules”
!  Close your slide copies now!
!  No questions! No discussion. Make your best interpretation of the
following rule :
No instances of “F” allowed on the screen.
Standard applies to any type of “F”, so count
even “derivates” (example “f” and “F”)
!  Count all defects for standard F
!  Write down your count of “defects” when the time is up
!  You may move to any position in the room to see better
!  Do not interfere with the view of others
!  You will get 2 minutes to check

94

Juran's “F” Test
"FEDERAL FUSES ARE THE RESULTS OF 75 YEARS OF
SCIENTIFIC STUDY COMBINED WITH THE EXPERIENCE OF 14
YEARS."

How many letter F's can you find on
this page?
Write the number down in this box


95

Checklist for “F” searching
F1. Do you find the word “OF”?
F2. Do you find large graphic patterns resembling F ?
F3. Did you turn images backwards and all angles?
F4. Did you find all numbers and shapes pronounced “F”
for example 14, 75 and “frames”?
F5.Check “f” sound in apostrophe and hyphen
F6. Did you see the upside-down, backwards letter “t” (= “f”)?
F7. ……...


96

! You have found defects in the requirements for
the new radio watch and you have re-written
some of them.
! Assignment: As a team, review the
requirements of your colleagues against the
rules (!!) and provide recommendations for
improvement
! “Good enough”?!


97


98

IREB e.V.
www.certified-re.de

International Requirements Engineering Board
!  A non-profit organization
!  Board members are international recognized
experts, e.g., Suzanne Robertson, Chris Rupp
!  Erik van Veenendaal active as a supporting
member
!  Goal: to improve practices in requirements
engineering and requirements management
!  Based on SWEBOK, ISTQB, IPMA, IEEE
!  iSQI active as examination body

99

IREB Foundation
!  IREB Foundation Syllabus
!  Defined Educational Objectives and
Levels of Knowledge
!  Three day training course
!  75 minutes exam, 45 questions
- Questions vary in difficulty and different (indicated)
marking accordingly
- At least 60% of possible score needed to pass
-  E-based exam also possible

!  Advanced syllabi also recently became available

100

IREB activities (Status 01-01-2013)
Finland

Sweden

United Kingdom

Denmark
USA

Hungary
South Korea

Bulgaria

Switzerland

Israel

Spain
Venezuela

Russia

Germany

The Netherlands

China

India

Austria

Malaysia

Ecuador
Sudan

Columbia

Egypt

Singapore
Australia

Brazil
South africa
New Zealand

101

Things to do tomorrow
From previous groups
!  Introduce requirements attributes (cards)
!  Add rationale early
!  Write use cases/EPIC’s and add requirements
!  Use multiple gathering techniques
!  Write requirements, not (technical) solution
!  Define and use requirements rules
!  Use templates
!  Introduce practical reviews
!  Get the whole team involved

102

Any questions.....?

Thank you !!

103

Requirements Engineering: A Practicum

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (18)

Semelhante a Requirements Engineering: A Practicum

Semelhante a Requirements Engineering: A Practicum (20)

Mais de TechWell

Mais de TechWell (20)

Último

Último (20)

Requirements Engineering: A Practicum