requirements engineering: a practicum

MC Full‐day Tutorial 6/3/2013 8:30 AM

"Requirements Engineering: A Practicum"

Presented by:

Erik van Veenendaal Improve Quality Services BV

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com

Erik van Veenendaal Improve Quality Services BV

A leading international consultant, trainer, and recognized expert in software testing, Erik van Veenendaal (erikvanveenendaal.nl) is the founder of Improve Quality Services BV, a company that specializes in testing, requirements engineering, and quality management. He is the author of a number of books and papers, one of the core developers of the TMap testing methodology, the TMMi improvement model, a participant in working parties of the International Requirements Engineering Board, and currently on the TMMi Foundation board. Erik 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.

R i t E i iR i t E i iRequirements EngineeringRequirements EngineeringQuality makes products

which do not return and

customers who do

Erik van Veenendaalwww.erikvanveenendaal.nl

Requirements Engineering: A Practicum

• 08:30 – 09:15 Introduction to Requirements Engineering09:15 – 10:00 Kick-off Phase10:00 10:15 Requirements Gathering10: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 E ercise Radio Watch (2)14.15 – 14.45 Exercise Radio Watch (2)

• 15:00 – 15:45 Verification and Validation 15.45 – 16.05 Exercise Radio Watch (3)16.05 – 16.30 IREB, Evaluation and Closure

Improve Quality Services B.V. 2

Learning Objectives

Understand the importance of requirementsHave an overview of requirements engineering

Learning by thinking and doing

Have an overview of requirements engineering processLearn a structured approach for writing goodrequirements in a natural languageProvide practical ideas for writing betterrequirementsrequirementsBe able to organize and participate in requirementsreviewsNote: in Agile requirements come as user stories

Improve Quality Services BV 3

Erik van Veenendaal

Founder and major shareholder ImproveQSI t ti i 1989 ki f

www. erikvanveenendaal.nl

In testing since 1989 working for many different clients and in many different rolesAuthor “TMap”, “TMMi”, “ISTQB Foundation” and many other books and papersVice-President International Software Testing Qualifications Board (ISTQB) 2005 - 2008


Supporting member IREB boardKeynote speaker, e.g., EuroSTAR, STARWinner of the European Testing Excellence Award (2007)

Improve Quality Services BV

Service organisation in the area ofTesting Requirements Engineering and

www. improveqs.nl

Testing, Requirements Engineering and Quality ManagementConsultancy, Subcontracting and Training

SW Process ImprovementTesting (TMap TMMi)


SW Process ImprovementQuality Level ManagementIT-AuditingRequirements Engineering& management (IREB)

Testing (TMap, TMMi)Agile Testing (CAT)Test Process ImprovementCertification (ISTQB)Inspections / Reviews

How I got involved?

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


Understanding Requirements


The Challenge

To capture the need “completely” and “ nambig o sl ” itho t resorting to specialist“unambiguously” without resorting to specialist jargon, thus understandable by our stakeholders

Requirements are the basis for:- Project (sprint) planning

T d ff ( i it tti )


- Trade-off (priority setting)- Development- Acceptance testing

Why?

Most significant contributors to project failure relate to requirements (Standish Group CHAOS report)

Outsourcing !?

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)

Reliable EstimatesFormal methodology

Project Success Factors….

Clear business objectives

16%User

Minimized scope10%

Executive support

12%18%

14%

8%6% 5%Standard software

infrastructure

gy

44%


involvement6%

Firm basic requirements

14%

5%Experienced

Project Manager

Other

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

More facts and figures

Investing less than 5% in gathering and processing i t ill l d t b d t f

Req. GD DD Impl. Test Oper.

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 engineeringRequirements defects are the most important


Requirements defects are the most important- defects have the characteristic to multiply themselves

top-down- cost of rework rise (exponentially)

Importance of Requirements

Different stakeholders Different objectives

User/Customer State their needsAgile Team Develop sprint planningProject Manager Develop budget/scheduleSystem Engineers Develop architecture

S f &Testers Specify test plan & casesSoftware Engineers Define work to be done


What is a Requirement?

A requirement is a condition or capability t hi h th t t f

… 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,

to which the system must conform


y y , p ,standard or other formally imposed documentation

… a statement of intent that describes something the system needs to do for some user

.

Three Types of RequirementsFunctional 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


p q y pwith 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

A main principle…….

Requirements process is context dependentHow much documentation is enough?

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


State abstractly how the system will meet the stakeholder requirements. Avoid reference to any particular design. “The product shall …..”

Agile / V-model / OutsourcingBusiness / Project / Product / Human factors

More Definitions….

Requirements Engineering- A systematic approach to gathering, organizing, and documenting the requirements of the system

Requirements ManagementA h bli h d i i


- 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

Requirements Proces (1)

1. Kick-off phase33 44 5511 22

Objective, scope, stakeholders, business caseCheck: Are things clear enough to start?

2. Requirements gathering (quantity-based)Functional, Non-functional, ConstraintsVarious gathering / elicitation techniques


a ous gat e g / e c tat o tec ques

3. Requirements specification (quality-based)Templates, Rule setMultiple levels, level of detail needed

Requirements Proces (2)

4. Verification and ValidationChecking requirements

33 44 5511 22

Checking requirementsDifferent types (walkthrough, pair-inspection)Use rules and checklists

5. Requirements managementIdentification and traceability

Note, in Agile

this is not a


Use attributes, e.g., sourceChange management Relates to the entire proces

this is not a

lineair process

• 08:30 – 09:15 Introduction to Requirements Engineering09:15 – 10:00 Kick-off Phase10:00 10:15 Requirements Gathering


10:00 – 10:15 Requirements Gathering





Kick-off, What is needed?

1. The purpose of the product2 C t d th t k h ld2. Customers and other stakeholders3. Users of the product4. Scope of the product (context diagram)5. Glossary: naming conventions, abbreviations

and definitions6. Relevant facts and assumptions7. References


The purpose of the product

The user problem (no more than 1 page)

PRINCE-2 “Business Case”RuP “Vision document”

- 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)p (p p )- What is the business advantage?- How will you measure the advantage?- Statement of needs on a high-level

Improve Quality Services BV 21Get stakeholders commitment on this !!

Purpose Example (A’dam Metro)

PurposePurpose: : To To sellsell metro tickets more metro tickets more efficientlyefficiently ((fasterfaster) ) thanthan currentlycurrentlyefficientlyefficiently ((fasterfaster) ) thanthan currentlycurrently..

RationalRational: : To To increaseincrease salessales and and reducereducecueingcueing whilewhile buyingbuying metro ticketsmetro tickets..

AcceptanceAcceptance Criteria: Criteria: The product The product willwillhand hand out ticket 30% out ticket 30% fasterfaster thanthan the the


a da d out t c et 30%out t c et 30% asteaste t at a t et ecurrentcurrent system. system. ThisThis improvementimprovement shallshallbebe achievedachieved onon all all prioritypriority 1 stations at 1 stations at peakpeak hourshours..

Stakeholders

A stakeholder is anyone who is interested in the product

Microsoft Excel-werkblad

productStakeholders may use it, are affected by it, have specific knowledge on it, or develop the productBrainstorm a list of stakeholdersDocument the knowledge area of the stakeholders (e g typical use cases nonstakeholders (e.g. typical use cases, non-functional or other requirements)Forgotten stakeholders means forgotten req.’s !!


Users of the Product

The purpose of identifying the users, so that you can understand the work that they docan understand the work that they doand the product you must build for themFor the users, describe all the known and potential users and their attributesThe roles (actors) for the user stories (use cases)

fto be defined laterForgotten users means forgotten req.’s !!


Context of Use

The functionality and usability of a product is effected by its context of use

Microsoft Office Excel-werkruimte

y

Context is characterized by :- the users of the product- the tasks they carry out- the working environmentg- …

Tool : Context of Use checklist MuSIC


The Scope of the Requirements

The context defines the extent of the workThe context is provided by the services provided by the work… and the needs of the outside worldDefines the scope of the work by showing the connections to the adjacent systemsIncludes all desired capabilities


Context diagram

AdjacentP

AdjacentProcess

At system leveladjacent systems

Work to be studied

(functionalitiesand data)

ProcessProcess

Services providedServices providedby the productby the product


AdjacentProcess Needed by the productNeeded by the product

to provide the servicesto provide the services

Naming conventions & definitionsMisunderstood terms cause problemsStart a list of important terms used by the stakeholders p yThis will be enlarged and refined laterIf your terms invoke the right meaning they save hours of explanationCheck for internal and industry-standardsContains terms that

- Could (potentially) be ambiguous in the context considered

- Are central for the project and the application domainLater….”Do all terms have a requirement? “


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?Sh ld d k f d b ttShould you proceed or ask for more and better information?


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”









Kano model: three categories

Not fulfilled Fulfilled

Basic factors Extremely dissatisfied

Not dissatisfied

Performance factors Dissatisfied Satisfied

Must-be quality


Excitement factors Not dissatisfied Extremely satisfied

Expected quality

Attractive quality

Requirements Gathering (1)

Finding conscious, unconscious and subconscious requirementsrequirementsApproach depends on:

- risk factors- experience of the req. engineer- time & budget- availability stakeholders

l it d th d f d t il d d- granularity and the degree of detail needed- system context- availability of sources, e.g., systems / documentation- …

All about quantity not quality building the backlogImprove Quality Services BV 33

Requirements Gathering (2)

Survey techniques- Interviews questionnaires

Observation techniques− Apprenticing fieldInterviews, questionnaires

Creativity techniques- Brainstorming, change of

perspective, analogies, role playing

Apprenticing, field observation

Document-centric techniques− System archaeology,

reuse of requirements


Combining different techniques for the best result …

Interview the stakeholders

Not the sole technique !!U d ’t k ll th i t- 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 H Wh Wh Wh Wh t WhHow..Why..When..Where..What..Who

- Are more likely to extract information

Use answers from one questions to ask a new one


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)g g)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….


Interview ProcessPeople factorsare critical !!

1. Getting acquainted2 Explain rules2. Explain rules3. Gather requirements

- check your observations- record draft requirements

4. Summary


y“have I missed anything?”

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

Questionnaire NF-requirements

In stakeholders’ (users’) language Business characteristicsBusiness characteristics

- objectives, process, users, software product- two versions: information systems and technical

automation, e.g. embeddedInterview with various stakeholders

-1 hour per interviewAnswers linked to quality attributes

- two dimensional matrices- business characteristics versus ISO 9126

Note NF-requirements are often on a system level


Examples Checklist Items

Objectives- Higher level of efficiency / productivity

note, rationale becomes clear as well

Higher level of efficiency / productivityreq.’s on usability and time-behaviour

- Continuity of information servicesreq.’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


Brainstorming

Requirements gathering is inventionObjective of brainstorming is to be as imaginativeObjective of brainstorming is to be as imaginative as possible, and so generate as many ideas as possibleList, discuss and group the ideas

- Initially five items and then discuss, next round …

Ch k th id ith th j tCheck the ideas with the project scopeLater turn them into requirementsThink about a facilitator


Brainstorming: simple rules

Wide range of disciplines and experienceStart with a well-defined open ended statement ofStart 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 functionalityfunctionalitySuspend judgment and evaluationPiggyback on each others’ ideasUse a separate section for project issues & design


Study the current situation

Understanding what we seek to changeCurrent system contains many of the neededCurrent 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 systemAlso include system from competitorsPractice apprenticing “Nobody can talk better about what they do, and why they do it, than they can while in the middle of doing it”


Supporting Tools

Mind mappingPrototypingUse Case WorkshopsEtc.


Mind maps

Mind maps to explore ideas

www.visual-mind.com

www.freemind.com

Useful devices to organize your thoughtsYou see the links between the various aspects of the product that have been told aboutUseful during interviewing users /stakeholders and brainstorminggImprove sharing of thoughts and knowledgeSome use class diagrams as a basic structure


Prototypes

For information gatheringSome requirements are not obvious, or are not fully elaborated yetSome users have trouble articulating their desiresGive users the opportunity to use the requirementsRestrict the prototypes to most common tasks


Restrict the prototypes to most common tasksFocus on the product, not the prototype

“The truth is almost never in the words”

Especially useful when ..

The product did not exist beforeThe users have no experience with the kind ofThe users have no experience with the kind of productThe users are stuck in the current way of workingThe users have trouble stating their req.’sThe requirements analyst / developer has trouble

46

yunderstanding what is required

Low-fidelity vs. High-fidelity prototypes

Use Case Workshops

Start with the context diagramUse cases give users a convenient way to

Describing the bigger picture

Use cases give users a convenient way to partition the productDescribes the bigger pictureOne 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


Use Cases

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

use case req.

p presultThe 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 actorThe scenario is the story of the use case


Use Case Example (A’dam Metro)UseUse CaseCase: : TravelleTraveller r buyingbuying a ticketa ticket..ActorActor: : TravellerTraveller1.1. The The travellertraveller offers offers destinationdestination, type of , type of

ticket and ticket and paymentpayment to the productto the product2.2. The productThe product checkschecks whethewhether the r the paymentpayment

is is okok forfor the the chosechose n n destinationdestination and type and type of of tickerttickert

33 The product The product checkschecks whetherwhether the the networknetwork


3.3. The product The product checkschecks whetherwhether the the networknetworkis is operationaloperational forfor the the chosenchosen destinationdestination..

4.4. TheThe product submits ticket and product submits ticket and ififnecessarynecessary changechange..

5.5. The product storesThe product stores the the transactiontransaction

Requirements Example (A’dam Metro)

UseUse Case step Case step 22.: .: The product The product checkscheckswhetherwhether the the paymentpayment is is okok forfor the the chosenchosendestinationdestination and type of ticketand type of ticketdestinationdestination and type of ticketand type of ticket

RequirementsRequirements::2.1 The product 2.1 The product shallshall establishestablish thatthat the the paymentpayment consistsconsists of of legallylegally validvalid money .money .2.2 The product 2.2 The product shallshall calcuatecalcuate the the lowestlowestfarefare forfor the the destinationdestination consideringconsidering dayday of of

k d tik d ti


week and timeweek and time2.3 The 2.3 The prodyctprodyct shallshall comparecompare the the travellerstravellers’ ’ paymentpayment withwith the the calculatedcalculated paymentpayment2.4 The product 2.4 The product shallshall provide feedback in provide feedback in case the case the paymentpayment is is notnot sufficientsufficient..

SWOT analysis Techniques & Tools

Instruction:Choose two elicitation techniques (or tool)Choose two elicitation techniques (or tool)- As a team what do you consider to be strongpoints / selling items of that technique?

When to use!- And what do you consider to be problems / drawb k / k f th t t h i ?


backs / weaknesses of that technique?When hard (or not) to use!








What is needed ….

If we could look into each others brains, we wouldn’t need documentation …Documentation helps us to communicate

Sender

Joint code

Receiver

Encodes Decodes

Message


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

"I didn't say he killed his wife“

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


d d t say e ed s e"I didn't say he killed his wife""I didn't say he killed his wife"

What are “good” requirements?

Identify at least five “rules” that determine ywhether a requirement is a good

(or “bad”) requirement

Consider !!

55

Individual requirements

Requirements attributes

Improve Quality Services B.V.

What is a good requirement?


Excercise Radio Watch (1)

• Study the requirement specification for the new Radio Watchnew Radio Watch

• Make comments (find defects) based onwhat you have learned so fare.g., attributes, rules, guidelines….


+

Requirement # : Requirement Type :Use Case :

Requirements cards

Description :

Rationale :Priority :Acceptance Criteria :


Source :Size :Supporting material : …annotation, conversation…

Requirements attributes (1)ID

- To allow traceabilityy

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 caseF bili d h l


- For traceability and change control purposes- Again for grouping etc.

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

stakeholders’ whishes & needs

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


q

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

Size- Number of story points

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, broken glas, and throwing darts.”

Acceptance Criteria

We have to be able to tell whether a solution completely satisfies or fits a requirement

involve tester here

completely satisfies, or fits, a requirementTo make requirements measurableIn practice very important for non-functional requirementsIt is usually necessary to negotiate acceptance

it i ith th t k h ld

62

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


Example Acceptance Criteria

Requirement / User Story- As a student I want to be able to buy a parking pass so IAs a student, I want to be able to buy a parking pass so I

can get to school quickly

Acceptance Criteria- A pass should be issued per month- The student will not receive the parking pass if the

payment is insufficientpayment 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 but one parking pass per month- …..


Writing Guidelines

Short and concise sentences and paragraphsOne requirement per sentence

To write simple is as difficult as to be good

One requirement per sentence - no compound requirements, a single verb

Consistent terminology (homonyms)Avoid generalizationsUse ‘must’, ‘can’ and similar words carefully

‘ h ll’ i b tt ‘ ’ i di t ti- ‘shall’ is better, ‘can’ indicates optionsNo solutions or designDirective languageNo pronouns


Use Templates

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

www.requirementsengineering.info

- 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

65

- 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


Requirements Rule Set

• Usefull set of agreementsS if th t t d f t• Specify the contents and formatof a requirement (and requirementsdocument)

• More objective, less discussion• Applied during specification and reviewing


• Applied during specification and reviewing• Organization specific• Rules for tracing, format and content

Examples of Rules (1)

IdentificationValuable / purpose All forms of annotation commentsValuable / purposeChangesGroupingUniquenessConsistency

All forms of annotation, comments, notes, suggestions, examples, or other items not part of the formalrequirement shall be clearly indicated as such. This will be documented by using the attribute ‘additional information’.


AnnotationLanguageKnowledge responsible (source)

Examples of Rules (2)

DetailBrief / Small

Req.’s shall be unambiguous to the intended readership. Req.’s shall have only one interpretation. For example the

Brief / SmallUnambiguousPriorityRationaleCompound

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.


IndependentTechnically achievableTestable

Interpretation: Unambiguous

To be part of the backlog- The requirements shall be at the level ofThe 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).


• Select the rules that you will adhere tooR i f h i f h• Rewrite some of the requirements for the newRadio Watch

• Make concrete improvement suggestions• Watch out for fuzzy terms• Use the requirements card template


+

Fuzzy Terms ListMostly As neededMight Make senseMight Make senseAppropriate Might make senseGraceful At minimumMajor SlowlyMay be of use to Including but not limited


May be of use to Including but not limitedAnd/or SuitableVarious Clean and stableInterface Several

Prioritizing Requirements

Use the priority (business value) attribute If this fails sort the requirements / use casesIf this fails, sort the requirements / use cases using (MoSCoW):- Must have in next sprint- Should have in next sprint- Could have in next sprintp- Would like if possible

Prioritize “Should have” & “Could have” categoriesUsually highly subjective and many discussions


Priority Factors from Practice

Selling item (marketing)Usage intensity CustomizationUsage intensityBusiness objectivesCustomer valueEase of implementationCost of implementation

Customizationneeded

Weightingscan be applied

pTime-to-marketCompetitionExternal visibility


PRISMA®

Stakeholders Involvement

Identify stakeholders (internal and external)product owner end user business mgr marketing- 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 differNote, this may chance as the project progresses


Stakeholders Involvement (2)

Individual scoring

9 : Critical5 : High3 : Moderate1 : Low

Sellingitem

Usage intensity

……

Item 1

Item 2

5

5

5

4

0 : None

they shallmake Item 2

Item 3

Item 4

Item 5

5

4

5

4

4

5

2

1

makechoices

75Improve Quality Services BV

Consensus Meeting

Discuss issue list - first defects found !!Result may influence development & test approachResult may influence development & test approach

Impact

Selling Item

Usage intensity

… Priority Num

b


y ber

Item 1 5 4 1 10Item 2 3 3 1 7Item n

Achieving Consensus ….

Talking it outdecide / announce before the meeting

Use the highest ratingUse the average ratingUse the most applied ratingDefer to one of the team members- Let the “owner” decide

Team votingGet an experts’ opinion

77Improve Quality Services B.V.

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

The User Story Matrix

X X

Size

(Story

Points)

X

X X

X

Improve Quality Services BV 79Relative Business Value

X XRequirements Two Aspects

Needs to be readableThe structure of the document how it is organised and- 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

i d h th di id d i t i lpreciseness 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


Readability: The Req.’s document

Three main sectionsIntroduction

Putting togetherwhat we have- Introduction

- Overall description• Constraints

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

what we have gathered so far

q

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






• 13.00 – 13.30 Exercise Radio Watch (1)13.30 – 14.15 Requirements Specification – cont.14 15 14 45 E ercise Radio Watch (2)14.15 – 14.45 Exercise Radio Watch (2)



Core Agile Practice : Reviews

CommunicationCommunication & Feedback& Feedback

Walkthrough / Pair Inspection /Informal Reviews

CommunicationCommunication & Feedback& Feedback

Customer collaborationCustomer collaboration

83

Priority to the profitableApply review practices that make the difference

Why Verification and Validation?

Efficient and effective way to find defects bi i t l t d- ambiguous, consistency, completeness, compound, ...

Many defects have already been made before design has started

- 50% “requirements related”

Early defects are highly important


Early defects are highly important- defects have the characteristic to multiply

themselves top-down- cost of rework rises (exponentially)

Req. Design Coding Testing

Requirements reviews - types

Walkthrough (with stakeholders)product owner will guide the group through the

Validation

- product owner will guide the group through the requirements

- common understanding, knowledge sharing, consensus

Inspection (with fellow engineers) Verification


p ( g )- formal check against rules- individual process to find defects- using checklists

Processing Requirementsinformation gathering

communicationconsensus

approval

Requirementsgathering

Walkthroughapproval


Requirements(user stories)

BrainstormInterviewing

Mind mapping

Use cases Inspection

Review Process OverviewPlanning

Kick-Off

Preparation

MeetingReworkRework Exit


Walkthrough

• Planning (scrum master): no formal entry criteria

P i ( di ) i i• Preparation (reading): preparing questions

• Kick-off at the beginning of the meeting: objective

• Meeting: author provides explanation(e.g., scenario’s, prototypes, use cases)

S ib t d fi di


• Scribe to records findings

• Scrum master manages the process (chair)

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

User Scenarios

A scenario is a story that illustrates the action that the product will take for a specificaction that the product will take for a specific caseA scenario might be the generic ‘normal case’ story, or it would tell a specific storyThink of “what if scenarios” !!


Think of what if scenarios !!Deals with one (or part of an) event / use caseUsed to discover missing requirements !!

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)

Check for Conflicts

• Look for pairs of requirements that are in conflict with each otherconflict with each other

• Look at existence dependent requirements, e.g., one product data that the other needs

• Do any requirements cover the same subject?j

• Is every use of terminology consistent with conventions and definitions?

• Real conflicts identify negotiation pointsImprove Quality Services BV 91

Checklist vs. Rules

Derived from rules - objectivesMost frequent / important defectsOne pageDynamic document, not staticQuestion form, “NO” means a defectQuestion form, NO means a defectShall be company specific


Juran’s F-Test “The Game Rules”

Close your slide copies now!No questions! No discussion. Make your best interpretation of the following rule :

Count all defects for standard F

No instances of “F” allowed on the screen.

Standard applies to any type of “F”, so count even “derivates” (example “f” and “F”)


Write down your count of “defects” when the time is upYou may move to any position in the room to see betterDo not interfere with the view of othersYou will get 2 minutes to check

Juran'sJuran's “F” “F” TestTest"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

94Improve Quality Services BV

Checklist for “F” searching

F1. Do you find the word “OF”?F2 Do you find large graphic patterns resembling F ?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 hyphenF6 Did you see the upside down backwards letter “t” (= “f”)?F6. Did you see the upside-down, backwards letter t (= f )?F7. ……...



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


+





• 13.00 – 13.30 Exercise Radio Watch (1)13.30 – 14.15 Requirements Specification – cont.14 15 14 45 E ercise Radio Watch (2)14.15 – 14.45 Exercise Radio Watch (2)



IREB e.V.

International Requirements Engineering BoardA non-profit organization

www.certified-re.de

A non-profit organizationBoard members are international recognized experts, e.g., Suzanne Robertson, Chris RuppErik van Veenendaal active as a supporting memberGoal: to improve practices in requirements


Goal: to improve practices in requirements engineering and requirements managementBased on SWEBOK, ISTQB, IPMA, IEEEiSQI active as examination body

IREB Foundation

IREB Foundation Syllabus Defined Educational Objectives andDefined Educational Objectives and Levels of KnowledgeThree day training course 75 minutes exam, 45 questions

- Questions vary in difficulty and different (indicated) marking accordingly


marking accordingly- At least 60% of possible score needed to pass- E-based exam also possible

Advanced syllabi also recently became available

IREB activities (Status 01-01-2013)

DenmarkDenmarkUnited KingdomUnited Kingdom

SwedenSwedenFinlandFinland

GermanyGermanyThe NetherlandsThe Netherlands

MalaysiaMalaysia

USAUSABulgariaBulgaria

ColumbiaColumbia

IndiaIndiaIsraelIsraelSpainSpain

SwitzerlandSwitzerland South KoreaSouth Korea

DenmarkDenmark

AustriaAustria

HungaryHungary

RussiaRussia

ChinaChinaVenezuelaVenezuela

SudanSudanEcuadorEcuador


ColumbiaColumbia

BrazilBrazil

South africaSouth africa

EgyptEgypt SingaporeSingaporeAustraliaAustralia

New ZealandNew Zealand

Things to do tomorrow

Introduce requirements attributes (cards)Add ti l l

From previous groups

Add rationale earlyWrite use cases and add requirementsUse multiple gathering techniquesWrite requirements, not (technical) solutionDefine and use requirements rules

101

Introduce practical reviews Get the whole team involved


Any questions.....?

102

Thank you !!Thank you !!Improve Quality Services B.V.

requirements engineering: a practicum

Technology