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
Improve Quality Services BV 4
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)
Improve Quality Services BV 5
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?’”
Improve Quality Services BV 6
Understanding Requirements
Improve Quality Services B.V. 7
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 )
Improve Quality Services B.V. 8
- 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
Improve Quality Services B.V. 9
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%
Improve Quality Services BV 10
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
Improve Quality Services B.V. 11
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
Improve Quality Services BV 12
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
Improve Quality Services B.V. 13
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
Improve Quality Services BV 14
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
Improve Quality Services BV 15
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
Improve Quality Services BV 16
- 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
Improve Quality Services B.V. 17
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
Improve Quality Services B.V. 18
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
Requirements Engineering: A Practicum
10:00 – 10:15 Requirements Gathering
• 10:30 – 11:30 Requirements Gathering - cont.11.30 – 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.40 IREB, Evaluation and Closure
Improve Quality Services B.V. 19
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
Improve Quality Services BV 20
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
Improve Quality Services BV 22
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 !!
Improve Quality Services BV 23
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 !!
Improve Quality Services BV 24
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
Improve Quality Services BV 25
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
Improve Quality Services BV 26
Context diagram
AdjacentP
AdjacentProcess
At system leveladjacent systems
Work to be studied
(functionalitiesand data)
ProcessProcess
Services providedServices providedby the productby the product
Improve Quality Services BV 27
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? “
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?Sh ld d k f d b ttShould you proceed or ask for more and better information?
Improve Quality Services BV 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”
Improve Quality Services BV 30
• 08:30 – 09:15 Introduction to Requirements Engineering09:15 – 10:00 Kick-off Phase10:00 10:15 Requirements Gathering
Requirements Engineering: A Practicum
10:00 – 10:15 Requirements Gathering
• 10:30 – 11:30 Requirements Gathering - cont.11.30 – 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. 31
Kano model: three categories
Not fulfilled Fulfilled
Basic factors Extremely dissatisfied
Not dissatisfied
Performance factors Dissatisfied Satisfied
Must-be quality
Improve Quality Services BV 32
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
Improve Quality Services BV 34
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
Improve Quality Services BV 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)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….
Improve Quality Services BV 36
Interview ProcessPeople factorsare critical !!
1. Getting acquainted2 Explain rules2. Explain rules3. Gather requirements
- check your observations- record draft requirements
4. Summary
Improve Quality Services BV 37
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
Improve Quality Services BV 38
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
Improve Quality Services BV 39
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
Improve Quality Services BV 40
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
Improve Quality Services BV 41
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”
Improve Quality Services BV 42
Supporting Tools
Mind mappingPrototypingUse Case WorkshopsEtc.
Improve Quality Services B.V. 43
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
Improve Quality Services BV 44
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
Improve Quality Services B.V. 45
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
Improve Quality Services BV 47
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
Improve Quality Services BV 48
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
Improve Quality Services BV 49
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
Improve Quality Services BV 50
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 ?
Improve Quality Services B.V. 51
backs / weaknesses of that technique?When hard (or not) to use!
• 08:30 – 09:15 Introduction to Requirements Engineering09:15 – 10:00 Kick-off Phase10:00 10:15 Requirements Gathering
Requirements Engineering: A Practicum
10:00 – 10:15 Requirements Gathering
• 10:30 – 11:30 Requirements Gathering - cont.11.30 – 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. 52
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
Improve Quality Services B.V. 53
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"
Improve Quality Services B.V. 54
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?
Improve Quality Services B.V. 56
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….
Improve Quality Services BV 57
+
Requirement # : Requirement Type :Use Case :
Requirements cards
Description :
Rationale :Priority :Acceptance Criteria :
Improve Quality Services B.V. 58
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
Improve Quality Services B.V. 59
- 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
Improve Quality Services B.V. 60
q
Source- Name of the person who raised the requirement , or document.
Size- Number of story points
Gold plating …..
Improve Quality Services BV 61
“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
Improve Quality Services B.V.
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- …..
Improve Quality Services BV 63
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
Improve Quality Services BV 64
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
Improve Quality Services B.V.
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
Improve Quality Services B.V. 66
• 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’.
Improve Quality Services B.V. 67
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.
Improve Quality Services B.V. 68
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.
Improve Quality Services B.V. 69
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).
Excercise Radio Watch (2)
• 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
Improve Quality Services BV 70
+
Fuzzy Terms ListMostly As neededMight Make senseMight Make senseAppropriate Might make senseGraceful At minimumMajor SlowlyMay be of use to Including but not limited
Improve Quality Services B.V. 71
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
Improve Quality Services BV 72
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
Improve Quality Services BV 73
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
Improve Quality Services BV 74
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
Improve Quality Services B.V. 76
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 …..
Improve Quality Services BV 78
'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
Improve Quality Services BV 80
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
Improve Quality Services BV 81
• 08:30 – 09:15 Introduction to Requirements Engineering09:15 – 10:00 Kick-off Phase10:00 10:15 Requirements Gathering
Requirements Engineering: A Practicum
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 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.40 IREB, Evaluation and Closure
Improve Quality Services B.V. 82
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
Improve Quality Services B.V. 84
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
Improve Quality Services B.V. 85
p ( g )- formal check against rules- individual process to find defects- using checklists
Processing Requirementsinformation gathering
communicationconsensus
approval
Requirementsgathering
Walkthroughapproval
Improve Quality Services BV 86
Requirements(user stories)
BrainstormInterviewing
Mind mapping
Use cases Inspection
Review Process OverviewPlanning
Kick-Off
Preparation
MeetingReworkRework Exit
Improve Quality Services B.V. 87
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
Improve Quality Services B.V. 88
• 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” !!
Improve Quality Services B.V. 89
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’
Improve Quality Services B.V. 90
• 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
Improve Quality Services BV 92
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”)
Improve Quality Services BV 93
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. ……...
Improve Quality Services BV 95
Excercise Radio Watch (3)
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”?!
Improve Quality Services BV 96
+
• 08:30 – 09:15 Introduction to Requirements Engineering09:15 – 10:00 Kick-off Phase10:00 10:15 Requirements Gathering
Requirements Engineering: A Practicum
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 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.40 IREB, Evaluation and Closure
Improve Quality Services B.V. 97
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
Improve Quality Services B.V. 98
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
Improve Quality Services B.V. 99
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
Improve Quality Services B.V. 100
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
Improve Quality Services B.V.
Any questions.....?
102
Thank you !!Thank you !!Improve Quality Services B.V.
Top Related