Certificate in Requirements Engineering Practitioner

Certificate in Requirements Engineering Practitioner

This certificate is concerned with the Requirements Engineering approach to requirements definition. Its focus is on using a systematic approach to eliciting, analysing, validating, documenting and managing requirements. This certification also counts towards the Diploma in Business Analysis.

What are the learning outcomes?

Candidates are required to be able to understand and explain the Requirements Engineering approach and to adopt relevant techniques at all stages of this approach.

The syllabus requires that the candidate should be able to describe the following aspects of the approach:

The structure (for example, phases and connections between phases)
The activities (for example, the tasks and possible techniques)
For further information please read the syllabus

Who is it aimed at?

The certificate is relevant to anyone requiring an understanding of requirements engineering, including business analysts, business managers and their staff, business change managers and project managers.

Entry Requirements:

There are no formal requirements for entry to the course however candidates should be suitably prepared and possess the appropriate skills and knowledge to fulfil the objectives.

Certificate in Requirements Engineering Syllabus

Syllabus ……………………………………………………………………………………………………………..7
1.
2.
Introduction to Requirements Engineering (5%) …………………………………………………7
1.1 Framework for Requirements Engineering 7
􏰀 Requirements Engineering activities – Elicitation, Analysis, Validation,
Documentation, Management 7
􏰀 Rationale for Requirements Engineering and the problems with requirements 7
􏰀 The importance of requirements planning and estimating 7
1.2 The business rationale and inputs 7
􏰀 The business case 7
􏰀 Terms of Reference / Project Initiation Document (PID) 7
Hierarchy of requirements (10%)………………………………………………………………………7
2.1 Building the hierarchy 7
2.2 Categories of requirements within the hierarchy 7
􏰀 General business requirements, including legal and business policy 7
􏰀 Technical policy requirements 7
􏰀 Functional requirements 7
􏰀 Non-functional requirements, including performance, usability, access, security,
archiving, back up and recovery, availability, robustness 7
Copyright © BCS 2012 Page 2 of 15 RE Syllabus
Version 2.2 September 2012
3. Stakeholders in the requirements process (5%) …………………………………………………7
3.1 Project Stakeholders 7
􏰀 Project Manager 7
􏰀 Business Analysis 7
􏰀 Developer 7
3.2 Business Stakeholders 7
􏰀 Project Sponsor 7
􏰀 Subject matter expert 7
􏰀 End users and managers 7
3.3 External stakeholders 7
􏰀 Customers 7
􏰀 Regulators 7
􏰀 Suppliers - products and services 7
4. Requirements Elicitation (20%) ……………………………………………………………………….8
4.1 Knowledge types – tacit and non-tacit 8
4.2 Elicitation techniques 8
􏰀 Interviews 8
􏰀 Workshops 8
􏰀 Observation: 8
o Formal/informal 8 o Shadowing 8
􏰀 Focus groups 8
􏰀 Prototyping 8
􏰀 Scenarios 8
􏰀 Document Analysis 8
􏰀 Special purpose records 8
􏰀 Questionnaires 8
4.3 Understanding the applicability of techniques 8
5. Use of models in Requirements Engineering (10%) ……………………………………………8
5.1 The purpose of modelling requirements 8
􏰀 Generating questions 8
􏰀 Cross-checking for consistency and completeness 8
􏰀 Defining business rules 8
5.2 Modelling the business context for the system 8
5.3 Developing a model to represent the system processing requirements 8
5.4 Interpreting a data model 8
Copyright © BCS 2012 Page 3 of 15 RE Syllabus
Version 2.2 September 2012
6.
Requirements Documentation (15%)…………………………………………………………………8
6.1 Documentation styles and levels of definition 8
6.2 Requirements Catalogue 8
􏰀 Identifier 8
􏰀 Name 8
􏰀 Description 8
􏰀 Acceptance criteria 8
􏰀 Source/Owner 8
􏰀 Rationale/Benefits 8
􏰀 Non-functional requirements 8
􏰀 Priority 8
􏰀 Related requirements/documents 8
􏰀 Author 8
􏰀 Version control/status 8
􏰀 Change history 8
Requirements Analysis (20%) ………………………………………………………………………….9
7.1 Prioritising and packaging requirements for delivery 9
7.2 Organising requirements 9
7.3 Ensuring well-formed requirements 9
7.4 Prototyping requirements 9
7.5 Verifying requirements 9
Requirements Validation (5%)…………………………………………………………………………9
8.1 Agreeing the requirements document 9
8.2 Types of reviews 9
8.3 Stakeholders and their areas of concern 9
Requirements Management (10%)…………………………………………………………………..9
9.1 Dealing with changing requirements 9
9.2 The importance of traceability 9
􏰀 Vertical traceability (to business objectives) 9
􏰀 Horizontal traceability (from origin to deliver) 9
9.3 Traceability and ownership 9
9.4 Requirements Engineering support tools 9

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License