To start any project on the right track we need to focus on the problem to be solved or the opportunity to be grasped. This clarifies the project objectives and helps us identify the terms of reference, that is, the 'what', 'where', 'when', 'who' and 'why' of the project.

The lesson topics answer the questions,

1. What is a requirement?
2. What is requirements engineering?
3. How can I establish a framework to guide the requirements initiative?
4. How to plan and estimate for a requirements project.

As well as practice multi-choice questions, there is a comprehensive case study that will be developed throughout the course. This will give you lots of opportunities to practice the techniques.

Having considered the problem that led to the start of the project, we now consider the owners of that problem - The stakeholders. This module maps to section 3 of the BCS 2018 syllabus.

Stakeholders can be internal and external to the organisation that is creating the requirements. They include people who,

• Will use the system in some way
• Have other interests in the system

Stakeholders are the prime source of requirements; they own the requirements. You need to identify them and then engage closely and often. It is vital that all stakeholders are identified and involved. Missing stakeholders means missing requirements.

Stakeholder engagement and collaboration is central to agile approaches to running projects.

Business analysts can employ various practices to increase the efficiency and effectiveness of the requirements process. Such practices include,

• User role analysis
• Personas
• Customer journeys

User role analysis is useful when considering what a user might need from a system.

Personas are valuable for considering the range and characteristics of users that are likely to access a system, e.g. customers that are likely to be interested in a particular brand.

Customer journeys are valuable for considering and improving the experience for both internal and external users.

Before planning how to engage with the stakeholders to learn their requirements, it's important that business analysts have a clear understanding of how to organise requirements.

It is generally accepted that the best way of doing this is to group the requirements into a hierarchy of categories.

Although the BCS Requirements Engineering exam employs the accepted categories of functional and non-functional, it also has its own approach to what it calls business requirements. We consider these in detail so that you will be able to pass the exam. We also mention some alternative approaches that should be useful in your career as a business analyst.

Software development life cycles are not mentioned in the BCS Requirements Engineering syllabus. However, to understand the rest of the course, it is essential to have a general understanding of the topic. We have therefore added this section as an optional module for people who are unfamiliar with terms such as waterfall, iterative and incremental, and agile.

With an understanding of the,

• Problem to be solved or opportunity to be gained
• Project objectives
• Types of stakeholders within the scope of the project

we can plan the best ways of understanding what is needed from a solution, i.e., the best way of discovering the requirements. This process is referred to as requirements elicitation.

There are many well established techniques, that can be grouped according to their relevance to particular situations.

In this session we describe,

• How to plan for elicitation
• Details of individual techniques
• The characteristics that make particular techniques relevant or not relevant to given situations

Modelling data and processes are powerful techniques that can help to,

• Understand the strengths and weaknesses in business and IT systems
• Discover (elicit) requirements for business solutions and IT systems
• Clarify relevant business rules
• Perform quality checks on the requirements
• Document requirements
• Cross check requirements for consistency and completeness
• Source prototypes and scenarios

This session focusses on three techniques:

1. Use cases as functional requirements
2. Data models, in the form of UML class models that,
   1. Create a picture of an organisation and its systems in terms of the data
   2. Highlight concerned business rules
3. CRUD matrices that cross check the data and function models for consistency, correctness and completeness

Documentation, either formal or informal, is essential in the development of large complex systems. Agile projects stress the importance of

• Limiting documentation to what is essential to developing a product
• Taking a 'Just in time' (JIT) approach to documentation, i.e. creating it close to when it will be needed for the development of the required product

To determine how much detail and formality is needed for the documentation it is necessary to consider the nature of the product being developed and the objectives of the requirements.

For example, will the requirements be used for,

• Building a tailor made software solution
• Selecting a ready made product
• Initiating an invitation to tender that suppliers can respond to with timescales and prices
• etc.

Things to consider about the product itself include:

• The consequences of failure, e.g. threats to life, finances, security and reputation
• Strategic importance
• Size and complexity
• Novelty or familiarity

Documentation is never going to be one size suits all.

We consider three broad forms of documentation:

1. Text, including traditional requirements statements and (agile) user stories
2. Models and diagrams
3. Tables, e.g. decision tables

The BCS syllabus for requirements engineering considers only text and diagrams.

Requirements management concerns the management of the documented requirements. It is closely related to configuration management. The BCS syllabus considers that configuration management is an element of requirements management. Another school of thought is that requirements management is a sub set of configuration management.

For this course, requirements management concerns:

• Configuration management
  • Unique identifiers for all requirements and related artifacts
  • Version management
  • Baselining of versions
  • Cross referencing of requirements
  • Source and ownership
  • Tracking of requirements to their destination and back to their origin
  • Tracking of changes to requirements
• Change control
  • Providing a procedure to manage changes to baselined requirements

Requirements elicitation will generally result in a mix of real requirements and other statements with varying degrees of relevance, correctness, accuracy and usefulness.

The aim of requirements analysis is to create a prioritised set of real requirements, optimally documented, valuable, complete and cohesive. It achieves this aim with a mix of checks, cross checks, filters, references to models and the use of prototypes. The requirements must be demonstrably testable and feasible.

It can be possible to elicit and analyse requirements simultaneously, particularly if,

• The analysts use models, prototypes and examples
• Business stakeholders, technical specialists and testers are involved in or with the team from the outset

Validation concerns obtaining confirmation that requirements are fit for purpose.

The approach taken to ensuring fitness for purpose will be different according to whether the project is being run in a linear, e.g. waterfall style, or an iterative, incremental or agile style.

More specifically it will depend on whether all envisaged requirements will be elicited, analysed and documented before starting to create the product, or whether working software will be developed rapidly, as increments in an iterative approach.

The final module of the course contains,

• Guidance for taking the BCS exam
• A timed practice exam for the BCS Practitioner Certificate in Requirements Engineering.

This practice exam has 40 questions, as will the actual exam. The distribution of questions also matches that of the actual exams and so will really help to prepare you.