EXIN BCS Practitioner Certificate in Requirements Engineering (RQE) Exam Syllabus

• Service description
• Service value proposition
• Service activities
• Service techniques

- Guidance

• Candidates will be tested on their ability to describe what a requirement is, and the requirements definition service, including its Value Proposition, Activities and Techniques, as per the Business Analysis Service Framework (BASF).

• a.
• b. Planning the requirements approach
  - Describe how each of the following have an impact planning an RE approach:
  1. Project approach
  2. Organizational standards in place
  3. Stakeholders involved
  4. Techniques to be used
  5. Requirement documentation to be produced

- Guidance

• Candidates will be tested on their ability to describe every stage of the RE Framework -Elicitation, Analysis, Documentation, Validation and Management - and the types of activities that the Business Analyst (BA) undertakes at each stage.
• Candidates will also be tested on their ability to describe the considerations that should be made when planning for a RE activity.
• A BA should be able to use the RE Framework in a project from start to finish. However, it is common for BAs to be brought in part way through a project. Therefore, it is important that BAs are able to quickly understand ongoing projects and act accordingly.
• Candidates will be tested on their ability to analyze a given scenario and explain which stage of the RE Framework is applicable and provide appropriate responses and actions to the scenario.

• Workshops (including techniques that can be used during a workshop)
• Interviews (including questioning techniques that can be used during an interview)
• Document analysis
• Scenario’s
• Storytelling
• Prototypes (low and high fidelity)
• Observation
• User role analysis

- Guidance

• Elicitation is concerned with purposefully extracting requirements from stakeholders.
• To successfully elicit requirements, Business Analysts (BA) will need to apply a combination of elicitation techniques to ensure the appropriate volume and depth of information is secured for analysis. Understanding knowledge types (tacit and explicit) is integral to the requirements elicitation approach.
• Candidates will be tested on their ability to explain how the different methods of elicitation are executed, how the method supports the extraction of the different types of knowledge and what potential outcomes can be expected when the elicitation technique is applied.

• Selecting the appropriate type of prototype (low/high fidelity; throwaway or evolutionary)
• Visualization of requirements
• Increase stakeholder understanding
• Managing expectations when using a prototype
• Extended use of prototypes to support analysis and documentation

- Guidance

• Prototyping can take many forms such as manual/hand drawn mock-ups, images of screens, genuine software development etc. The useful common feature and purpose of these prototypes is the creation of visual or physical example, with which stakeholders can interact and provide feedback on.
• Candidates will be tested on their ability to explain which type of prototype might be appropriate for a given scenario, how they might use it and what outcomes they should anticipate.

• How to select an appropriate elicitation technique
• Plan/prepare for its use
• Explain execution of technique
• Describe the anticipated outcome/output

- Guidance

• Candidates will be tested on their ability to analyze a given scenario and apply appropriate elicitation techniques.

• Business (general, technical)
• Solution (functional, non-functional)

- Guidance

• Each type of requirement focuses on different aspects of the future solution. Therefore, it is important that the candidates can confidently categorize requirements by type.
• Candidates will be tested on their ability to describe the different types of requirements. Candidates will also be tested on their ability to review a given requirement and identify the type.

• Diagrammatic documentation such as data model, function model, business activity model, business process model
• Text-based documentation, such as requirements catalogue, business requirements documentation (BRD), user story, backlogs
• Selecting the appropriate style(s) of documentation

- Guidance

• It is important to clearly define what should be delivered. While there are different approaches to documenting the different aspects of requirements, the main focus is to provide it in an easily accessible format and to select the appropriate documentation for the project approach. Consistency of documentation promotes effective communication between stakeholders and the basis of subsequent analysis and validation.
• Candidates will be tested on their ability to explain the different styles of requirements documentation and will also be assessed on their ability to apply best practice to requirements authoring.

• Issues that contribute to poorly articulated or incomplete expressions of need
• Tasks undertaken as part of requirements analysis (such as refining, categorising, prioritising and modelling)
• Goal of analysing requirements

- Guidance

• When multiple elicitation techniques have been used to extract requirement information, the output can often take multiple forms, contain different levels of detail or understanding. The Business Analyst (BA) must recognise that raw output from the selected elicitation techniques, needs to be analysed both in terms of each individual requirement and as a collective or “set” of requirements.
• Candidates will be tested on their ability to explain the types of issues that might be encountered following requirements elicitation and why they may occur. They will also be able to describe how they will assess whether the output from requirements analysis is complete, well organised and appropriately documented.

• Unravelling multiple requirements
• Checking for overlapping or duplicate
• Removing conflicts
• Evaluating feasibility
• Confirming relevance of the requirement
• Checking for solutions

- Guidance

• Once requirements have been elicited and captured initially in some form of documentation, it is important to conduct requirement analysis to ensure that each requirement is distinct and belongs as part of the set. Analysis filters are criteria used to analyse and refine requirements. They help to identify ambiguities and inconsistencies.
• Candidates will be tested on their ability to describe a technique to refine a set of requirements, for a given scenario. They will be able to identify the issues they have encountered within the scenario and the techniques that would be appropriate to resolve them.

• INVEST
• Quality criteria:
  - Clear
  - Concise
  - Relevant
  - Unambiguous
  - Correct
  - Testable
  - Traceable

- Guidance

• In addition to being part of a well-formed set of requirements, each individual requirement should meet a clearly defined set of criteria to be considered wellformed, clear and complete.
• Candidates will be tested on their ability to define a requirement statement for a given scenario, ensuring it meets the quality characteristics or explaining why it does not.

• Slicing/splitting requirements
• Analysing Business Rules
• Categorising requirements
• Requirements Hierarchy
• Prioritising requirements (including MoSCoW, Priority Levels, Kano, WSJF, AHP)
• Modelling to analyse requirements (such as CRUD matrix, data models (UML/ERD class models), functional models, activity models, business process models, customer journey mapping)

- Guidance

• These additional requirements analysis techniques support the Business Analyst (BA) in ensuring the requirements they produce are well formed, within the agreed scope and boundary of the project, appropriately presented and truly represent the needs of the business.
• Candidates will be tested on their ability to explain the different methods. They will need to be able to explain the purpose of each type of analysis and what would be achieved by applying it. The candidate will also be tested to their ability to explain why and how requirements should be organised in readiness for requirements validation.

• The objective of validating requirements
• Confirm requirements are accurate
• Validate that requirements are aligned to business goals, project and business objectives and scope
• Agree requirements are suitable for solution design and build activities
• In Linear projects: agree acceptance criteria is clearly defined, understood and agreed as a basis for User Acceptance Testing (UAT)
• In Agile projects: agree requirements form an appropriate basis for further elaboration

- Guidance

• Requirements validation involves the review of requirements conducted by a selected group of stakeholders with the aim to agree that the requirements state the features and characteristics fulfilled by the solution.
• Candidates will be tested on their ability to explain the purpose of validating requirements, to justify the need for validation, and the consequences if they are not validated.

• Business Analyst (BA)
• Business sponsor
• Business owners
• SMEs
• Solutions architect
• Developers
• Testers
• Project office representatives

- Guidance

• Validation should include people who represent key project or business roles. Each role has a different responsibility when validating the requirements, and each comes with their own perspective. It is important to obtain validation from different perspectives.
• Candidates will be tested on their ability to explain the roles and responsibilities of the review group during requirements validation.

• Informal review - Agile/Linear
• Formal review - Agile/Linear
• Possible outcomes of requirements validation
  - Rejected - rework required
  - Amendment required
  - ​Agreed - signed off/baselined requirements, backlog established or ‘ready’ status
• The two stages of Agile requirements validation

- Guidance

• The approach to validation may vary depending on the project approach and the availability of stakeholders.
• Candidates will be tested on their ability to explain the reasoning for various approaches to requirements validation, and when in the Requirements Engineering (RE) Framework they should occur.
• Candidates will also be tested on their ability to describe for a given scenario how a requirement validation review would be planned and executed, along with the action they should take for each possible outcome.

• Rationale for when requirements management occurs in the Requirements Engineering (RE) Framework
• Elements of requirements management
  - Identification
  - Cross-referencing
  - Origin and ownership
  - Software support
  - Change control
  - Configuration management
  - Maintaining traceability
  1. Horizontal traceability (backwards from, forwards to)
  2. Vertical traceability (trace up, trace down)

- Guidance

• During the Elicitation, Analysis and Documentation stages of the RE Framework, key information about each requirement is captured. Once the requirement has been agreed, during Validation, that information must be kept up to date, while the solution is being developed. Requirements management ensures this maintenance occurs, providing ongoing traceability which is particularly useful in times of solution negotiation or business change. Good requirements management will allow the Business Analyst (BA) to respond effectively during ongoing project activities.
• Candidates will be tested on their ability to explain the purpose and rationale of requirements management and to describe the main elements of requirements management.

• Change control process
• Possible outcomes: implement or reject
• The impact of change to configuration management

- Guidance

• Change control is a vital element of requirements management, the purpose of which is to create a robust audit trail of any changes made to requirements and ensure that any changes made are impact assessed and justified.
• Candidates will be tested on their ability to apply a change control process to a given scenario and explain how the change would impact any artefacts subject to configuration management.