BCS Requirements Engineering Practitioner

The requirements engineering certification is a key requirement for the following jobs:

• Business Analysts
• Requirements Engineers
• Project Managers
• Business Change Managers
• People who want to elicit, analyse, validate, document and manage requirements

Candidates can achieve this certification by passing the following exam(s).

• RE18: BCS Practitioner Certificate in Requirements Engineering

The Requirements Engineering certification exam if included in your course can be registered and attempted within 3 months of course/module completion at Logitrain training centre on weekdays during normal business hours (excludes public holidays)

• Introduction to Requirements Engineering
• Hierarchy of Requirements
• Stakeholders in the Requirements Process
• Requirements Elicitation
• Use of Models in Requirements Engineering
• Requirements Documentation
• Requirements Analysis
• Requirements Validation
• Requirements Management

This course is likely to add to the employment-related skills of the participants. The skills developed are likely to be used in the course of being an employee or working in a business.

Following people can attend Requirements Engineering training

• Business Analysis Graduates
• Business Analysts
• Requirement Engineers
• People aspiring to become Business Analysts or Requirement Engineers

• Define the term ‘requirements’ and the characteristics of a requirement.
• Explain the rationale for Requirements Engineering and the application of the Requirements Engineering framework.
• Explain the rationale of requirements planning and estimating.
• Describe the elements that should be considered as the contents of a project initiation document, terms of reference or project charter: Business objectives; Project objectives; Scope; Constraints (budget, timescale, standards); Authority or sponsor; Resources; Assumptions.
• Show understanding of the rationale for the requirements hierarchy and describe how it is applied in Requirements Engineering.
• Explain the categories within the hierarchy: Business policy (general) requirements; Technical policy requirements; Functional requirements; Non-functional requirements.
• Define the term stakeholder.
• Explain the key roles of the following project stakeholders during Requirements Engineering: Project Manager; Developer; Tester; Solution Architect.
• Explain the key roles of the following business stakeholders during Requirements Engineering: Project Sponsor; Subject Matter Expert; End User; Business Manager.
• Interpret a given scenario, identify stakeholders and describe their contribution to Requirements Engineering.
• Explain different knowledge types: Tacit / Non-tacit (explicit); Individual / Corporate.
• Interpret a given scenario to identify different knowledge types.
• Interpret a given scenario to identify relevant elicitation techniques from the following list: Interviews; Workshops; Observation; Focus groups; Prototyping; Scenario analysis; Document analysis; Surveys; Record searching; Special purpose records; Activity sampling.
• Describe the principles and application of the elicitation techniques.
• List the advantages and disadvantages of the elicitation techniques.
• Discuss the suitability of the elicitation techniques for Agile and linear development approaches.
• Explain the rationale for modelling the functional requirements (processing and data) of an information system and describe how models help the analyst to: Generate questions in order to clarify a requirement and remove ambiguity; Define business rules; Cross-check requirements for consistency and completeness.
• Interpret a given scenario to develop a context diagram.
• Interpret a given scenario to identify the different types of event that can initiate processing (external, time based, internal).
• Understand how to construct a UML use case diagram for a given scenario to represent the functional requirements for an information system.
• 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.
• 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).
• Explain the rationale for creating a requirements document and for documenting requirements at different levels of definition.
• Understand how to construct requirements documentation for a given scenario.
• Describe a requirement in terms of its characteristics or attributes and explain why each of the following may be needed: Identifier; Name; Description; Source; Owner; Author; Type (general, technical, functional, non-functional); Priority; Business area; Stakeholders; Associated non-functional requirements; Acceptance criteria; Related requirements; Related documents; Comments; Rationale; Resolution; and Version history.
• Describe the structure and contents of the requirements document.
• Explain the rationale for prioritising requirements, using the MoSCoW prioritisation technique.
• Interpret a given scenario and apply the MoSCoW prioritisation technique.
• Examine individual requirements; apply filters and quality criteria to assess that they are well defined.
• Use requirements for a given scenario to check for technical, business and financial feasibility.
• Assign a requirement type to an individual requirement.
• Organise the requirements for a given scenario by requirement type and functional area.
• Explain the use of prototyping to elaborate requirements.
• Describe the rationale for the following approaches to requirements validation: Informal reviews & Formal reviews.
• Explain the steps to be followed in the validation process for requirements artefacts.
• Explain the rationale for requirements management.
• Define the elements of requirements management and the links between them.
• Explain the structure and elements of a change control process.
• Explain the structure and elements of version control.
• Define two forms of traceability and how projects benefit from each of them: Horizontal (forwards from origin to delivery and backwards from delivery to origin) & Vertical (to business objectives).
• Explain the rationale and the approach to achieving requirements traceability.