1. Home
  2. BCS
  3. RE18 Exam Syllabus

BCS RE18 Exam Topics

BCS RE18 Exam Overview :

Exam Name: BCS Practitioner Certificate in Requirements Engineering 2018
Exam Code: RE18
Certifications: BCS Business Analysis Certification
See Expected Questions: BCS RE18 Expected Questions in Actual Exam

BCS RE18 Exam Objectives :

Section Weight Objectives
1. Introduction to Requirements Engineering 5% 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% 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% 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% 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% 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).
Requirements Documentation 15% 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% 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% 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.
Requirements Management 10% 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.
Official Information https://www2.bcs.org/certifications/ba/requirements-engineering

Updates in the BCS RE18 Exam Topics:

BCS RE18 exam questions and practice test are the best ways to get fully prepared. Study4exam's trusted preparation material consists of both practice questions and practice test. To pass the actual  Business Analysis RE18  exam on the first attempt, you need to put in hard work on these questions as they cover all updated  BCS RE18 exam topics included in the official syllabus. Besides studying actual questions, you should take the  BCS RE18 practice test for self-assessment and actual exam simulation. Revise actual exam questions and remove your mistakes with the BCS Practitioner Certificate in Requirements Engineering 2018 RE18 exam practice test. Online and Windows-based formats of the RE18 exam practice test are available for self-assessment.

Limited Time Offer

50%

Off

Get Premium RE18 Questions as Interactive Practice Test or PDF