EXIN BCS Practitioner Certificate in Requirements Engineering

1. Define Requirements Approach and Project Scope

1.1 Define the term ‘requirements’

• Provide a definition of the term “requirements” as per Business Analysis 4th Edition.

1.2 Describe the requirements engineering framework

• Understand the non-linear nature of the requirements engineering framework and the need for stakeholder engagement.

1.3 Explain factors to be considered in adapting the approach to requirements engineering

• Consider factors like organizational standards, project approach, types of requirements, and nature of the solution.

1.4 Describe the contents of a project initiation document (PID)/terms of reference (ToR)

• Understand the components such as OSCAR (Objectives, Scope, Constraints, Authority, Resources).

2. Elicit Requirements

2.1 Explain different knowledge types

• Tacit/non-tacit (explicit), individual/corporate knowledge.

2.2 Identify a technique to articulate tacit knowledge

• Techniques like observation, shadowing, storytelling, scenario analysis, prototyping, and scenario role-play.

2.3 Explain the use, advantages, and disadvantages of elicitation techniques

• Understand the benefits and drawbacks of interviews, workshops, observation, storytelling, prototyping, and more.

2.4 Identify an appropriate technique to elicit requirements

• Consider project approach, resources, and stakeholder expertise when selecting a technique.

2.5 Explain the suitability of elicitation techniques for Agile and linear development approaches

• Evaluate techniques for both iterative and linear development.

3. Record Requirements (Documentation)

3.1 Identify and describe the categories of requirement

• Business and solution requirements: general, technical, functional, and non-functional.

3.2 Explain the importance of documentation

• Consistency, communication, validation, and supporting product development.

3.3 Identify the key documentation styles

• Text-based and diagrammatic documentation.

3.4 Explain the characteristics documented for requirements in a requirements catalog

• Document information such as source, owner, name, and business area.

3.5 Explain the key underlying principles and standard format of a user story

• Format: “As a {user role}, I want {feature} so that I can {reason}.”

4. Build Models and Prototypes to Represent the Requirements

4.1 Explain the rationale for modeling the functional requirements

• Conceptualize the solution, confirm requirements are in scope, and provide clarity.

4.2 Describe the purpose of modeling in requirements engineering

• Clarify requirements, define business rules, and ensure consistency.

4.3 Prepare a UML use case diagram

• Include actors, use cases, system boundaries, and associations.

4.4 Prepare a UML class diagram

• Include classes, attributes, associations, and multiplicities.

4.5 Explain the use of a CRUD matrix

• Compare a function or event against data using Create, Read, Update, Delete.

4.6 Explain the use of prototyping to elaborate requirements

• Visualization of requirements to increase stakeholder understanding.

5. Collaborate and Communicate with Stakeholders to Clarify Requirements

5.1 Describe the responsibilities of the actors (stakeholder roles) in requirements engineering

• Understand the roles of actors, stakeholders, project sponsors, and product owners.

5.2 Describe the purpose of requirements validation

• Review and agree on requirements with stakeholders.

5.3 Describe the rationale for various approaches to requirements validation

• Understand informal and formal validation processes.

5.4 Demonstrate how Agile requirements are validated

• Validate requirements through backlog management, prioritization, and acceptance criteria.

5.5 Demonstrate how formal requirements are validated

• Business requirements document (BRD) and review groups.

6. Analyze, Prioritize, and Assure the Quality of Requirements

6.1 Explain the purpose of analyzing requirements

• Ensure requirements are clearly developed, well-organized, and appropriately documented.

6.2 Apply the MoSCoW technique to prioritize requirements

• Prioritize requirements using “Must have, Should have, Could have, Won’t have.”

6.3 Interpret individual requirements, applying filters and quality criteria

• Use INVEST and quality criteria to ensure clarity and consistency.

6.4 Identify the purposes of slicing requirements (Agile/linear)

• Allow incremental development and elaborate as required.

6.5 Identify techniques used to analyze business rules

• Analyze operational guidance and constraints using activity diagrams, business process models, and more.

6.6 Explain the importance of testability

• Ensure requirements can be tested to verify if they are delivered as intended.

7. Conduct User Analysis and Profiling

7.1 Describe techniques used to analyze roles

• Use user role analysis and personas to understand interactions with the system.

7.2 Explain the purpose of a customer journey map

• Map touchpoints between the user and the business to ensure requirements are met.

8. Requirements Management and Traceability

8.1 Explain the rationale and approach to achieving requirements traceability

• Establish the origin and ownership of each requirement.

8.2 Explain the rationale for requirements management

• Manage requirements effectively to support business change and maintain traceability.

8.3 Define the elements of requirements management and the links between them

• Identification, cross-referencing, change control, and configuration management.

8.4 Explain the use of a change control process

• Document, analyze, consult, and decide on changes.

8.5 Describe the elements of a version control process

• Allocate unique identifiers and version numbers to track changes.

8.6 Explain the use and advantages of different forms of traceability

• Understand horizontal (forwards and backwards) and vertical traceability to confirm alignment with business strategy.