Business analysts, systems analysts and anyone involved in the analysis, investigation or improvement of business systems and processes.
Attendance on the Business Analysis Foundation course or equivalent knowledge and experience.
Lecture presentations are supported by group practical work which allows discussion, reinforcement of learning and enhancement of the understanding process.
This course has been independently developed but follows the BCS Requirements Engineering syllabus. Course fees do not include the BCS examination. This course is concerned with one of the major areas of business analysis work which is producing a well-organised and clearly-defined set of requirements. The course is structured around a five part framework for Requirements Engineering which is applied to a project initiated by an approved business case. The five elements of the framework are Requirements Elicitation, Requirements Analysis, Requirements Validation, Requirements Documentation and Requirements Management.
At the end of the course, delegates should be able to:
- Explain the importance of linking requirements to the business case.
- Describe the roles and responsibilities of key stakeholders in the requirements engineering process.
- Explain the use of a range of requirements elicitation techniques and the relevance of the techniques to business situations.
- Analyse, prioritise and organise elicited requirements.
- Document requirements.
- Identify problems with requirements and explain how requirements documentation may be improved.
- Create a model of the features required from a system.
- Interpret a model of the data requirements for an information system.
- Describe the principles of requirements management and explain the importance of managing requirements.
- Describe the use of tools to support requirements engineering.
- Explain the process and stakeholders involved in requirements validation.
Introduction to Requirements Engineering
Framework for requirements engineering:
The business rationale and inputs.
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, including performance, usability, access, security, archiving, back up and recovery, availability, robustness.
Stakeholders in the Requirements Process
The definition of the term'stakeholder'
Knowledge types – tacit and non-tacit.
• Observation - formal/informal, shadowing.
• Focus groups.
• Document analysis.
• Special purpose records.
Understanding the applicability of techniques.
Use of Models in Requirements Engineering
The purpose of modelling requirements:
• Generating questions.
• Cross-checking for consistency and completeness.
• Defining business rules.
Modelling 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 diagram.
Interpreting a data model based upon the system data requirements - class diagram.
Documentation styles and levels of definition.
Prioritising and packaging requirements for delivery.
• Requirements filters.
• Characteristics of a good requirement.
Agreeing the requirements document.
Types of reviews:
• Informal reviews.
• Structured walkthroughs (author-led review).
• Technical reviews.
Stakeholders and their areas of concern.
Dealing with changing requirements.
The importance of traceability:
• Vertical traceability (to business objectives).
• Horizontal traceability (from origin to deliver).
Traceability and ownership.
Requirements engineering support tools.