REQB® - Foundation Level Requirements Manager

REQ

Bis

atr

adem

ark

of G

loba

l Ass

ocia

tion

for S

oftw

are

Qua

lity,

GAS

Q G

mbH

Start and finish Course style

LunchCoffee and breaks

M00 - Course introduction 2/9 | 2/427

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


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


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


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


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

quizlet.com/63625322/


twitter.com/mirodabrowski

linkedin.com/in/miroslawdabrowskigoogle.com/+miroslawdabrowski

miroslaw_dabrowski

www.miroslawdabrowski.com

Mirosław DąbrowskiAgile 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, independenttrainer 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 …


1. Introduction to Requirements2. Context of Requirements

Engineering3. Requirements Engineering Process4. Requirements Management5. Requirements Development6. Requirements Engineering in Model7. Tool Support

M01 - Introduction to Requirements 2/23 | 11/427


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 stakeholders4. Lack of skills and proven approach to project and risk

management5. Project not broken down into manageable steps6. Evaluation of proposals linked to short term affordability

rather than longer term value for money7. Lack of understanding of and contact with suppliers8. Lack of effective integration between

the client, supplier and supply chain

Reported by Office of Government Commerce (OGC) in respect of Gateway Reviews


Other1%

Lack of Qualified Resources

3%

Communication Problems

14%

Inadequate Risk Management

17%

Poor Scope Definition15%

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


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


Report from 2015 studied 50,000 projects around the world, ranging from tiny enhancements to massive systemsre-engineering implementations


Top 10 Reasons for Success1. User Involvement2. Executive Management Support3. Clear Business Objectives4. Optimizing Scope5. Agile Process6. Project Manager Expertise7. Financial Management8. Skilled Resources9. Formal Methodology10. Standard Tools and Infrastructure

Research by The Standish Group International Inc.

End User involvement!

Not just customer



A requirement is [lEEE Std 610.12-1990]1. A condition or capability needed by a stakeholder to solve a

problem or achieve an objective2. 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

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

Customer requirements

(business requirements)

Solution/system requirements

Product/component requirements


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


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



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


Requirements Engineering discipline involves: Requirements elicitation Requirements analysis Requirements specification Requirements validation and verification Requirements traceability Configuration and change management Quality assurance



Describes the function, architecture, and design of softwareDescribes the process of development itselfAll 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


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


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



I hope you enjoyed this presentation. If so, please like, share and

leave a commentbelow.

Endorsements on LinkedIn are also

highly appreciated! (your feedback = more free stuff)

MIROSLAWDABROWSKI.COM/downloads

Education

REQB® - Foundation Level Requirements Manager