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

• “A feature which business staff need a system (business or IT) to provide.”

- Guidance

• Candidates should be able to provide a definition of the term “requirements” as per Business Analysis 4th Edition.

- Indicative content

- Guidance

• The requirements engineering framework, as shown, demonstrates the relationship between the typical stages of the requirements engineering process. The non-linear nature of this framework should be noted, allowing for flexibility in the order of completion of these stages, and repetition as required. Note that stakeholder engagement and consultation is necessary throughout this framework. This is explored further in topic 5.

1. Organizational standards
2. Project approach
3. Types of requirements
4. Nature of the solution

- Guidance

• The selected approach will vary, depending on a range of factors – candidates should have an understanding of how to identify and respond to these factors when planning their approach to requirements engineering in a given environment/own context.

1. OSCAR (Objectives, Scope, Constraints, Authority, Resources)
2. Rationale for aligning requirements with a business case and the objectives of the organization.

- Guidance

• The contents and use of the PID/ToR should be understood and how it is used to support the approach to requirements engineering, ensuring alignment with project and business objectives. Note that for the purpose of this preparation guide, the terms PID and ToR may be used interchangeably, as per the reference text.

• Tacit/non-tacit (explicit)
• Individual/corporate

- Guidance

• The ability to categorize and elicit both tacit and explicit knowledge is integral to the requirements engineering process. Elicitation is concerned with purposefully extracting requirements from stakeholders, a process which requires different skills and techniques to simply gathering knowledge. Candidates should consider things such as individual skills, corporate culture and other factors which may not be explicitly communicated through all elicitation techniques.

• Observe: observation, shadowing
• Recount: storytelling, scenario analysis
• Enact: prototyping, scenario role-play

- Guidance

• Certain techniques are more likely to be effective in the successful elicitation of tacit knowledge.

• Interviews
• Workshops
• Observation
• Shadowing
• Storytelling
• Scenario analysis
• Scenario role-play
• Prototyping
• Document analysis

- Guidance

• Candidates should understand the benefits and drawbacks of each of these techniques, to be able to evaluate their effectiveness and suitability in a range of circumstances. Consider how these techniques have evolved within different organizational contexts to take account of online working and collaboration. Note that additional techniques exist, but candidates should expect to be tested only on those listed.

• Project approach
• Resources (time, documentation, technology)
• Stakeholder expertise

- Guidance

• Appreciating that many factors can impact the effectiveness of an elicitation technique - such as those listed - candidates should be able to select a technique suitable to a particular circumstance.

• Iterative development
• Linear development

- Guidance

• Different elicitation techniques can be considered more useful or suitable to either an agile or linear project approach as detailed in the reference text. Candidates will be asked to interpret a range of circumstances (including the project approach) to consider the (un)suitability of a given elicitation technique.

• Business:
  - General requirements
  - Technical requirements
• Solution:
  - Functional requirements
  - Non-functional requirements

- Guidance

• Requirements are categorized depending on whether they are related to a business objective, or the solution/product. Sub-categories can then be established. This categorization is useful when prioritizing requirements, selecting a documentation approach, ensuring alignment with business strategy etc.

• Ensures consistency
• Enables communication
• Provides a basis for validation
• Supports product development

- Guidance

• Documentation should be used throughout requirements engineering. This can take many forms, considering the project approach and type of requirement. Documentation can be revisited/referred to at each stage of the process, as illustrated by in the requirements engineering framework. Robust documentation will capture the development of requirements from elicitation to implementation and ongoing management.

• Text based
• Diagrammatic

- Guidance

• Candidates should understand that documentation styles can be categorized as either text based on diagrammatic, including but not limited to a requirements document, business process model, or requirements backlog. The style of documentation used will vary depending on the type of requirement, project approach, organizational norms etc.

• Source
• Owner
• Name
• Business Area

- Guidance

• Information gathered that relates to an individual requirement is recorded in the requirements catalog. This document is useful in providing a level of organization and structure to the elicited requirements. Many characteristics may be recorded; a full list is available from the Business Analysis 4th Edition text. Candidates should expect to be assessed on any characteristic from the complete list within the reference text.

• Who? What? Why?
• “As a {user role} I want {feature} so that I can {reason}.”

- Guidance

• Creating user stories is a simple method of identifying the needs of a particular actor, from a system or solution. This is a standard format, easily used by all stakeholders to communicate their needs. For example, “As a cardholder, I want to be able to view my statement on demand, so that I can review my transactions”.

• Conceptualizes the solution in its entirety
• Helps to confirm requirements are in scope
• Provides clarity

- Guidance

• Being able to visualize the solution using a model can help both the analyst and stakeholders to confirm the functional requirements are as intended, and to identify any errors.

• Generate questions in order to clarify a requirement and remove ambiguity
• Define business rules
• Cross-check requirements for consistency and completeness

- Guidance

• Modelling is used to provide a visual representation of the intended solution. Candidates should understand that models are used to provide clarity and ensure consistency of requirements, allowing the concept to be easily understood by others.

• Elements required to create a case diagram:
  - Actors
  - Use cases
  - System boundary
  - Associations

- Guidance

• Use case diagrams are created to show interactions between system functions and actors. Candidates will be expected to complete diagrams within the assessment using given examples, including filling missing information, rectifying errors, and ensuring correct representation of all elements.

• Elements used to create a class diagram that represent the data requirements:
  - Classes
  - Attributes
  - Associations
  - Multiplicities
• Describe the business rules that are represented

- Guidance

• Class diagrams are used to model data and show the associations between “classes” – items of interest – in a system. Candidates will be expected to complete diagrams within the assessment using given examples, including filling missing information, rectifying errors, and ensuring correct representation of all elements.

• Create, read, update, delete
• Comparing a function or event against data
• Benefits to be derived from cross-referencing model

- Guidance

• Candidates should be able to explain how a CRUD matrix can be used in conjunction with the other models explored in this topic, to identify omissions or errors in data and/or models. A CRUD matrix shows which functions in a solution create, read, update or delete data.

• Visualization of requirements
• Increase stakeholder understanding
• Analysis and confirmation of requirements

- 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.

• Actors – “Usually user roles [that] show the individual or group of individuals responsible for carrying out the work or interacting with a system. An actor may also be an IT system or time.”
• Stakeholders – “An individual, group of individuals or organization with an interest in the change.”

- Guidance

• Multiple stakeholder roles exist as explored in the reference text. Candidates should expect to be tested on roles specifically associated with requirements engineering, including the project sponsor, product owner, the SMEs and business stakeholders.

• Validation process
• Review and agree requirements

- Guidance

• Candidates should be able to describe the use of requirements validation to ensure that the features and characteristics of the solution are met by the requirements. This process involves a review of the requirements with relevant stakeholders.

• Informal review
• Formal review

- Guidance

• The approach to validation may vary depending on the project approach and the availability of stakeholders – for example, if a singular stakeholder is unable to attend a formal review, then an informal review may be conducted with that individual.

• Initiating the backlog
• Maintaining the backlog
• Prioritization
• Defining acceptance criteria

- Guidance

• Candidates should be able to articulate the less formal validation processes typically associated with an Agile approach. For example, a straightforward outline of a requirement may be accepted as “valid” in order to be added to the backlog, prioritized for development and then elaborated over time.

• Business requirements document (BRD)
• Review group

- Guidance

• Candidates should be able to articulate more formal requirements validation which may align with a more linear methodology and/or organizational governance. This involves forming a review group where different perspectives on the requirements are considered as part of a formal review process.

• Ensure they are developed clearly
• Well organized
• Appropriately documented

- Guidance

• Candidates should be able to explain how requirements analysis is used to ensure the correctness and completeness of the requirements which have been elicited.

• Must have, Should have, Could have, Want to have (but won’t have this time)

- Guidance

• The MoSCoW technique is used to categorize requirements by priority level. Application of this technique ensures features are developed and delivered in an order which supports the priority of the requirements. Candidates should expect to be tested on their ability to apply this technique to given requirements.

• INVEST
• Quality Criteria including clear, concise, consistent, relevant
• Filters including checking for duplication, unravelling multiple requirements, evaluating feasibility

- Guidance

• Requirements should be quality checked to minimize errors such as duplication, multiple requirements, or inconsistencies. Candidates should be able to use the filters and quality criteria listed, as listed in the Business Analysis 4th Edition text, to interpret the characteristics and quality of the requirements.

• Allowing work to commence and/or progress
• Elaborating only as required
• Incremental development
• Linear development

- Guidance

• As the requirements engineering framework is non-linear, there can be the need for elicitation, elaboration etc. to be completed over time. Through the use of slicing (focusing on sections of requirements, rather than requirements as a whole) requirements analysis can begin on high priority requirements, while some elicitation work is still ongoing.

• Constraints
  - Action governance
  - Data constraints
• Operational guidance
  - Decision conditions
  - calculations
• Data models
• CRUD matrices
• Activity diagrams
• Business process models

- Guidance

• Business rules must be considered to ensure that the requirements – and therefore the solution – align with the business objectives, ways of working and any legal or regulatory conditions which must be adhered to. Candidates should be able to identify a range of techniques used to analyze both operational guidance and constraints.

• “Has the requirement been delivered as intended?”
• Functional requirements and related non-functional requirements

- Guidance

• The mark of testability is the ability to provide a firm yes or no response to this question. Candidates should be able to articulate the need for testability to ensure that requirements have been delivered as intended.

• User role analysis
• Personas

- Guidance

• User analysis helps the analyst to understand how a given party will interact with the solution, which is further supported by the creation of personas. A persona provides a more detailed example of a specific user (to explore particular demographics, needs and wants, limitations, accessibility etc.). This helps to further validate/support the need for specific requirements to be met and to help define the workings of the solution.

• How to use a customer journey map.
• Elements to be considered in its creation.

- Guidance

• Customer journey maps should be used to demonstrate the points of contact between a given user and the business/process. They are generally used in conjunction with a persona to fully explore the needs and behaviors of specific users, rather than the generic “user”. Following the journey of the persona(s) helps to ensure the requirements are met in the final solution. Candidates should consider elements such as role, persona, and touchpoints. A full list is provided within the Business Analysis 4th Edition text.

• Establish the origin and ownership of each requirement

- Guidance

• Candidates should be able to articulate why traceability is necessary within a project and within requirements engineering. For example, to ensure alignment with business objectives or to track the origins of a feature.

• Business change
• Traceability
• Ownership
• Origins

- Guidance

• The robust management of requirements is necessary to ensure ongoing traceability – this is particularly useful in times of problem solving or business change. Good requirements management will allow the origins and ownership of any requirement to be explored if challenged and can assist with future planning.

• Identification
• Cross-referencing
• Origin and ownership
• Software support
• Change control
• Configuration management

- Guidance

• Candidates should explore each element of requirements management as listed, and the relationship between these elements. For example, the relationship between cross-referencing and change control, where any change made to a single requirement may impact on other requirements.

• Document, analyze, consult, decide
• Implement or reject

- 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 justified.

• Allocate an identifier
• Allocate a version number
• Version number updated to reflect changes

- Guidance

• Version control ensures that any movement from draft to baselined requirements, and any movement within those, is recorded through the allocation of a unique identifier and the allocation/update of a version number. This ensures that any movement in requirements is clearly recorded, and version numbers can be used for comparison and to ensure all parties are working with the correct version

• Horizontal; forwards and backwards
• Vertical

- Guidance

• Traceability is the means of being able to track the development of a requirement – either forwards or backwards throughout the development cycle (why does it exist, or what became of it?), or vertically, to confirm alignment with overall business strategy. Candidates should be able to define both forms of traceability including when and why they are required.