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
M00 - Course introduction 3/9 | 3/523
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/523
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/523
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/523
REQB syllabus section code and title1 Basics
2 Processes models and management
3 Project and Risk Management
4 Identification of Requirements
5 Specification and Documentation of Requirements
6 Requirements Analysis
7 Techniques and Strategies for Conflict Resolution
8 Quality Assurance
9 Tools
Module slide number / total module slides
Slide number / total slides
Module number and name
REQB syllabus section code
SyllabusM00 - Course introduction 7/9 | 7/523
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 …
M00 - Course introduction 9/9 | 9/523
1. Fundamentals of requirement engineering
2. Processes models and management3. Project and risk management4. Identification of requirements5. Specification and documentation of
requirements6. Requirements analysis7. Techniques and strategies for conflict
resolution8. Quality assurance9. Tools
M01 - Fundamentals of requirement engineering 2/27 | 11/523
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
M01 - Fundamentals of requirement engineering 3/27 | 12/523
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
M01 - Fundamentals of requirement engineering 4/27 | 13/523
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 - Fundamentals of requirement engineering 5/27 | 14/523
Report from 2015 studied 50,000 projects around the world, ranging from tiny enhancements to massive systemsre-engineering implementations
M01 - Fundamentals of requirement engineering 6/27 | 15/523
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
M01 - Fundamentals of requirement engineering 7/27 | 16/523
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 - Fundamentals of requirement engineering 9/27 | 18/523
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 - Fundamentals of requirement engineering 10/27 | 19/523
Requirements should be proceeded by descriptors like: Business requirements User requirements Functional requirements Non-functional requirements
1.1M01 - Fundamentals of requirement engineering 11/27 | 20/523
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 - Fundamentals of requirement engineering 12/27 | 21/523
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 - Fundamentals of requirement engineering 13/27 | 22/523
Customer requirements
(business requirements)
Solution/system requirements
Product/component requirements
1.1M01 - Fundamentals of requirement engineering 14/27 | 23/523
Requirements Engineering Sub-discipline of System Engineering, focused on determining, developing and
managing the requirements of hardware and software systems According to CMMI, Requirements Engineering encompasses Requirements
Management and Requirements Development.
Requirements Management A continuous process of eliciting, documenting, analyzing, tracing, prioritizing,
communicating, agreeing on requirements and managing requirements' changes
Requirements Development Collection of activities, tasks, techniques and tools to identify, analyze and
validate requirements on the different abstraction levels
1.1M01 - Fundamentals of requirement engineering 17/27 | 26/523
Requirements DeveloperA technical oriented person mainly
involved in the Elicitation, Analysis and prioritizing of requirements
Requirements ManagerA person responsible for documenting,
analyzing, tracing, prioritizing and agreeing on requirements and then
controlling change and communicating to relevant stakeholders
The two roles are complimentary
1.1M01 - Fundamentals of requirement engineering 18/27 | 27/523
Requirements Engineering discipline involves: Requirements elicitation Requirements analysis Requirements specification Requirements validation and
verification Requirements traceability Configuration and change
management Quality assurance
M01 - Fundamentals of requirement engineering 19/27 | 28/523
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.)
1.1
Vison Statement Business Case Use Cases Activity
diagrams
Class diagrams Component diagrams
Design documents
Requirements documentation
Project documentation Risk assessment
M01 - Fundamentals of requirement engineering 21/27 | 30/523
Traceability is an association that exists between different types of requirements and: Requirements (mapping the higher level requirements that defined
the needs and features to the more detailed requirements) Detailed requirements and design models Detailed requirements and test cases (e.g., for system testing) High level requirements and test cases (e.g., for acceptance test) Requirements and design artefacts
Requirement Model Source Code Object
• Bidirectional traceability from requirements to software architecture to code.
• Bidirectional traceability from requirements to test cases.
M01 - Fundamentals of requirement engineering 22/27 | 31/523
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 missing stakeholders groups
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 - Fundamentals of requirement engineering 24/27 | 33/523
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 - Fundamentals of requirement engineering 25/27 | 34/523
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