BCS Certificate in Requirements Engineering Extended Syllabus

BCS Certificate in Requirements Engineering Extended Syllabus Version 2.3 July 2013

Change History Version Number and Date Version 2.3 July 2013 Changes Made Minor updates made to the commentary Version 2.2 September 2012 This is the first version of the extended RE syllabus. The version number is unchanged so that it is consistent with the existing RE syllabus. The syllabus has been extended to support the centralised RE examination. The original syllabus is defined in black and the extensions in red. A commentary has been added to aid candidates preparing for the centralised examination. Page 1 of 21

BCS Certificate in Requirements Engineering Contents Change History...1 Introduction...6 Objectives...6 Eligibility for the Examination...6 Duration and Format of the Examination...7 Accreditation Guidelines for Providers...7 Additional Time for Candidates requiring Reasonable Adjustments due to a temporary or permanent disability...7 Additional Time for Candidates whose business language is not English...7 Excerpts from BCS Books...7 Syllabus...8 1. Introduction to Requirements Engineering (5%)...8 1.1 Framework for Requirements Engineering 8 Rationale for Requirements Engineering and the problems with requirements 8 The definition and characteristics of a requirement (1) 8 The characteristics of a requirements engineering process (2) 8 The problems of defining requirements (3) 8 A framework for Requirements Engineering (4) 8 Requirement Engineering activities elicitation, analysis, validation, documentation and management 8 The importance of requirements planning and estimating (5) 8 1.2 The business rationale and inputs 8 The business analysis process model and the inputs into the define requirements stage (6) 8 The business case in the project lifecycle (7) 8 Terms of Reference / Project Initiation Document / Project Charter business objectives, project objectives, scope, constraints (budget, timescale, standards), sponsor (authority), resources and assumptions 8 2. Hierarchy of requirements (10%)...8 2.1 Building the hierarchy through decomposition of requirements (1) 8 2.2 Categories of requirements within the hierarchy (2) 8 General business requirements, including legal and business policy 8 Technical policy requirements 8 Functional requirements 8 Page 2 of 21

Non-functional requirements, including performance, usability, access, security, archiving, back up and recovery, availability, robustness (3) 8 3. Stakeholders in the requirements process (5%)...8 3.1 The definition of the term stakeholder (1) 8 3.2 Project Stakeholders: their role and contribution to the requirements engineering process (2) 8 Project Manager 8 Business Analysis 8 Solution Developer 8 Testers (3) 8 Architects (4) 8 3.3 Business Stakeholders: their role and contribution to the requirements engineering process (5) 8 Project Sponsor 8 Subject matter expert 8 End users and managers 8 3.4 External stakeholders: their role and contribution to the requirements engineering process (6) 9 Customers 9 Regulators 9 Suppliers - products and services 9 4. Requirements Elicitation (20%)...9 4.1 Knowledge types tacit and non-tacit (explicit) (1) 9 4.2 Elicitation techniques 9 For each elicitation technique; description of the technique (what it is), conduct of the technique (how it is performed); advantages of the technique, including situations where the technique is particularly appropriate, and disadvantages or drawbacks of the technique, including situations where the technique is not particularly appropriate. 9 Interviews 9 Workshops 9 Observation: 9 o Formal/informal 9 o Shadowing 9 Focus groups 9 Prototyping 9 Scenarios 9 Document Analysis (2) 9 Special purpose records 9 Questionnaires 9 Activity sampling 9 4.3 Understanding the applicability of techniques (3) 9 5. Use of models in Requirements Engineering (10%)...9 5.1 The purpose of modelling requirements 9 Generating questions 9 Cross-checking for consistency and completeness 9 Defining business rules 9 5.2 Modelling the business context for the system using a context diagram that identifies the inputs and outputs of the system 9 Page 3 of 21

5.3 Developing a model to represent the system processing requirements 9 Use case diagram actors, boundaries, associations, use cases (1) 9 5.4 Interpreting a data model based upon the system data requirements 9 Class diagram classes, simple associations, multiplicities, attributes (2) 9 6. Requirements Documentation (15%)...10 6.1 Documentation styles and levels of definition 10 User Stories (1) 10 Use Cases (2) 10 Requirements List 10 Requirements Catalogue 10 6.2 Requirements Catalogue 10 Identifier 10 Name 10 Description 10 Acceptance criteria 10 Source 10 Owner 10 Rationale/Benefits 10 Related non-functional requirements 10 Priority 10 Type (functional, non-functional, general, technical) 10 Related requirements/documents 10 Author 10 Version control/status 10 Change history 10 Resolution 10 6.3 Requirements Document (3) 10 Introduction and Background 10 Business Process Models 10 Function models (use case diagram) of defined requirements 10 Data model (class model) of defined requirements 10 Requirements catalogue 10 Glossary 10 7. Requirements Analysis (20%)...11 7.1 Prioritising and packaging requirements for delivery 11 The MoSCoW prioritisation scheme (1) and its role/purpose in planning the delivery of a system, its iterations or releases 11 7.2 Organising requirements 11 Requirements filters (2) 11 Characteristics of a good requirement (3) 11 7.3 Prototyping requirements 11 7.4 Verifying requirements (4) 11 8. Requirements Validation (5%)...11 8.1 Agreeing the requirements document 11 The requirements validation process; plan review, issue documentation, review documentation, collect comments, undertake actions, revise documentation 11 8.2 Types of reviews (1) 11 Informal reviews 11 Structured walkthroughs (author-led review) 11 Technical reviews 11 Page 4 of 21

Inspections 11 8.3 Stakeholders and their areas of concern (2) 11 Project sponsor, end user representatives, subject matter expert (domain expert) business analyst, developers, testers, project office representatives. 11 9. Requirements Management (10%)...12 9.1 Dealing with changing requirements 12 The sources of change (1) 12 Change Management (2) 12 Configuration management (3) 12 9.2 The importance of traceability 12 Vertical traceability (to business objectives) 12 Horizontal traceability (from origin to deliver) 12 9.3 Traceability and ownership 12 9.4 Requirements Engineering support tools (4) 12 CARE Tools (Computer Aided Requirements Engineering) 12 CASE Tools (Computer Aided Software Engineering) 12 Extended Syllabus Commentary...13 Levels of Knowledge...16 Levels of Skill and Responsibility (SFIA Levels)...17 Format of the Examination...19 Recommended Reading List...20 Page 5 of 21

Introduction The syllabus 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. The syllabus requires that the candidate should be able to describe the objectives and techniques within each element of the framework. This extended Requirements Engineering syllabus is designed to support the centralised requirements engineering examination paper. The original syllabus is defined in black and the extensions in red. A commentary has been added to aid candidates preparing for the centralised examination. There are numbers at the end of some bullet points which directly refer to points made in the commentary. Objectives Holders of the BCS Certificate in Requirements Engineering 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 Eligibility for the Examination There are no specific pre-requisites for entry to the examination; however candidates should possess the appropriate level of knowledge to fulfil the objective shown above. Page 6 of 21

Duration and Format of the Examination The format for the examination is a one hour written (closed book) based on a combination business scenarios, complex multiple choice and short answer questions with 15 minutes reading time. Candidates who are awarded a pass for the examination are awarded the BCS Certificate in Requirements Engineering. Accreditation Guidelines for Providers This certification is subject to the accreditation guidelines applied to all BCS Certifications. It is the view of BCS that, for full coverage to be achieved, training courses leading to the certificate should normally run for 21 hours. Additional Time for Candidates requiring Reasonable Adjustments due to a temporary or permanent disability Candidates may request additional time if they require reasonable adjustments in line with the BCS reasonable adjustments policy. It will be the Examination Provider s responsibility to make a decision regarding candidate eligibility and keep a record of the decision. This is subject to audit by BCS. Additional Time for Candidates whose business language is not English An additional 15 minutes will be allowed for candidates sitting the examination in a language that is not their mother tongue, and where the language of the exam is not their primary business language, Foreign language candidates who meet the above requirements are also entitled to the use of a paper dictionary (to be supplied by the candidate). It will be the Examination Provider s responsibility to make the decision regarding candidate eligibility and keep a record of the additional time allowed. Candidates must request additional time in advance of the examination to allow the Examination Provider enough time to make suitable arrangements with the invigilator. Excerpts from BCS Books Examination Providers may include excerpts from BCS books in the course materials. If you wish to use excerpts from the books you will need a license from BCS to do this. If you are interested in taking out a licence to use BCS published material you should contact the Head of Publishing at BCS outlining the material you wish to copy and the use to which it will be put. Page 7 of 21

Syllabus 1. Introduction to Requirements Engineering (5%) 1.1 Framework for Requirements Engineering Rationale for Requirements Engineering and the problems with requirements The definition and characteristics of a requirement (1) The characteristics of a requirements engineering process (2) The problems of defining requirements (3) A framework for Requirements Engineering (4) Requirement Engineering activities elicitation, analysis, validation, documentation and management The importance of requirements planning and estimating (5) 1.2 The business rationale and inputs The business analysis process model and the inputs into the define requirements stage (6) The business case in the project lifecycle (7) Terms of Reference / Project Initiation Document / Project Charter business objectives, project objectives, scope, constraints (budget, timescale, standards), sponsor (authority), resources and assumptions 2. Hierarchy of requirements (10%) 2.1 Building the hierarchy through decomposition of requirements (1) 2.2 Categories of requirements within the hierarchy (2) 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 (3) 3. Stakeholders in the requirements process (5%) 3.1 The definition of the term stakeholder (1) 3.2 Project Stakeholders: their role and contribution to the requirements engineering process (2) Project Manager Business Analysis Solution Developer Testers (3) Architects (4) 3.3 Business Stakeholders: their role and contribution to the requirements engineering process (5) Project Sponsor Subject matter expert End users and managers Page 8 of 21

3.4 External stakeholders: their role and contribution to the requirements engineering process (6) Customers Regulators Suppliers - products and services 4. Requirements Elicitation (20%) 4.1 Knowledge types tacit and non-tacit (explicit) (1) 4.2 Elicitation techniques For each elicitation technique; description of the technique (what it is), conduct of the technique (how it is performed); advantages of the technique, including situations where the technique is particularly appropriate, and disadvantages or drawbacks of the technique, including situations where the technique is not particularly appropriate. Interviews Workshops Observation: o Formal/informal o Shadowing Focus groups Prototyping Scenarios Document Analysis (2) Special purpose records Questionnaires Activity sampling 4.3 Understanding the applicability of techniques (3) 5. Use of models in Requirements Engineering (10%) 5.1 The purpose of modelling requirements Generating questions Cross-checking for consistency and completeness Defining business rules 5.2 Modelling the business context for the system using a context diagram that identifies the inputs and outputs of the system 5.3 Developing a model to represent the system processing requirements Use case diagram actors, boundaries, associations, use cases (1) 5.4 Interpreting a data model based upon the system data requirements Class diagram classes, simple associations, multiplicities, attributes (2) Page 9 of 21

6. Requirements Documentation (15%) 6.1 Documentation styles and levels of definition User Stories (1) Use Cases (2) Requirements List Requirements Catalogue 6.2 Requirements Catalogue Identifier Name Description Acceptance criteria Source Owner Rationale/Benefits Related non-functional requirements Priority Type (functional, non-functional, general, technical) Related requirements/documents Author Version control/status Change history Resolution 6.3 Requirements Document (3) Introduction and Background Business Process Models Function models (use case diagram) of defined requirements Data model (class model) of defined requirements Requirements catalogue Glossary Page 10 of 21

7. Requirements Analysis (20%) 7.1 Prioritising and packaging requirements for delivery The MoSCoW prioritisation scheme (1) and its role/purpose in planning the delivery of a system, its iterations or releases 7.2 Organising requirements Requirements filters (2) Characteristics of a good requirement (3) Removing duplicated requirements Reconciling overlapping requirements Identifying and negotiating conflicts between requirements Removing ambiguity Ensuring feasibility (technical, business and financial) Ensuring testability Ensuring traceability 7.3 Prototyping requirements 7.4 Verifying requirements (4) 8. Requirements Validation (5%) 8.1 Agreeing the requirements document The requirements validation process; plan review, issue documentation, review documentation, collect comments, undertake actions, revise documentation 8.2 Types of reviews (1) Informal reviews Structured walkthroughs (author-led review) Technical reviews Inspections 8.3 Stakeholders and their areas of concern (2) Project sponsor, end user representatives, subject matter expert (domain expert) business analyst, developers, testers, project office representatives. Page 11 of 21

9. Requirements Management (10%) 9.1 Dealing with changing requirements The sources of change (1) Change Management (2) Configuration management (3) 9.2 The importance of traceability Vertical traceability (to business objectives) Horizontal traceability (from origin to deliver) 9.3 Traceability and ownership 9.4 Requirements Engineering support tools (4) CARE Tools (Computer Aided Requirements Engineering) CASE Tools (Computer Aided Software Engineering) Page 12 of 21

Extended Syllabus Commentary Section 1: Introduction to Requirements Engineering 1) The definition of a requirement may be found in the IIBA BaBOK. 2) A requirements engineering process would typically define the responsibilities of key stakeholders, suggest the separation of elicitation, analysis and validation, stress links to the business context of the project, promote organised requirements documentation, emphasise testable requirements, stress requirements traceability, employ industry-standard modelling techniques and promote the use of visualisation techniques such as prototyping. 3) Typical problems with requirements are defined in Paul et al; Business Analysis (second edition), BCS publications, pp149-150. 4) A framework for Requirements Engineering is presented in Paul et al; Business Analysis (second edition), BCS publications, pp152-153. 5) Only an appreciation of the importance of planning and estimating is required. A detailed consideration of project planning and use of published estimating models is not required. 6) The business analysis process model and inputs into the define requirements stage is presented in Paul et al; Business Analysis (second edition), BCS publications, pp65-67. 7) Detailed consideration of what is in a business case is not required. The project lifecycle of a business case is presented in Paul et al; Business Analysis (second edition), BCS publications, pp223-224. Section 2: Hierarchy requirements 1) This is concerned with the principle of hierarchy and its potential use in decomposition. 2) This classification is defined in detail in Paul et al; Business Analysis (second edition), BCS publications, pp171 175. 3) An examinable list of non-functional requirements is provided in Paul et al; Business Analysis (second edition), BCS publications, pp174-175. Section 3: Stakeholders in the requirements process 1) The term stakeholder is defined as someone who has an interest in the system or business change under consideration. 2) Project stakeholders are discussed in Paul et al; Business Analysis (second edition), BCS publications, p155. 3) Project stakeholders include testers from the perspective of validating testable requirements and testing the software that purports to fulfil those requirements. 4) Solution Architects will particularly contribute to the technical requirements of the project. 5) Business stakeholders are discussed in Paul et al; Business Analysis (second edition), BCS publications, pp153-155. 6) This is a sub-set of the external stakeholders discussed in Paul et al; Business Analysis (second edition), BCS publications, pp100-102. Page 13 of 21

Section 4: Requirements Elicitation 1) The distinction between knowledge types is made in Paul et al; Business Analysis (second edition), BCS publications, pp156-159. 2) This means the analysis of documents used in the process (for example; a delegate booking form used in a training course system), it does not mean reviewing existing documentation describing the business processes or system under review. 3) This is largely covered by the extended information given in 4.2. However, candidates must be able to select appropriate techniques to elicit requirements in the context of a given scenario. A candidate relationship between techniques and knowledge types is given in Paul et al; Business Analysis (second edition), BCS publications, pp160-161. Section 5: Use of models in Requirements Engineering 1) Different types of actor (user roles, time, another system), use cases (including a definition of the different types of event that can initiate a use case (external input, time, internal), boundary of the system, simple associations between actors and use cases. There is no requirement to understand <<include>> and <<extend>> constructs. 2) Simple business classes (such as Employee, Payment, Invoice etc) and how they are related to each other through associations. Understanding business rules through interpreting multiplicities (min..max). Definition of attributes. There is no requirement to understand operations and associations such as generalisation and associated concepts of inheritance and polymorphism. Section 6: Requirements Documentation 1) User stories should at least identify the who, why and what of a requirement. For example; As a (role or actor) (Who), I want (what capability or feature is required) (What), so that (why is it of business value or benefit) (Why) 2) Use cases need to identify the use case name, actor, pre-conditions, triggering event, use case steps (with alternatives and exceptions), post-conditions or success guarantees. 3) The contents of a Requirements Document are discussed in Paul et al; Business Analysis (second edition), BCS publications, pp169-170 Section 7: Requirements Analysis 1) The MoSCoW prioritization scheme is associated with an agile approach to systems development. For the purpose of this syllabus, both M(ust) have and S(hould) have requirements are mandatory. Must have requirements must be delivered in the initial software release, but Should have requirements can be delayed to a later software release. The C stands for C(ould) and, the W for W(on t have this time). 2) Requirements filters are defined in Paul et al; Business Analysis (second edition), BCS publications, pp163-164. 3) Characteristics of a good requirement are defined in Paul et al; Business Analysis (second edition), BCS publications, pp164-165. A good requirement can also be defined as one that is SMART which in this context is specific, measurable, achievable, relevant and time-framed. The usefulness of the acronym is improved if two of the letters are used flexibly. The T might also stand for testable (measurable). The R might also stand for realistic (achievable). 4) This concerns checking performed by requirements (business) analysts, rather than the stakeholders undertaking the requirements validation review. Page 14 of 21

Section 8: Requirements Validation 1) The types of review are introduced in the ISTQB software testing syllabus. Formal reviews are a formal fault identification process with a focus on finding, documenting and categorising faults, not apportioning blame. The characteristics of these four types of reviews is explored in Hambling et al, Software Testing, BCS Publications, pp62-63. 2) The focus here is on how stakeholders contribute to the validation process. The potential contribution of stakeholders to requirements validation is discussed in Paul et al; Business Analysis (second edition), BCS publications, pp165-166. Section 9: Requirements Management 1) Sources of requirements change includes changes in organisational focus and strategy, changes in significant stakeholders, changes in technical possibilities or technical constraints, deterioration in the financial performance of the organisation. Changes in the external environment (for example; enactment of a new law, deterioration in the economy) may also impact the project. 2) Change control is discussed in Paul et al; Business Analysis (second edition), BCS publications, p184. 3) Configuration management is discussed in Paul et al; Business Analysis (second edition), BCS publications, pp182-183. 4) Only a simple distinction is required here, between features offered by tools that focus on requirements documentation and management (CARE) and features offered by tools that also possess functions to support requirements modelling (CASE). Page 15 of 21

Levels of Knowledge This course will provide candidates with the levels of difficulty / knowledge highlighted within the following table, enabling them to develop the skills to operate at the levels of responsibility indicated. The levels of knowledge are explained in the following text. Note that each K level subsumes lower levels. For example, a K4 level topic is one for which a candidate must be able to analyse a situation and extract relevant information. A question on a K4 topic could be at any level up to and including K4. As an example, a scenario requiring a candidate to analyse a scenario and select the best risk identification method would be at K4, but questions could also be asked about this topic at K3 and a question at K3 for this topic might require a candidate to apply one of the risk identification methods to a situation. Level 1: Remember (K1) The candidate should be able to recognise, remember and recall a term or concept but not necessarily be able to use or explain. Typical questions would use: define, duplicate, list, memorise, recall, repeat, reproduce, state. Level 2: Understand (K2) The candidate should be able to explain a topic or classify information or make comparisons. The candidate should be able to explain ideas or concepts. Typical questions would use: classify, describe, discuss, explain, identify, locate, recognise, report, select, translate, paraphrase. Level 3: Apply (K3) The candidate should be able apply a topic in a practical setting. The candidate should be able to use the information in a new way. Typical questions would use: choose, demonstrate, employ, illustrate, interpret, operate, schedule, sketch, solve, use, write. Level 4: Analyse (K4) The candidate should be able to distinguish/separate information related to a concept or technique into its constituent parts for better understanding, and can distinguish between facts and inferences. Typical questions would use: appraise, compare, contrast, criticise, differentiate, discriminate, distinguish, examiner, question, test. Level 5: Synthesise (K5) The candidate should be able to justify a decision and can identify and build patterns in facts and information related to a concept or technique, they can create new meaning or structure from parts of a concept. Typical questions would use: appraise, argue, defend, judge, select, support, value, evaluate. Level 6: Evaluate (K6) The candidate should be able to provide a new point of view and can judge the value of information and decide on its applicability in a given situation. Typical questions would use: assemble, contract, create, design, develop, formulate, write. Page 16 of 21

Levels of Skill and Responsibility (SFIA Levels) The levels of knowledge above will enable candidates to develop the following levels of skill to be able to operate at the following levels of responsibility (as defined within the SFIA framework) within their workplace: Level 1: Follow Work under close supervision to perform routine activities in a structured environment. They will require assistance in resolving unexpected problems, but will be able to demonstrate an organised approach to work and learn new skills and applies newly acquired knowledge. Level 2: Assist Works under routine supervision and uses minor discretion in resolving problems or enquiries. Works without frequent reference to others and may have influence within their own domain. They are able to perform a range of varied work activities in a variety of structured environments and can identify and negotiate their own development opportunities. They can also monitor their own work within short time horizons and absorb technical information when it is presented systematically and apply it effectively. Level 3: Apply Works under general supervision and uses discretion in identifying and resolving complex problems and assignments. They usually require specific instructions with their work being reviewed at frequent milestones, but can determines when issues should be escalated to a higher level. Interacts with and influences department/project team members. In a predictable and structured environment they may supervise others. They can perform a broad range of work, sometimes complex and non-routine, in a variety of environments. They understand and use appropriate methods, tools and applications and can demonstrate an analytical and systematic approach to problem solving. They can take the initiative in identifying and negotiating appropriate development opportunities and demonstrate effective communication skills, sometimes planning, scheduling and monitoring their own work. They can absorb and apply technical information, works to required standards and understand and uses appropriate methods, tools and applications. Level 4: Enable Works under general direction within clear framework of accountability and can exercise substantial personal responsibility and autonomy. They can plan their own work to meet given objectives and processes and can influence their team and specialist peers internally. They can have some responsibility for the work of others and for the allocation of resources. They can make decisions which influence the success of projects and team objectives and perform a broad range of complex technical or professional work activities, in a variety of contexts. They are capable of selecting appropriately from applicable standards, methods, tools and applications and demonstrate an analytical and systematic approach to problem solving, communicating fluently orally and in writing, and can present complex technical information to both technical and non-technical audiences. They plan, schedule and monitor their work to meet time and quality targets and in accordance with relevant legislation and procedures, rapidly absorbing new technical information and applying it effectively. They have a good appreciation of the wider field of information systems, their use in relevant employment areas and how they relate to the business activities of the employer or client. Page 17 of 21

Level 5: Ensure and advise Works under broad direction, being fully accountable for their own technical work and/or project/supervisory responsibilities, receiving assignments in the form of objectives. Their work is often self-initiated and they can establish their own milestones, team objectives, and delegates responsibilities. They have significant responsibility for the work of others and for the allocation of resources, making decisions which impact on the success of assigned projects i.e. results, deadlines and budget. They can also develop business relationships with customers, perform a challenging range and variety of complex technical or professional work activities and undertake work which requires the application of fundamental principles in a wide and often unpredictable range of contexts. They can advise on the available standards, methods, tools and applications relevant to own specialism and can make correct choices from alternatives. They can also analyse, diagnose, design, plan, execute and evaluate work to time, cost and quality targets, communicating effectively, formally and informally, with colleagues, subordinates and customers. They can demonstrate leadership, mentor more junior colleagues and take the initiative in keeping their skills up to date. Takes customer requirements into account and demonstrates creativity and innovation in applying solutions for the benefit of the customer. Level 6: Initiate and influence Have a defined authority and responsibility for a significant area of work, including technical, financial and quality aspects. They can establish organisational objectives and delegates responsibilities, being accountable for actions and decisions taken by them self and their subordinates. They can influence policy formation within their own specialism to business objectives, influencing a significant part of their own organisation and customers/suppliers and the industry at senior management level. They make decisions which impact the work of employing organisations, achievement of organisational objectives and financial performance, developing high-level relationships with customers, suppliers and industry leaders. They can perform highly complex work activities covering technical, financial and quality aspects. They contribute to the formulation of IT strategy, creatively applying a wide range of technical and/or management principles. They absorb complex technical information and communicate effectively at all levels to both technical and non-technical audiences, assesses and evaluates risk and understand the implications of new technologies. They demonstrate clear leadership and the ability to influence and persuade others, with a broad understanding of all aspects of IT and deep understanding of their own specialism(s). They take the initiative in keeping both their own and subordinates' skills up to date and to maintain an awareness of developments in the IT industry. Level 7: Set strategy, inspire and mobilise Have the authority and responsibility for all aspects of a significant area of work, including policy formation and application. They are fully accountable for actions taken and decisions made, by both them self and their subordinates. They make decisions critical to organisational success and influence developments within the IT industry at the highest levels, advancing the knowledge and/or exploitation of IT within one or more organisations. They develop long-term strategic relationships with customers and industry leaders, leading on the formulation and application of strategy. They apply the highest level of management and leadership skills, having a deep understanding of the IT industry and the implications of emerging technologies for the wider business environment. They have a full range of strategic management and leadership skills and can understand, explain and present complex technical ideas to both technical and non-technical audiences at all levels up to the Page 18 of 21

highest in a persuasive and convincing manner. They have a broad and deep IT knowledge coupled with equivalent knowledge of the activities of those businesses and other organisations that use and exploit IT. Communicates the potential impact of emerging technologies on organisations and individuals and analyses the risks of using or not using such technologies. They also assess the impact of legislation, and actively promote compliance. Level Levels of knowledge Levels of skill and responsibility (SFIA) K7 Set strategy, inspire and mobilise K6 Evaluate Initiate and influence K5 Synthesise Ensure and advise K4 Analyse Enable K3 Apply Apply K2 Understand Assist K1 Remember Follow Format of the Examination This syllabus has an accompanying examination at which the candidate must achieve a pass score to gain the BCS Certificate in Requirements Engineering. Type Duration Pre-requisites Supervised / Invigilated Open Book Written closed book examination based on a combination business scenarios, complex multiple choice and short answer questions 1 Hour preceded by 15 minutes reading time Candidates sitting the examination in a language other than their primary business language may request an additional 15 minutes as well as the use of a paper dictionary None Yes Yes Pass Mark 50% Distinction Mark Delivery None Paper based examination Page 19 of 21

Recommended Reading List Title: Business Analysis (2 nd Edition) Author: Debra Paul, Donald Yeates and James Cadle Publisher: BCS Publication Date: 2010 ISBN: 9781906124618 URL: http://shop.bcs.org Title: Mastering the Requirements Process Author: Suzanne Robertson and James Robertson Publisher: Addison Wesley Publication Date: 1999 ISBN: 978-0201360462 Title: Writing Effective Use Cases Author: Alistair Cockburn Publisher: Addison-Wesley Publication Date: October 2000 ISBN: 0201702258 Title: User Stories Applied: For Agile Software Development Author: Mike Cohn Publisher: Addison Wesley Publication Date: March 2004 ISBN: 9780321205681 Title: Requirements Engineering: Processes and Techniques Author: Gerald Kotonya and Ian Sommerville Publisher: John Wiley & Sons Publication Date: April 1998 ISBN: 0471972088 Title: Use Case Modeling Author: Kirt Bittner and Ian Spence Publisher: Addison Wesley Publication Date: August 2002 ISBN: 9780201709131 Title: Business Analysis Techniques: 72 Essential Tools for Success Author: James Cadle, Debbie Paul and Paul Turner Publisher: BCS Publication Date: February 2010 ISBN: 9781906124236 URL: http://shop.bcs.org Page 20 of 21

Title: Writing Better Requirements Author: Ian F Alexander and Richard Stevens Publisher: Addison-Wesley Publication Date: 2002 ISBN: 0321131630 Title: Scenarios, Stories and Use Cases Author: Ian Alexander and Neil Maiden Publisher: John Wiley and Sons Publication Date: 2004 ISBN: 0470861940 Title: Requirements by Collaboration Author: Ellen Gottesdiener Publisher: Addison Wesley Publication Date: April 2002 ISBN: 9780201786064 Page 21 of 21