requirements engineering: a practicum
DESCRIPTION
Identifying, documenting, and communicating software requirements are key to all successful IT projects. Common problems in requirements engineering are “How do we discover the real requirements?”, “How do we document requirements?”, and “How do user stories fit into requirements?” Erik van Veenendaal answers these questions and more while helping you improve your skills in requirements engineering for both traditional and agile projects. With practical case studies and hands-on exercises, Erik illustrates requirements issues and solutions. Practice finding, specifying, and evaluating requirements while learning how to gather information through varied elicitation techniques. Exploring the advantages and disadvantages of each technique, Erik offers guidelines for developing both functional and nonfunctional requirements. Learn a rule set for determining how much documentation you need for “good enough” requirements. Explore requirements review techniques—walkthroughs and inspections—to determine what will work best for you. Collaboratively create a set of Golden Rules for requirements engineering that every project can use.TRANSCRIPT
�
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�ͼ�[email protected]�ͼ�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.
1
Do not put content on the brand
signature area
Do not put content on the brand signature area
Erik van Veenendaal
www.erikvanveenendaal.nl
Requirements Engineering Quality makes products
which do not return and
customers who do
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 15.45 – 16.05 Exercise Radio Watch (3) 16.05 – 16.30 IREB, Evaluation and Closure
Improve Quality Services B.V. 2
2
Learning Objectives
! 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
Learning by thinking and doing
Improve Quality Services BV 4
Erik van Veenendaal
! 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)
www. erikvanveenendaal.nl
3
Improve Quality Services BV 5
Improve Quality Services BV
! Service organisation in the area of Testing, Requirements Engineering and Quality Management
! Consultancy, Subcontracting and Training
SW Process Improvement Quality Level Management IT-Auditing Requirements Engineering & management (IREB)
Testing (TMap, TMMi) Agile Testing (CAT) Test Process Improvement Certification (ISTQB) Inspections / Reviews
www. improveqs.nl
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?’”
Improve Quality Services BV 6
4
Improve Quality Services B.V. 7
Understanding Requirements
Improve Quality Services B.V. 8
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
5
Improve Quality Services B.V. 9
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)
Outsourcing !?
Improve Quality Services BV 10
Clear business objectives
16% User
involvement 6%
Minimized scope 10%
Firm basic requirements
Executive support
12%
18%
14%
8% 6% 5%
5% Experienced
Project Manager
Standard software infrastructure
Reliable Estimates Formal methodology
Other
Source: “Extreme Chaos” The Standish Group. www.standishgroup.com
44%
Project Success Factors….
6
Improve Quality Services B.V. 11
More facts and figures
! 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)
Req. GD DD Impl. Test Oper.
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
Improve Quality Services BV 12
7
Improve Quality Services B.V. 13
What is a Requirement?
… 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
.
A requirement is a condition or capability to which the system must conform
Improve Quality Services BV 14
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
8
Improve Quality Services BV 15
A main principle…….
" 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
How much documentation is enough?
Improve Quality Services BV 16
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
9
Improve Quality Services B.V. 17
Requirements Proces (1)
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
3 4 5 1 2
Improve Quality Services B.V. 18
Requirements Proces (2)
4. Verification and Validation ! 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
3 4 5 1 2
Note, in Agile
this is not a
lineair process
10
• 08:30 – 09:15 Introduction to Requirements Engineering 09:15 – 10:00 Kick-off Phase 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 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
Requirements Engineering: A Practicum
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
Improve Quality Services BV 20
11
The purpose of the product
! 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
Improve Quality Services BV 21
PRINCE-2 “Business Case” RuP “Vision document”
Get stakeholders commitment on this !!
Purpose Example (A’dam Metro)
Improve Quality Services BV 22
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.
12
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, 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 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 !!
Improve Quality Services BV 24
13
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
Improve Quality Services BV 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
Improve Quality Services BV 26
14
Context diagram
Improve Quality Services BV 27
Work to be studied
(functionalities and data)
Adjacent Process
Adjacent Process
Adjacent Process
Needed by the product to provide the services
Services provided by the product
At system level adjacent systems
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
15
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?
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” – Do you mitigate these risks?
Improve Quality Services BV 30
16
• 08:30 – 09:15 Introduction to Requirements Engineering 09:15 – 10:00 Kick-off Phase 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 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
Requirements Engineering: A Practicum
Kano model: three categories
Improve Quality Services BV 32
Not fulfilled Fulfilled
Basic factors Extremely dissatisfied
Not dissatisfied
Performance factors Dissatisfied Satisfied
Excitement factors Not dissatisfied Extremely satisfied
Must-be quality
Expected quality
Attractive quality
17
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 Improve Quality Services BV 33
Requirements Gathering (2)
Improve Quality Services BV 34
! Survey techniques - Interviews, questionnaires
! Creativity techniques - Brainstorming, change of
perspective, analogies, role playing
! Observation techniques − Apprenticing, field
observation
! Document-centric techniques − System archaeology,
reuse of requirements
Combining different techniques for the best result …
18
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
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)
! 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
19
Interview Process
Improve Quality Services BV 37
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?”
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
Improve Quality Services BV 38
20
Examples Checklist Items
! 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
Improve Quality Services BV 39
note, rationale becomes clear as well
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
Improve Quality Services BV 40
21
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
Improve Quality Services BV 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”
Improve Quality Services BV 42
22
Improve Quality Services B.V. 43
Supporting Tools
! Mind mapping ! Prototyping ! Use Case Workshops ! Etc.
Mind maps
! 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
Improve Quality Services BV 44
www.visual-mind.com
www.freemind.com
23
Improve Quality Services B.V. 45
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”
46
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
24
Use Case Workshops / EPIC
! 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
Improve Quality Services BV 47
Describing the bigger picture
Use Cases
! 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
Improve Quality Services BV 48
use case req.
25
Hierarchy and Traceability
Context diagram
Use cases
Req.’s Req.’s
EPICs
User stories
User stories
Improve Quality Services BV 49
Use Case Example (A’dam Metro)
Improve Quality Services BV 50
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
26
Requirements Example (A’dam Metro)
Improve Quality Services BV 51
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.
Improve Quality Services B.V. 52
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!
27
• 08:30 – 09:15 Introduction to Requirements Engineering 09:15 – 10:00 Kick-off Phase 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 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. 53
Requirements Engineering: A Practicum
Improve Quality Services B.V. 54
What is needed ….
! If we could look into each others brains, we wouldn’t need documentation …
! Documentation helps us to communicate
! Be careful, words may not be enough! - Formal / informal language - Different interpretations
Sender
Joint code
Receiver
Encodes Decodes
Message
28
Improve Quality Services B.V. 55
"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" "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"
56
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
Improve Quality Services B.V.
29
Improve Quality Services B.V. 57
What is a good requirement?
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….
Improve Quality Services BV 58
+
30
Improve Quality Services B.V. 59
Requirement # : Priority : Requirement Type : Use case : Description : Rationale : Source : Acceptance Criteria : Size : Supporting material : …annotation, conversation…
Requirements cards
Improve Quality Services B.V. 60
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
31
Improve Quality Services B.V. 61
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
Improve Quality Services BV 62
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.”
32
63
Acceptance Criteria
! 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
involve tester here
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 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 - …..
Improve Quality Services BV 64
33
Writing Guidelines
! 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
Improve Quality Services BV 65
To write simple is as difficult as to be good
66
Use Templates
! 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
www.requirementsengineering.info
Improve Quality Services B.V.
34
Improve Quality Services B.V. 67
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
Improve Quality Services B.V. 68
Examples of Rules (1)
! Identification ! Valuable / purpose ! Changes ! Grouping ! Uniqueness ! Consistency ! Annotation ! Language ! Knowledge responsible (source)
All forms of annotation, comments, notes, suggestions, examples, or other items not part of the formal requirement shall be clearly indicated as such. This will be documented by using the attribute ‘additional information’.
35
Improve Quality Services B.V. 69
Examples of Rules (2)
! Detail ! Brief / Small ! Unambiguous ! Priority ! Rationale ! Compound ! Independent ! Technically achievable ! Testable
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.
Improve Quality Services B.V. 70
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).
36
Excercise Radio Watch (2)
• 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
Improve Quality Services BV 71
Improve Quality Services B.V. 72
Fuzzy Terms List Mostly As needed Might Make sense Appropriate Might make sense Graceful At minimum Major Slowly May be of use to Including but not limited And/or Suitable Various Clean and stable Interface Several
37
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
Improve Quality Services BV 73
Priority Factors from Practice
! Selling item (marketing) ! Usage intensity ! Business objectives ! Customer value ! Ease of implementation ! Cost of implementation ! Time-to-market ! Competition ! External visibility
Improve Quality Services BV 74
Customization needed
Weightings can be applied
PRISMA®
38
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
Improve Quality Services BV 75
Stakeholders Involvement (2)
" Individual scoring
Selling item
Usage intensity
……
Item 1
Item 2
Item 3
Item 4
Item 5
5
5
4
5
4
5
4
5
2
1
9 : Critical 5 : High 3 : Moderate 1 : Low 0 : None
they shall make
choices
76 Improve Quality Services BV
39
Consensus Meeting
! Discuss issue list - first defects found !! ! Result may influence development & test approach
Improve Quality Services B.V. 77
Impact
Selling Item
Usage intensity
…
Priority Num
ber
Item 1 5 4 1 10 Item 2 3 3 1 7 Item n
Achieving Consensus ….
! 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
decide / announce before the meeting
Improve Quality Services B.V.
40
Or Play the Card Game
! Poker Planning based …..
Improve Quality Services BV 79
'Risk management in agile projects: the PRISMA approach‘ in: Professional Tester (June 2012)
downloadable from www.erikvanveenendaal.nl
The User Story Matrix
Improve Quality Services BV 80
Relative Business Value
Size
(Story
Points)
X
X
X
X
X
X
X
X
41
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
Improve Quality Services BV 81
Readability: The Req.’s document
! Three main sections - 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
Improve Quality Services BV 82
Putting together what we have
gathered so far
42
• 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 15.45 – 16.05 Exercise Radio Watch (3) 16.05 – 16.40 IREB, Evaluation and Closure
Improve Quality Services B.V. 83
Requirements Engineering: A Practicum
84
Core Agile Practice : Reviews
! Walkthrough / Pair Inspection / Informal Reviews
! Priority to the profitable ! Apply review practices that
make the difference
Communication & Feedback
Customer collaboration
43
Improve Quality Services B.V. 85
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
Improve Quality Services B.V. 86
Requirements reviews - types
! Walkthrough (with stakeholders) - 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
Validation
Verification
44
Processing Requirements
Improve Quality Services BV 87
Requirements (user stories)
Brainstorm Interviewing
Mind mapping
Use cases
Requirements gathering
Walkthrough
information gathering communication
consensus approval
Inspection
Review Process Overview Planning
Kick-Off
Preparation
Meeting Rework Exit
Improve Quality Services B.V. 88
45
Improve Quality Services B.V. 89
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
Improve Quality Services B.V. 90
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 !!
46
Improve Quality Services B.V. 91
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 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 Improve Quality Services BV 92
47
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
Improve Quality Services BV 93
Juran’s F-Test “The Game Rules”
Improve Quality Services BV 94
! Close your slide copies now! ! No questions! No discussion. Make your best interpretation of the
following rule :
! 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
No instances of “F” allowed on the screen.
Standard applies to any type of “F”, so count even “derivates” (example “f” and “F”)
48
95
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
Improve Quality Services BV
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. ……...
Improve Quality Services BV 96
49
Excercise Radio Watch (3)
! 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”?!
Improve Quality Services BV 97
• 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 15.45 – 16.05 Exercise Radio Watch (3) 16.05 – 16.40 IREB, Evaluation and Closure
Improve Quality Services B.V. 98
Requirements Engineering: A Practicum
50
Improve Quality Services B.V. 99
IREB e.V.
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
www.certified-re.de
Improve Quality Services B.V. 100
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
51
Improve Quality Services B.V. 101
IREB activities (Status 01-01-2013)
Germany The Netherlands
Malaysia
USA Bulgaria
Columbia
India Israel Spain
Switzerland South Korea
Denmark
Brazil
Austria
United Kingdom
South africa
Hungary
Russia
Egypt
Sweden Finland
Singapore Australia
New Zealand
China Venezuela
Sudan Ecuador
102
Things to do tomorrow
! 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
From previous groups
Improve Quality Services B.V.
52
103
Any questions.....?
Thank you !! Improve Quality Services B.V.