Personally designed (content + graphics design), officially accredited REQB® - Foundation Level Requirements Manager courseware. Trademarks are properties of the holders, who are not affiliated with courseware author.

1. REQBisatrademarkofGlobalAssociationforSoftwareQuality,GASQGmbH

2. Start and finish Course style
LunchCoffee and breaks
M00 - Course introduction 2/9 | 2/427

3.  The role of Requirements Manager
 The underpinning philosophy and principles of
requirements analysis profession
 Requirements analysis process
 The products produced by requirements analyst
 Requirements engineering roles
 Requirements engineering tools and techniques
Main goal
 Attempt Foundation exam with confidence
 Communicate freely within business analysis team
with confidence, understanding its principles and
philosophy
Secondary goal
 Benefits and value of requirements engineering and
REQB
M00 - Course introduction 3/9 | 3/427

4. Please share with the class:
 Your name and surname
 Your organization
 Your profession (title, function,
job responsibilities)
 Your familiarity with the:
 Project management
 Business analysis
 Requirements engineering
 Modelling
 Your personal session
expectations
M00 - Course introduction 4/9 | 4/427

5.  Foundation Exam
 Computer based and closed book exam
 Only pencil and eraser are allowed
 Simple multiple (ABCD) choice exam
 Only one answer is correct
 40 questions, pass mark is 26 (65%)
 1 hour exam
 No negative points, no “Tricky Questions”
 No pre-requisite for Foundation exam
 Sample, one (official) mock exam is
provided to you
Candidates completing an examination in a language that
is not their mother tongue, will receive additional time
M00 - Course introduction 5/9 | 5/427

6.  Foundation Exam
 Computer based and closed book exam
 Only pencil and eraser are allowed
 Simple multiple (ABCD) choice exam
 Only one answer is correct
 40 questions, pass mark is 26 (65%)
 1 hour exam
 No negative points, no “Tricky Questions”
 Pre-requisite is Foundation exam
Candidates completing an examination in a language that
is not their mother tongue, will receive additional time
M00 - Course introduction 6/9 | 6/427

7. REQB syllabus section code and title
1 Introduction to Requirements
2 Context of Requirements Engineering
3 Requirements Engineering Process
4 Requirements Management
5 Requirements Development
6 Requirements Engineering in Model
7 Tool Support
Module slide number / total module slides
Slide number /
total slides
Module number
and name
REQB syllabus
section code
SyllabusM00 - Course introduction 7/9 | 7/427

8. quizlet.com/63625322/
M00 - Course introduction 8/9 | 8/427

9. twitter.com/mirodabrowski
linkedin.com/in/miroslawdabrowski
google.com/+miroslawdabrowski
miroslaw_dabrowski
www.miroslawdabrowski.com
Mirosław Dąbrowski
Agile Coach, Trainer, Consultant
(former JEE/PHP developer, UX/UI designer, BA/SA)
Creator Writer / Translator Trainer / Coach
• Creator of 50+ mind maps from PPM and related
topics (2mln views): miroslawdabrowski.com
• Lead author of more than 50+ accredited materials
from PRINCE2, PRINCE2 Agile, MSP, MoP, P3O, ITIL,
M_o_R, MoV, PMP, Scrum, AgilePM, DSDM, CISSP,
CISA, CISM, CRISC, CGEIT, TOGAF, COBIT5 etc.
• Creator of 50+ interactive mind maps from PPM
topics: mindmeister.com/users/channel/2757050
• Product Owner of biggest Polish project
management portal: 4PM: 4pm.pl (15.000+ views
each month)
• Editorial Board Member of Official PMI Poland
Chapter magazine: “Strefa PMI”: strefapmi.pl
• Official PRINCE2 Agile, AgilePM, ASL2, BiSL methods
translator for Polish language
• English speaking, international, independent
trainer and coach from multiple domains.
• Master Lead Trainer
• 11+ years in training and coaching / 15.000+ hours
• 100+ certifications
• 5000+ people trained and coached
• 25+ trainers trained and coached
linkedin.com/in/miroslawdabrowski
Agile Coach / Scrum Master PM / IT architect Notable clients
• 8+ years of experience with Agile projects as a
Scrum Master, Product Owner and Agile Coach
• Coached 25+ teams from Agile and Scrum
• Agile Coach coaching C-level executives
• Scrum Master facilitating multiple teams
experienced with UX/UI + Dev teams
• Experience multiple Agile methods
• Author of AgilePM/DSDM Project Health Check
Questionnaire (PHCQ) audit tool
• Dozens of mobile and ecommerce projects
• IT architect experienced in IT projects with budget
above 10mln PLN and timeline of 3+ years
• Experienced with (“traditional”) projects under high
security, audit and compliance requirements based
on ISO/EIC 27001
• 25+ web portal design and development and
mobile application projects with iterative,
incremental and adaptive approach
ABB, AGH, Aiton Caldwell, Asseco, Capgemini, Deutsche Bank,
Descom, Ericsson, Ericpol, Euler Hermes, General Electric,
Glencore, HP Global Business Center, Ideo, Infovide-Matrix,
Interia, Kemira, Lufthansa Systems, Media-Satrun Group,
Ministry of Defense (Poland), Ministry of Justice (Poland),
Nokia Siemens Networks, Oracle, Orange, Polish Air Force,
Proama, Roche, Sabre Holdings, Samsung Electronics, Sescom,
Scania, Sopra Steria, Sun Microsystems, Tauron Polish Energy,
Tieto, University of Wroclaw, UBS Service Centre, Volvo IT…
miroslawdabrowski.com/about-me/clients-and-references/
Accreditations/certifications (selected): CISA, CISM, CRISC, CASP, Security+, Project+, Network+, Server+, Approved
Trainer: (MoP, MSP, PRINCE2, PRINCE2 Agile, M_o_R, MoV, P3O, ITIL Expert, RESILIA), ASL2, BiSL, Change Management,
Facilitation, Managing Benefits, COBIT5, TOGAF 8/9L2, OBASHI, CAPM, PSM I, SDC, SMC, ESMC, SPOC, AEC, DSDM Atern,
DSDM Agile Professional, DSDM Agile Trainer-Coach, AgilePM, OCUP Advanced, SCWCD, SCBCD, SCDJWS, SCMAD, ZCE 5.0,
ZCE 5.3, MCT, MCP, MCITP, MCSE-S, MCSA-S, MCS, MCSA, ISTQB, IQBBA, REQB, CIW Web Design / Web Development /
Web Security Professional, Playing Lean Facilitator, DISC D3 Consultant, SDI Facilitator, Certified Trainer Apollo 13 ITSM
Simulation …
M00 - Course introduction 9/9 | 9/427

11. 1. Introduction to Requirements
2. Context of Requirements
Engineering
3. Requirements Engineering Process
4. Requirements Management
5. Requirements Development
6. Requirements Engineering in Model
7. Tool Support
M01 - Introduction to Requirements 2/23 | 11/427

12. M01 - Introduction to Requirements 3/23 | 12/427

13. 1. Lack of clear link to the organisation’s
key strategic priorities
2. Lack of clear senior management
ownership and leadership
3. Lack of effective engagement with stakeholders
4. Lack of skills and proven approach to project and risk
management
5. Project not broken down into manageable steps
6. Evaluation of proposals linked to short term affordability
rather than longer term value for money
7. Lack of understanding of and contact with suppliers
8. Lack of effective integration between
the client, supplier and supply chain
Reported by Office of
Government Commerce (OGC)
in respect of Gateway Reviews
M01 - Introduction to Requirements 4/23 | 13/427

14. Other
1%
Lack of Qualified
Resources
3%
Communication
Problems
14%
Inadequate Risk
Management
17%
Poor Scope Definition
15%
Poor Requirements
Definition
50%
Other
Lack of Qualified Resources
Communication Problems
Inadequate Risk Management
Poor Scope Definition
Poor Requirements Definition
ESI International survey of 2000
business professionals, 2005
M01 - Introduction to Requirements 5/23 | 14/427

15. The major reasons of projects' failure are problems with
requirements and communication
 Business requirements are not aligned with business real needs
The base for identifying, defining the business
requirements is Business Analysis which acts as a
“communication bridge” between client and supplier
ESI International survey of 2000
business professionals, 2005
M01 - Introduction to Requirements 6/23 | 15/427

16. Report from 2015 studied 50,000 projects
around the world, ranging from tiny
enhancements to massive systems
re-engineering implementations
M01 - Introduction to Requirements 7/23 | 16/427

17. Top 10 Reasons for Success
1. User Involvement
2. Executive Management Support
3. Clear Business Objectives
4. Optimizing Scope
5. Agile Process
6. Project Manager Expertise
7. Financial Management
8. Skilled Resources
9. Formal Methodology
10. Standard Tools and Infrastructure
Research by The Standish Group International Inc.
End User
involvement!
Not just customer
M01 - Introduction to Requirements 8/23 | 17/427

18. M01 - Introduction to Requirements 9/23 | 18/427

19. A requirement is [lEEE Std 610.12-1990]
1. A condition or capability needed by a stakeholder to solve a
problem or achieve an objective
2. A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard,
specification, or other formally imposed documents
3. A documented representation of a condition or capability as in 1
or 2
 Requirements should be preceded by descriptors like
 Business requirements
 User requirements
 Functional requirements (FR)
 Non-functional requirements (NFR)
1.1M01 - Introduction to Requirements 10/23 | 19/427

20. Requirement
Provide foundation
for project's
assessment,
planning, execution
and monitoring
Defines customer
expectations
(stakeholders value)
Acting as
component of
agreements,
project plans
Establish system
boundaries, scope
of delivery
1.1M01 - Introduction to Requirements 11/23 | 20/427

21. 1.1
Customer
requirements
(business requirements)
Solution/system
requirements
Product/component
requirements
M01 - Introduction to Requirements 12/23 | 21/427

22. Requirement
Product
Functional
(FR)
External
Internal
Non-functional
(NFR)
External
Internal
Process
Needs and limitations of the business processes:
• Costs, marketing, processing time, sales and distribution,
organization, documentation
• May specify methodologies or frameworks to be followed
1.1M01 - Introduction to Requirements 13/23 | 22/427

23. Non-functional product
requirements:
 Specify how the system
performs its functions
 Describe the quality
attributes of the system
Functional product
requirements:
 Allow to specify what the
product should do
 Describe the function of the
product
1.1
WHAT HOW
M01 - Introduction to Requirements 14/23 | 23/427

24. M01 - Introduction to Requirements 15/23 | 24/427

25. 1.1
Requirements Engineering
Requirements
Management
Traceability of
Requirements
Configuration
and Change
Management
Quality
Assurance
(QA)
Requirements
Development
Requirements
Elicitation
Requirements
Analysis
Requirements
Specification
Requirements
Validation
and
Verification
According to CMMI, Requirements Engineering
encompasses Requirements Management and Requirements Development
M01 - Introduction to Requirements 16/23 | 25/427

26. Requirements Engineering discipline involves:
 Requirements elicitation
 Requirements analysis
 Requirements specification
 Requirements validation and verification
 Requirements traceability
 Configuration and change management
 Quality assurance
M01 - Introduction to Requirements 17/23 | 26/427

27. M01 - Introduction to Requirements 18/23 | 27/427

28. Describes the function, architecture, and design of software
Describes the process of development itself
All artefacts should be under version control (e.g. version
control, naming conventions, archiving, etc.)
Vison
Statement
Business Case Use Cases
Activity
diagrams
Class diagrams
Component
diagrams
Design
documents
Requirements
documentation
Project
documentation
Risk
assessment
1.1M01 - Introduction to Requirements 19/23 | 28/427

29.  Too formal description
 Instability of the requirements
 Bad quality of the requirements
 incomplete, not well described
 Over or under specified
 Gold plating
 Insufficient user involvement
 Overlooked stakeholders
 Inaccurate planning
 Minimal specification
(acceptable in case of Agile
approaches)
 Ambiguous, overly specified,
unclear, impossible,
contradictory requirements
 Unclear project goals
 Communication problems
 Wrong format for the wrong
audience
 Language barriers
 Culture barriers
 Knowledge barriers
 different domains; business vs
technology
 Vague formulation
1.1M01 - Introduction to Requirements 20/23 | 29/427

30. The requirements
specification must be:
 Traceable
 Complete
 Consistent
 Modifiable
 Under change control
 Accessible
 Up to date and
communicated
A requirement must be:
 Complete
 Validatable
 Verifiable
 Testable
 Unambiguous
 Prioritized
 Feasible
 Necessary (depends in case
of Agile approaches and
MuSCoW prioritization)
1.1
Based on Karl Wiegers
M01 - Introduction to Requirements 21/23 | 30/427

31. M01 - Introduction to Requirements 22/23 | 31/427

32. I hope you enjoyed
this presentation. If so,
please like, share and
leave a comment
below.
Endorsements on
LinkedIn are also
highly appreciated! 
(your feedback = more free stuff)

MIROSLAWDABROWSKI.COM/downloads