Requirements Engineering: A Practicum

�

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

��

"Requirements Engineering: A Practicum"

��

Presented by:

Erik van Veenendaal Improve IT Services BV

��

Brought�to�you�by:��

��

340�Corporate�Way,�Suite�300,�Orange�Park,�FL�32073�888Ͳ268Ͳ8770�ͼ�904Ͳ278Ͳ0524�ͼ�[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


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

! 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?’”


4


Understanding Requirements


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


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 !?


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


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


7


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


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


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?


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


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


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







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


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


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

Get stakeholders commitment on this !!

Purpose Example (A’dam Metro)


Purpose: To sell metro tickets more efficiently (faster) than currently.

Rational: To increase sales and reduce cueing while buying metro tickets.

Acceptance Criteria: The product will hand out ticket 30% faster than the current system. This improvement shall be achieved on all priority 1 stations at peak hours.

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 !!


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 !!


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


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


14

Context diagram


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?


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?


16







Kano model: three categories


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)


! 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


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


19

Interview Process


People factors are critical !!

1.  Getting acquainted 2.  Explain rules 3.  Gather requirements

- check your observations - record draft requirements

4.  Summary “have I missed anything?”

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

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


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


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


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


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”


22


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


www.visual-mind.com

www.freemind.com

23


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


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


use case req.

25

Hierarchy and Traceability

Context diagram

Use cases

Req.’s Req.’s

EPICs

User stories

User stories


Use Case Example (A’dam Metro)


Use Case: Traveller buying a ticket. Actor: Traveller 1.  The traveller offers destination, type of

ticket and payment to the product 2.  The product checks whether the payment

is ok for the chose n destination and type of tickert

3.  The product checks whether the network is operational for the chosen destination.

4.  The product submits ticket and if necessary change.

5.  The product stores the transaction

26

Requirements Example (A’dam Metro)


Use Case step 2.: The product checks whether the payment is ok for the chosen destination and type of ticket

Requirements: 2.1 The product shall establish that the payment consists of legally valid money . 2.2 The product shall calcuate the lowest fare for the destination considering day of week and time 2.3 The prodyct shall compare the travellers’ payment with the calculated payment 2.4 The product shall provide feedback in case the payment is not sufficient.


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








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


"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


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


+

30


Requirement # : Priority : Requirement Type : Use case : Description : Rationale : Source : Acceptance Criteria : Size : Supporting material : …annotation, conversation…

Requirements cards


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


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


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


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


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


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


34


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


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


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.


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


• 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



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


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


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


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


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


40

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


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


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


Putting together what we have

gathered so far

42







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


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


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


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


45


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


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


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


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 !  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. ……...


49


! 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”?!








50


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


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


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


52

103

Any questions.....?

Thank you !! Improve Quality Services B.V.

Requirements Engineering: A Practicum

Technology

Transcript of Requirements Engineering: A Practicum