Opleiding: BCS Practitioner Certificate in Requirements Engineering (incl. examen)

BCS training: Practitioner Certificate in Requirements Engineering (incl. examen)

Een 3-daagse training ‘Requirements Engineering Practice’ training ter voorbereiding op het BCS examen. De training behandelt de concepten, benaderingen en technieken die van toepassing zijn op het Practitioner Certificate in Requirements Engineering van BCS. Het examen is inbegrepen bij deze training.

Voor wie?

Het Practitioner certificaat is geschikt voor iedereen die inzicht wil krijgen in de die de klant, business en requirements spelen binnen bedrijfscontexten. De training is geschikt voor business analisten, project managers, systeemanalisten, product eigenaren, productmanagers en degenen die betrokken zijn bij zakelijke veranderingsprocessen en/of projecten.

Wat levert deze training jou op?

In deze training worden de volgende onderwerpen besproken:

• The Requirements Engineering Framework
• How to elicit requirements and techniques to use
• How to collaborate and communicate with stakeholders in the requirements process
• How to write a user story
• Best practice approaches to document requirements
• How to manage requirements
• Validating, prioritising and quality assurance in the requirements process
• Analysing and evaluation of requirements

Taal

Deze training wordt in het Engels en Nederlands gegeven.

Lesmateriaal

Bij de training ontvang je passend lesmateriaal.

Inclusief examenvoucher

Bij deze training is een examenvoucher voor het ‘Practitioner Certificate in Requirements Engineering’ examen inbegrepen. Na het volgen van de training kan je zelf het examen inplannen. Het examen bestaat uit 40 meerkeuzevragen en duurt 60 minuten.

Vervolgtraining

Bekijk ook onze andere BCS trainingen.

Lesprogramma

1. Introduction to Requirements Engineering 5%
Candidates will be able to:
1.1 Define the term ‘requirements’ and the characteristics of a requirement.
1.2 Explain the rationale for Requirements Engineering and the application of the
Requirements Engineering framework.
1.3 Explain the rationale of requirements planning and estimating.
1.4 Describe the elements that should be considered as the contents of a project
initiation document, terms of reference or project charter:
1.4.1 Business objectives.
1.4.2 Project objectives.
1.4.3 Scope.
1.4.4 Constraints (budget, timescale, standards).
1.4.5 Authority or sponsor.
1.4.6 Resources.
1.4.7 Assumptions.

2 Hierarchy of Requirements 10%
Candidates will be able to:
2.1 Show understanding of the rationale for the requirements hierarchy and describe how
it is applied in Requirements Engineering.
2.2 Explain the categories within the hierarchy:
2.2.1 Business policy (general) requirements.
2.2.2 Technical policy requirements.
2.2.3 Functional requirements.
2.2.4 Non-functional requirements.

3 Stakeholders in the Requirements Process 5%
Candidates will be able to:
3.1 Define the term stakeholder.
3.2 Explain the key roles of the following project stakeholders during Requirements
Engineering:
3.2.1 Project Manager.
3.2.2 Developer.
3.2.3 Tester.
3.2.4 Solution Architect.
3.3 Explain the key roles of the following business stakeholders during Requirements
Engineering:
3.3.1 Project Sponsor.
3.3.2 Subject Matter Expert.
3.3.3 End User.
3.3.4 Business Manager.
3.4 Interpret a given scenario, identify stakeholders and describe their contribution to
Requirements Engineering.

4 Requirements Elicitation 20%
Candidates will be able to:
4.1 Explain different knowledge types:
4.1.1 Tacit / Non-tacit (explicit).
4.1.2 Individual / Corporate.
4.2 Interpret a given scenario to identify different knowledge types.
4.3 Interpret a given scenario to identify relevant elicitation techniques from the following
list:
4.3.1 Interviews.
4.3.2 Workshops.
4.3.3 Observation.
4.3.4 Focus groups.
4.3.5 Prototyping.
4.3.6 Scenario analysis.
4.3.7 Document analysis.
4.3.8 Surveys.
4.3.9 Record searching.
4.3.10 Special purpose records.
4.3.11 Activity sampling.
4.4 Describe the principles and application of the elicitation techniques (listed in 4.3).
4.5 List the advantages and disadvantages of the elicitation techniques (listed in 4.3).
4.6 Discuss the suitability of the elicitation techniques (listed in 4.3) for Agile and linear
development approaches.

5 Use of Models in Requirements Engineering 10%
Candidates will be able to:
5.1 Explain the rationale for modelling the functional requirements (processing and data)
of an information system and describe how models help the analyst to:
5.1.1 Generate questions in order to clarify a requirement and remove ambiguity.
5.1.2 Define business rules.
5.1.3 Cross-check requirements for consistency and completeness.
5.2 Interpret a given scenario to develop a context diagram.
5.3 Interpret a given scenario to identify the different types of event that can initiate
processing (external, time based, internal).
5.4 Understand how to construct a UML use case diagram for a given scenario to
represent the functional requirements for an information system, including the
following notational elements:
5.4.1 System boundary.
5.4.2 Actors (user role, another system and time).
5.4.3 Use cases.
5.4.4 Communication relationships (associations) between actors and use cases.
– It should be noted that there is no requirement to understand include and extend
constructs.
5.5 Interpret a UML Class diagram (comprising of classes, attributes, associations and
multiplicities) that represents the data requirements for a given scenario, and
describe the business rules that are represented.
– It should be noted that there is no requirement to understand operations,
association classes, generalisation (and associated concepts of inheritance and
polymorphism), aggregation and composition.
5.6 Explain the benefits to be derived from cross-referencing models and illustrate how
this can be achieved by using a CRUD matrix (of function or event against data).

6 Requirements Documentation 15%
Candidates will be able to:
6.1 Explain the rationale for creating a requirements document and for documenting
requirements at different levels of definition, relating to:
6.1.1 The nature of the solution.
6.1.2 The level of priority.
6.1.3 The delivery approach.
6.2 Understand how to construct requirements documentation for a given scenario, using
the following specified styles:
6.2.1 User story.
6.2.2 Use case.
6.2.3 Requirements list.
6.2.4 Requirements catalogue.
6.3 Describe a requirement in terms of its characteristics or attributes and explain why
each of the following may be needed:
6.3.1 Identifier.
6.3.2 Name.
6.3.3 Description.
6.3.4 Source.
6.3.5 Owner.
6.3.6 Author.
6.3.7 Type (general, technical, functional, non-functional).
6.3.8 Priority.
6.3.9 Business area.
6.3.10 Stakeholders.
6.3.11 Associated non-functional requirements.
6.3.12 Acceptance criteria.
6.3.13 Related requirements.
6.3.14 Related documents.
6.3.15 Comments.
6.3.16 Rationale.
6.3.17 Resolution.
6.3.18 Version history.
6.4 Describe the structure and contents of the requirements document:
6.4.1 Introduction and background.
6.4.2 Business process models.
6.4.3 Function model (use case diagram) of defined requirements.
6.4.4 Data model (class model) of defined requirements.
6.4.5 Requirements (defined using the selected documentation style).
6.4.6 Glossary.

7 Requirements Analysis 20%
Candidates will be able to:
7.1 Explain the rationale for prioritising requirements, using the MoSCoW prioritisation
technique.
7.2 Interpret a given scenario and apply the MoSCoW prioritisation technique.
7.3 Examine individual requirements; apply filters and quality criteria to assess that they
are well defined.
7.4 Use requirements for a given scenario to check for technical, business and financial
feasibility.
7.5 Assign a requirement type to an individual requirement.
7.6 Organise the requirements for a given scenario by requirement type and functional
area.
7.7 Within a given requirement set:
7.7.1 Identify and resolve duplicate requirements.
7.7.2 Identify and reconcile overlapping requirements.
7.7.3 Identify conflicting requirements and explain how requirements negotiation
could be applied to resolve these conflicts.
7.7.4 Identify ambiguous requirements and aspects to be defined to remove
ambiguity.
7.8 Explain the use of prototyping to elaborate requirements.

8 Requirements Validation 5%
Candidates will be able to:
8.1 Describe the rationale for the following approaches to requirements validation:
8.1.1 Informal reviews.
8.1.2 Formal reviews:
8.1.2.1 Structured walkthrough.
8.1.2.2 Prototype reviews.
8.2 Explain the steps to be followed in the validation process for requirements artefacts:
8.2.1 Plan review.
8.2.2 Conduct review of artefacts.
8.2.3 Collect comments.
8.2.4 Undertake actions.
8.2.5 Revise artefacts.
8.2.6 Obtain approval.

9 Requirements Management 10%
Candidates will be able to:
9.1 Explain the rationale for requirements management.
9.2 Define the elements of requirements management and the links between them.
9.3 Explain the structure and elements of a change control process.
9.4 Explain the structure and elements of version control.
9.5 Define two forms of traceability and how projects benefit from each of them:
9.5.1 Horizontal (forwards from origin to delivery and backwards from delivery to
origin).
9.5.2 Vertical (to business objectives).
9.6 Explain the rationale and the approach to achieving requirements traceability..

Lesmethodes

Kies de lesmethode die het best bij je past. Deze training kun je op de volgende manieren volgen:

• Online hybride training

  Een live trainer geeft de training in de klas en je volgt deze training online (vanuit huis of kantoor). Je hebt direct contact met de trainer en andere deelnemers die fysiek in de klas of online deelnemen.

• Klassikaal op locatie

  Deze training wordt gegeven op verschillende trainingslocaties in Nederland. Net als bij de Virtual Classroom training zijn er medewerkers van verschillende bedrijven aanwezig. Volledig verzorgd, inclusief uitgebreide lunch.

• In-company / Maatwerk

  In een op maat gemaakte training wordt alleen datgene behandeld dat relevant is voor jouw werksituatie en/of bedrijf. Dit maakt deze training zeer effectief. Beschikbaar in het Nederlands, Engels en Duits. Afhankelijk van het aantal deelnemers kan de korting wel oplopen tot 50% t.o.v. de Klassikale Training. Meer info of scherpe offerte aanvragen.

Microsoft Partner – Silver Data Analytics

SignOn bezit de status Microsoft Partner – Silver Data Analytics en toont daarmee aan dat de kennis, vaardigheden en prestaties van een bijzonder hoog niveau zijn. We laten hiermee zien volledig op de hoogte te zijn van de nieuwste technieken over Microsoft Power BI en Big Data.

Microsoft Certified Trainers

Onze Microsoft Certified Trainers (MCT) zijn experts in hun vakgebied en gecertificeerd volgens de voorwaarden van Microsoft. Naast het geven van trainingen werken ze ook in projecten en kennen als geen ander de dagelijkse praktijk. Daardoor weten zij waar cursisten dagelijks mee te maken krijgen en tegen aan kunnen lopen. Zij gebruiken hun praktijkervaring ter verrijking van de theorie in de klas.

Cedeo erkenning: wat betekent dit voor u?

Cedeo is een begrip als het gaat om opleidingen. Er zijn circa 300 Cedeo-erkende instituten in Nederland. Met een keuze voor een Cedeo-erkende leverancier weet u daarom zeker dat u een keuze maakt voor één van de betere opleidingsinstituten.

SignOn en het UWV

SignOn ICT Trainingen+ is erkend scholingspartner van het UWV. SignOn ICT Trainingen+ is één van de weinige ICT opleidingen organisaties die door het UWV erkend is om opleidingen te verzorgen om mensen weer te helpen bij het terugkeren in het arbeidsproces.