BCS Certificate in Requirement Engineering

A candidate can use this course to develop the skills to work with requirements stakeholders in order to make sure that different perspectives are fulfilled by the requirements and that conflicts are negotiated in such a way that they become the opinion of all. The course is targeted to those people who may be ambitious to acquire the skills required for establishing system requirements.

EXAM:

Fees: The Exam Fees is not covered/included in the course fees and has to be paid while registering for the exam. The exam can only be taken after completing the BCS Certificate in Requirement Engineering course. The candidates appearing for the BCS exam must bring some kind of photographic evidence to show at the examination hall to the invigilator. BCS allow additional time for candidates having some kind of disability or whose native language differs to that of the examination paper. For details refer to the BCS Reasonable Adjustments Policy which is available to view on the BCS website. If you believe you qualify for this then please notify the Exam Administration team at least two weeks prior to the exam.  Delegates failing to do so and provide evidence when requested, may not be allowed the additional support.

Introduction to Requirement Engineering

• Framework for Requirements Engineering
  • Rationale for Requirements Engineering and the problems with requirements
  • The Definition and Characteristics of Requirement
  • The Characteristics of a Requirements Engineering Process
  • The Problems of Defining Requirements
  • The Requirements Engineering Framework
  • Requirement Engineering Activities
  • Importance of Requirements Planning and Estimating
• Business Rationale and Input
  • Business Process Analysis Model and Inputs into ‘The Define Requirements’ Stage
  • Business Case in Project Life-Cycle 
  • Terms of Reference/ Project Initiation Document/ Project Charter–business objectives,  project objectives, scope, constraints (budget, timescale, standards), sponsor (authority), resources and  assumptions

Hierarchy of requirements 

• Building the hierarchy through decomposition of requirements
• Categories of requirements within the hierarchy
  • General business requirements, including legal and business policy
  • Technical policy requirements
  • Functional requirements
  • Non-functional requirements, that include performance, availability, robustness, usability, robustness, access, security, archiving, backup  and recovery 

Stakeholders in the requirements process 

• The definition of the term ‘stakeholder
• Role and Contribution of Project Stakeholders to the requirements engineering process 
  • Project Manager
  • Business Analysis
  • Solution 
  • Developer
  • Testers 
  • Architects
• Role and contribution of Business Stakeholders to the requirements engineering process
  • Project Sponsor
  • Subject matter expert
  • End users and managers
• Role and Contribution of External stakeholders to the requirements engineering process 
  • Customers
  • Regulators
  • Suppliers - products and services

Requirements Elicitation 

• Knowledge types –tacit and non-tacit(explicit)
• Elicitation techniques
  • Interviews
  • Workshops
  • Observation
  • Formal/informal
  • Shadowing
  • Focus groups
  • Prototyping
  • Scenarios
  • Document Analysis
  • Special purpose records
  • Questionnaires
  • Activity sampling

• Understanding the applicability of techniques

Use of models in Requirements Engineering 

• The purpose of modeling requirements 
  • Generating questions
  • Crosschecking for consistency and completeness
  • Defining business rules
• Modeling the business context for the system using a context diagram that identifies the inputs and outputs of the system
• Developing a model to represent the system processing requirements.Use case diagrams –actors, boundaries, associations, use cases 
• Interpreting a data model based upon the system data requirements Class diagram –classes, simple associations, multiplicities, attributes

Requirements Documentation 

• Documentation styles and levels of definition
  • User Stories
  • Use Cases
  • Requirements List
  • Requirements Catalogue

• Requirements Catalogue
  • Identifier
  • Name
  • Description
  • Acceptance criteria
  • Source
  • Owner
  • Rationale/Benefits
  • Related on functional requirements
  • Priority
  • Type (functional, non-functional, general, technical)
  • Related requirements/documents
  • Author
  • Version control/status
  • Change history
  • Resolution
• Requirements Document 
• Introduction and Background
• Business Process Models
• Function models (use case diagram) of defined requirements
• Data model (class model) of defined requirements
• Requirements catalogue
• Glossary

Requirements Analysis

• Prioritizing and packaging requirements for delivery

   The MoSCoW prioritization scheme and its role/purpose in planning the delivery of a system, its iterations or releases

• Organising requirements
  • Requirements filters 
  • Characteristics of a good requirement
  • Removing duplicated requirements
  • Reconcilingoverlapping requirements
  • Identifying and negotiating conflicts between requirements
  • Removing ambiguity
  • Ensuring feasibility(technical, business and financial)
  • Ensuring testability
  • Ensuring traceability
• Prototyping requirements
• Verifying requirements 

Requirements Validation 

• Agreeing with the requirements document

The requirements validation process; plan review, issue documentation, review documentation, collect comments, undertake actions, revise documentation

• Types of reviews
  • Informal reviews
  • Structured walkthroughs (author-led review)
  • Technical reviews
  • Inspections
• Stakeholders and their areas of concern

Project sponsor, end user representatives, subject matter expert (domain expert) business analyst, developers, testers, project office 

Requirements Management 

• Dealing with changing requirements
  • The sources of change
  • Change Management 
  • Configuration management 
• The importance of traceability
  • Vertical traceability (to business objectives)
  • Horizontal traceability (from origin to delivery)
• Traceability and ownership
• Requirements Engineering support tools
  • CARE Tools (Computer Aided Requirements Engineering)
  • CASE Tools (Computer Aided Software Engineering)