BCS Exam Notes PDF

BCS Exam Notes 1. What is Business Analysis (5%) 1.1 Describe the business change lifecycle Alignment is concerned with ensuring that the organisation's objectives and strategy are aligned with the external business world and that...

BCS Exam Notes 1. What is Business Analysis (5%) 1.1 Describe the business change lifecycle Alignment is concerned with ensuring that the organisation's objectives and strategy are aligned with the external business world and that any changes to this environment are considered and, if appropriate, accommodated. This stage also aims to ensure that any proposed business changes are aligned with internal policies and architectures. Definition is concerned with taking a closer look at a proposed business situation in order to uncover root causes of problems, conduct a thorough analysis, recommend relevant, feasible changes and define requirements. Business analysts define the business and solution requirements during the definition stage. Design and development is concerned with the detailed specification, development and testing of the solution, including business processes and related tasks, and the software that is needed to support them. Implementation is concerned with planning, preparation and deployment of the business changes. Realisation is concerned with review of the predicted business benefits with a view to identifying those that have been achieved and identifying where further action is needed to achieve those benefits still to be realised. 1.2 List the following principles of business analysis: 1.2.1 Root causes not symptoms To distinguish between the symptoms of problems and the root causes. To investigate and address the root causes of business problems. To consider the holistic view. 1.2.2 Business improvement not IT system change To recognise that IT systems should enable business opportunity or problem resolution. To analyse opportunities for business improvement. To enable business innovation and customer experience enhancement. 1.2.3 Options not solutions To challenge pre-determined solutions. To identify and evaluate options for meeting business needs.  BCS Exam Notes 1.2.4 Feasible, contributing requirements, not meeting all requests To be aware of financial and timescale constraints To identify requirements that are not feasible and do not contribute to business objectives. To evaluate stated requirements against business needs and constraints 1.2.5 Entire business change lifecycle, not just requirements definition To analyse business situations. To support the effective development, testing, deployment and post- implementation review of solutions. To support the management and realisation of business benefits. 1.2.6 Negotiation not avoidance To recognise conflicting stakeholder views and requirements. To negotiate conflicts between stakeholders. 1.3 Describe the variants of the business analyst role Business BA / Enterprise business analyst: A business analyst role where the focus is on understanding the business situations to be improved and the business requirements to be met. This work is likely to require engagement with senior stakeholders as well as those at more junior levels and a focus on business system redesign. Requirements are defined from a business solution perspective and may be modelled using conceptual models such as business use case diagrams. Technical business analyst/ Business systems analyst: A business analyst role where the focus is on analysing the solution requirements and supporting the development of the software product. Where necessary, requirements may be specified using techniques to model system features (use case diagrams), data (class diagrams/entity relationship diagrams) and events (state machines and sequence diagrams). Digital business analyst: A business analyst role that is concerned with the opportunities digital technologies offer organisations. both to improve operations and enhance the personalisation and customisation of customer services and experience. This role requires extensive understanding of the business domain, customer experience requirements and technology. Project business analyst: A business analyst role where the focus is on developing the software product. This typically involves elaborating user stories in collaboration with business staff and product developers. This role may also require the application of a range of techniques in order to elaborate and clarify business rules and non- functional requirements relevant to the software product.  BCS Exam Notes 2. The Competencies of a Business Analyst (2.5%) 2.1 Explain the concept of the T-shaped Professional Highly skilled individuals who can adapt to different situations because of the range of skills they possess. These individuals are known as 'T-shaped professionals' because they hold deep skills in their specialist discipline and broad, generic skills across other disciplines. This mix of skills enables them to solve problems within their own specialism and to communicate effectively with colleagues and stakeholders from other areas.  BCS Exam Notes 2.2 Identify the three areas of business analysis competency Personal qualities: This is how business analysts think and interact with people. They are not specific to business analysis but are generic skills that are needed to work collaboratively within any business environment. Behavioural skills are a prerequisite for working with other people. Business knowledge: Business analysts also require business knowledge as it helps them to develop a good understanding of their organisation and the business domain Figure 2.3 The competencies of a business analyst or sector within which it operates. This knowledge is vital if the business analyst is to offer the advice and insights that help to improve the organisation's performance. Professional techniques: These techniques are those specific to the business analyst role and differentiate business analysts from other roles. There are numerous professional techniques that business analysts need to develop so that they can perform the role effectively and adapt to the range of situations they encounter.  BCS Exam Notes 3. The Strategic Context for Business Analysis (7.5%) 3.1 Describe business analysis and the strategic context Understanding the strategic context helps to clarify the environment in which the business analyst operates. This insight allows for the business analyst to contribute positively to the organisation's strategic journey through the delivery of business analysis services. Many benefits arise if the business analyst is aware and can apply knowledge of the strategic context. These include the ability to: Analyse and discuss strategic approaches and priorities; Build credibility when discussing the organisation with stakeholders; Question the appropriateness and alignment of decisions taken prior and during the execution of change; Analyse the effectiveness of the approach, outputs and benefits expected from a change initiative; Provide leadership and influence for the delivery of strategically aligned change. If the business analyst can apply knowledge of the strategic context, they are able to contribute positively to the organisation's strategic change journey, typically through the enhancement of the organisation's capabilities. If business analysts are not aware of the strategic context, they can potentially deliver outputs that harm or cause damage to the capabilities of the organisation. 3.2 Define the factors assessed using PESTLE to analyse an external environment Political forces within the international, national and local political environments. Examples include: Policies and decisions made by national and local governments Policies and decisions made by transnational political organisations such as the African Union, Arab League, European Union, United Nations, North Atlantic Treaty Organization (NATO) Trends and policies advocated by associations looking to further their political cause such as Amnesty International, Greenpeace, WWF. Economic forces within the international, national and local economic environment. Examples include: Interest rates. This impacts the cost of borrowing Inflation. This indicates the rate at which prices are stable or increasing within the economy Levels of employment. This impacts the availability of labour for an organisation Levels of disposable income. This impacts consumer spending power and can negatively or positively impact spending levels within the economy Availability and cost of resources. Growth trends in national and international economies Fluctuations in currency exchange rates. Socio-cultural trends within society and culture. Examples include: Changes to demographics. This includes changes to characteristics of the population such as ethnicity, gender, age, education levels, occupation, religion, marriage and birth/death rates Changes in preferences and habits. For example, the trend towards using smart devices Changes within popularly held viewpoints and opinions. For example, the increased prominence of speaking about mental health issues by celebrities or the increased discussion and focus on environmental concerns. Technological trends within technology. Examples include: The availability of new technologies such as Al, self-driving vehicles, smart devices, voice-enabled devices The increased connectedness of technologies The increased use of RPA (robotic process automation) Availability of skills to build and maintain technology platforms The movement towards digital products and services Legal trends and expectations that have legal or regulatory impact. Examples include: Data protection law Health and safety law Taxation rules and regulations Disability discrimination and or equality law Intellectual property law Market specific legislation and regulation  BCS Exam Notes Environmental trends and influences that are concerned with the natural environment. Examples include: Carbon emissions and climate change Changes to natural habitats (e.g. deforestation, shrinking of polar ice caps) Animal welfare Waste disposal and recycling 3.3 Identify the elements of the VMOST technique used to analyse an internal environment VMOST analysis Vision: Defines the target state for the organisation without regard to how this will be achieved. The target state is realised through the completion of the 'mission·. Mission: Describes what the organisation does or will do. Objectives: The specific objectives or outcomes that the organisation wants to achieve. These are used to guide and measure progress towards ihe organisation's vision and the completion of the mission. Strategy: The long-term approach that is going to be taken by the organisation to achieve the 'Vision', 'mission' and 'objectives·. Tactics: The specific and detailed means by which the strategy should be executed. The tactics are often adapted when feedback regarding the success of the strategy is received. 3.4 Describe the following elements of performance measurement 3.4.1 Critical success factors The areas in which an organisation must succeed in order to achieve positive organisational performance. 3.4.2 Key Performance Indicators (KPIs) Specific areas of performance that are monitored in order to assess the performance of an organisation. KPls are often identified in order to monitor progress of the critical success factors. 3.5 Describe the structure of a SWOT analysis The content and language used in SWOT analysis is important. Overall the SWOT should be accurate, complete, brief and clear. It should also align with the VMOST of the organisation.  BCS Exam Notes 3.6 Describe the following techniques used in strategy execution 3.6.1 The POPITTM model People: What knowledge and skills will people need in the target state? What levels of motivation will be required? How will people communicate? Skills, motivation, performance objectives, recruitment approach and criteria, appraisal and development approach, salaries and benefits. Organisation: Who will be the key partners and suppliers? What business model or organisation structure will be adopted? What culture will pertain within the organisation? What leadership and management approaches will be used? How many people are needed and in what roles? Job roles. management structures, culture, values, standards, policies. Processes: Which processes will be used in the target state? Are the processes optimal? What efficiency gains will be obtained? Process and task definitions, business events, business rules. Information: What change will be made to the capture. storage and analysis of data and information? How secure will the organisation's information and data be? Capture, recording, reporting and distribution of data and information. Technology: What technology will be used in the target state? How well will this align to the organisation's processes? Will the technology be scalable? Will the technology be interoperable? Software products, hardware, infrastructure, networking, communication, digital and other forms of technology. 3.6.2 The purpose of the business model canvas A business model describes the rationale of how an organisation creates, manages and delivers value.  BCS Exam Notes Customer segments: Who are the organisation's important customers? For whom is value proposed? Value propositions: What value does the organisation offer? Which customer problems or pains does it propose to solve? Which customer opportunities or gains do the products or services support or satisfy? What are the qualities (e.g. price, availability, choice, quality, functions supported) offered by the products or services? What is the relative value of the organisation's brand or image? Channels: How does the organisation interact and communicate with customers? Is there variance in customer experience across different channels? Which channels work best? What additional channels do customers expect? How do customers pay? Customer Relationships: What is the nature of the relationship that the organisation has with each customer segment? Where might it be possible to enhance the customer experience? Revenue Streams: What are the organisation's revenue streams? How profitable are each of these revenue streams? How much does each revenue stream contribute? Key Resources: What key resources do the organisation's value proposition, channels and customer relationships require? Key Activities: What key activities do the organisation's value propositions, channels and customer relationships require? Key Partners: Who are the organisation's key partners and suppliers? Which key resources or key activities do they provide? Cost Structure: What are the costs of the key resources, key activities and key partners employed in the business model? Is the cost structure sustainable?  BCS Exam Notes 4. The Business Analysis Service Framework (2.5%) 4.1 Identify the following services in the Business Analysis Service Framework (BASF) 4.1.1 Situation investigation and problem analysis The situation investigation and problem analysis service offers the following value proposition: State a clear definition of the problem to be addressed and the business needs to be met. Define the scope of the work to achieve this. Where undertaking a project is relevant to addressing the business issue, clarity in outline the investment objectives and business benefits to be achieved by the project. Activities: 1. Investigate the situation and the problem or opportunity 2. Understand the strategic context for the situation 3. Identify and articulate the business needs 4. Define the problem 5. Define the scope of the business change project 6. Define the rationale for rejecting a project proposal 4.1.2 Feasibility assessment and business case development The feasibility assessment and business case development service offers the following value proposition: Define the rationale for a proposed business change. Generate, describe and evaluate the options to achieve the business requirements. Quantify and/or describe the investment objectives and predicted business benefits. Support informed decision-making regarding business change investment. Activities: 1.Generate and describe options to resolve the problem 2.Remove unviable options 3.Identify and analyse impacts and risks for each option and what may be done about them  BCS Exam Notes 4.Identify and analyse costs and benefits for each option 5.Evaluate financial, technical and business feasibility of options 6.Evaluate alignment of options with strategic goals 7.Support comparison and selection of solution 4.1.3 Business process improvement The business process improvement service offers the following value proposition: Describe and redesign existing business processes. Define required process changes that will enable business improvement and business benefit realisation. Identify the actions to be undertaken to deploy the improved processes. Activities: 1. Model existing processes 2. Define required (new or revised) processes 3. Identify gaps between existing ('as is') and required ('to be') processes 4. Analyse gaps between existing and required processes 5. Identify and analyse business process measures 6. Identify actions to implement new processes 7. Ensure alignment between IT systems and processes 4.1.4 Requirements definition The requirements definition service offers the following value proposition: Elicit, analyse, describe and manage requirements that are to be addressed by business and IT changes, at the level of detail relevant to the context. Define requirements that will enable business improvement and business benefit realisation Activities: 1. Define requirements definition approach and quality standards 2. Elicit and interpret the requirements 3. Record requirements 4. Build models and prototypes to represent the requirements 5. Collaborate and communicate with internal stakeholders in the business and IT functions, and external stakeholders to clarify requirements 6. Analyse, prioritise and assure the quality of the defined requirements 7. Support stakeholder review of requirements 8. Conduct user analysis and profiling 9. Ensure requirements are aligned with project scope and strategic business goals 10.Establish traceability of requirements from the business need to the solution  BCS Exam Notes 4.1.5 Business acceptance testing The business acceptance testing service offers the following value proposition: Define acceptance tests for a business solution. Collaborate with stakeholders to support business acceptance of a business solution. Activities: 1.Agree scope for testing activity 2.Define test scenarios and test cases 3.Provide support to stakeholders when testing for business acceptance 4.1.6 Business change deployment The business change deployment service offers the following value proposition: Define transition requirements for the business changes. Collaborate with stakeholders to support the deployment of the required business changes and enable their adoption. Activities: 1.Assess business readiness 2.Support transition planning 3.Support the adoption of the IT and business changes 4.Develop and deliver training in the new business IT systems. 5.Support the benefits and post-implementation reviews 6.Support the realisation of the business benefits 4.1.7 Stakeholder engagement This service is not included in the BASF because it is an auxiliary service. The value proposition, activities and techniques involved in stakeholder engagement are relevant whenever a business analyst is conducting any of the other services. The stakeholder engagement service offers the following value proposition: Support the achievement of business change and IT project success through stakeholder collaboration, communication and effective stakeholder relationship management. Activities: 1.Identify stakeholders 2.Challenge and inform stakeholders 3.Negotiate stakeholder conflicts 4.Engage with stakeholders 5.Communicate with stakeholders verbally and in writing 6.Support stakeholders 7.Facilitate meetings and workshops and record outputs  BCS Exam Notes 5. Investigating the Business Situation (12.5%) 5.1 Define workshops A meeting attended by business actors from a range of business areas and run by a facilitator, for the purpose of eliciting, analysing or validating information. An agenda is prepared prior to the workshop and distributed to participants. The actions and decisions are recorded by ascribe. 5.1.1 Advantages and disadvantages of workshops Advantages: Gain a broad view of the area under investigation: Having a group of stakeholders in one room allows the analyst to gain a more complete understanding of the issues and different views at play. Some of these issues may well be political or cultural, and the analyst has to pay attention to the interactions and dynamics of the group to get early insight into the prevailing business and stakeholder perspectives. Increase speed and productivity: It is less time-consuming to have one extended meeting with a group of people than interviewing them one by one, cross-referring responses for agreement or divergence and conducting follow-up sessions. Obtain buy-in and acceptance for the project: When stakeholders are involved in a collaboration, they are not only more accepting of any suggestions for change, they are also more likely to be champions for the agreed ways forward. Gain a consensus view or group agreement: If all of the stakeholders are involved in the decision-making process, there is a greater chance that they will take ownership of the results. If two or more stakeholders have different viewpoints at the outset, there is a better chance of helping them move to an agreement in a well-facilitated workshop as long as they feel that their concerns and views have been listened to respectfully and any particular concerns have been addressed. Disadvantages: Extensive preparation time: Workshops can be time-consuming to organise. For example, it is not always easy to arrange for all of the key stakeholders to be together at the same time. Undue influence of dominant personalities: If a workshop is not facilitated carefully, forceful participants can tend to dominate the discussion. In extreme cases, such a participant may be able to impose a decision because the other members of the group feel disempowered and unable to raise their objections. Authority limitations: It can be difficult to ensure that workshop participants have the required level of authority - which sometimes means that decisions are reversed after the workshop has ended. This can be a problem especially in an organisation with a culture where power radiates from a few central people or where there is a strong hierarchical structure. If there are two authoritative stakeholders with opposing views, the facilitator may have to use a range of skills to keep the workshop on track and moving towards achieving its objective 5.1.2 List techniques used for discovery workshops Brainstorming: Participants are asked to call out ideas about a given topic. All of the ideas are written on a flipchart or whiteboard as they are suggested. It is important that all suggestions can be seen by all of the participants as this allows them to build on each other's ideas. Evaluation of the ideas is suspended until everyone has finished making suggestions. This technique is particularly relevant for groups where the participants know each other well and are comfortable calling out ideas in an open forum. It is less useful where participants lack the confidence to call out suggestions or prefer a more reflective approach. Round robin discussions: Participants are asked to provide their ideas in turn. This can be very useful to encourage participation from those who do not like brainstorming because they are uncomfortable when required to interrupt others in order to call-out ideas. Round robin discussions provide each participant with an opportunity to speak without fear of interruption or being ignored. One difficulty is that during the 'round' participants may want to comment on an earlier contribution rather than offer their own idea, and without good facilitation it can turn into a discussion on just one or two points without all participants having the opportunity to offer their own idea.  BCS Exam Notes Brain-writing: This technique has similarities with brainstorming but requires participants to write down ideas rather than call them out. Each person writes an idea on a sheet of paper and then puts it in the middle of the table. Everyone then takes another sheet with an idea already written on it, writes down another idea and then returns the paper to the centre. This continues until there are no more ideas being generated. This approach overcomes the problem where participants are not sufficiently confident to interrupt others and call out their ideas but still enables them to build on the ideas of others. Sticky: Ideas are written down on Post-it notes, but the participants work individually or in pairs. Each individual or pair writes down their suggestions - one per sticky note - and, once everyone has stopped writing, displays them to the group, usually by sticking them on a wall or board. Once all of the suggestions have been displayed, those that are similar are grouped together using affinity mapping and broader themes are identified. Stepwise refinement: The facilitator proposes a statement or idea and asks 'why?' continually until the heart of a problem, idea or situation has been uncovered. Break-out or syndicate group exercises: Many workshop participants prefer to work in small groups as it is easier for them to make suggestions or develop their ideas. Typically, a volunteer from each smaller group reports back to the larger group. This is a powerful way to manage a larger workshop, particularly where there is a range of skills and knowledge. It can also be useful for each break-out group to have its own sub- facilitator 5.1.3 List techniques used for visualisation workshops Process models: Using one of two standardized styles of graphical business process notation: Business Process Modelling Notation (BPMN) — also called Business Process Model and Notation — or Unified Modelling Language (UML). Within these notation systems, certain visual elements have universally recognized meanings when used in a process model. Whether an organization uses UML diagrams or BPMN diagrams, these standardized notation methodologies allow process models to be easily shared and read by anyone:  Arrows represent sequence flows  Diamonds represent decision points or gateways  Ovals represent beginnings and endpoints of processes  Rectangles represent specific activities within a workflow  Swim-lanes are used to identify who owns which components of a process Rich Pictures: A pictorial technique offering a free format approach that allows analysts to document whatever is of interest or significance in the business situation. Mind Maps: A technique pioneered by Tony Suzan that represents an issue as a diagram with the name of the issue in the centre and aspects associated with it as radiating branches. Context Diagrams: An outline visual representation of a business or IT system, comprising a box or circle and the interactions the system has with external actors and systems. Use case diagram: A diagram showing the use cases within the scope of a business or IT system and the interaction of these which business actors. Task Scenarios: A technique used to elicit, analyse and validate requirements. A scenario will trace the course of a transaction from an initial business trigger through each of the steps needed to achieve a successful outcome, Alternative scenarios, for example, where specific conditions are not met, are also traced. User Stories: A technique used within Agile development approaches where a feature required by a user role is stated in terms of what a system should do and why the delivery of the required feature would be beneficial.  BCS Exam Notes 5.2 Define observation A technique used within requirements elicitation where an analyst observes work being performed with a view to identifying issues and/or requirements to improve a business situation. 5.2.1 Advantages and disadvantages of observation Advantages: A much better understanding of the problems and difficulties faced by the business users is obtained. Seeing a task performed helps to identify relevant questions for a follow-up interview with the person responsible for that task. The depth of understanding gained from observation helps in identifying workable solutions that are more likely to be acceptable to the business. Disadvantages: Being observed can be rather unnerving so people tend to behave as they feel is expected rather than how they would under normal work conditions. The saying 'you change what you observe' needs to be factored into the approach taken and the findings obtained. When observing a task being performed, the analyst just sees what happens on that particular occasion. Title routine activities are likely to be performed but there may be other aspects of the process that are carried out infrequently and, if they are not needed during the observation session, the analyt may be unaware of them. For example, conducting an observation on a Wednesday morning would mean that the final summarising task performed each Friday afternoon is not observed. 5.2.2 Formal observation Formal observation involves watching a specific task being performed. While this form of observation runs the risk of staff following standard practices without demonstrating any of the everyday variances, this is still a useful technique to increase understanding of the business situation. It is important that the staff members being observed are prepared beforehand and are aware that the focus is on understanding the task rather than assessing competence and performance. Self-consciousness can influence how the staff member performs and a lack of prior notice serves to accentuate this problem. If the staff members perceive the observer as having been sent by management, they are more likely to perform the task according to the rulebook, rather than how it has evolved over time. When observing a task, it is acceptable to ask those being observed about the sequence of' steps they are following, so long as the question does not: Sound critical of the way the person is working, either in words or tone of voice; Distract from their performance of the job. The analyst must position themselves in such a way that they can see clearly all that is happening but do not interfere with the completion of the task. 5.2.3 Shadowing Shadowing involves following a member of staff for a period, such as one or two days, to find out what a particular job entails. This is a powerful way to understand a specific user role. When shadowing someone, the analyst can request explanations of various aspects of the work performed in order to clarify what the individual actually does to perform the role. These aspects include how the work is done, the information used or the workflow sequence. Shadowing key staff is a useful approach when investigating a business situation as it helps to highlight the nature of problems and why they have arisen. It also improves requirements definition work since it provides a visual context for processes described during interviews or workshops. 5.3 Define interviews An investigation technique to elicit information from business users. An interview agenda is prepared prior to the Interview and distributed to participants. The interview is carried out in an organised manner and a report of the interview is produced once the interview has been concluded. 5.3.1 Advantages and disadvantages of interviewing Advantages: They help the analyst to understand different viewpoints and attitudes across the user group. They provide an opportunity to investigate new areas that were not previously mentioned. Enable the analyst to identify and collect examples of documents, forms and reports used by the clients. They allow an appreciation of political factors that may affect how the business performs its work. They provide an opportunity to study the environment in which the business staff carry out their work.  BCS Exam Notes Disadvantages: Interviews can require significant investment of time and budget, particularly if the business staff are widely dispersed. They require interviewees to allocate sufficient time if the interview is to be of use and this may prove difficult within a busy schedule. This may mean that interviewees try to speed up the interview and may resent the time required to participate. The information provided during interviews is often based upon opinion and is likely to derive from the interviewee's perspective on the situation. Therefore, quantitative data may be required to confirm the information elicited during interviews before any firm conclusions can be drawn. Different interviewees often hold different views and, where this is the case, the business analyst needs to analyse the information gathered in order to identify conflicts. This may create a need for follow-up interviews or meetings to investigative the situation further and attempt to build consensus. 5.4 Define scenarios A technique used to elicit, analyse and validate requirements. A scenario will trace the course of a transaction from an initial business trigger through each of the steps needed to achieve a successful outcome, Alternative scenarios, for example, where specific conditions are not met, are also traced. Process: Identify the task or interaction to be modelled as a scenario and the trigger, or event, that causes that interaction to take place. Identify the steps that are carried out during the usual progress of the interaction and the flow of these steps. Define the control conditions that must be met in order to move from one step to the next, following the typical sequence of steps. Identify alternative paths that would be required to handle situations where the control conditions are not met. 5.4.1 Advantages and disadvantages of scenarios Advantages: They require the member of staff to identify each step required to carry out a transaction, and the transitions between the steps; this reduces! or even removes, the opportunity for omissions. The step-by-step development approach helps to ensure that there are no taken-for-granted elements and the problem of tacit knowledge is addressed. They are developed using a 'top-down' approach, starting with an overview scenario and then refining this with further detail. This helps the staff to visualise all possible situations and removes uncertainty, A workshop group with responsibility for refining a scenario should identify those paths that do not suit the corporate culture or are not congruent with any community of practice involved. They provide a basis for developing prototypes. They provide a painstaking basis for preparing test scripts. Disadvantages: Can be time-consuming to develop and some scenarios can become very complex, particularly where there are several alternative paths. Where this is the case, it is easier to analyse the scenarios if each of the alternative paths is considered as a separate scenario. 5.5 Define prototyping A technique used to elicit, analyse and validate requirements. Prototyping involves building simulations of documents, processes or systems in order to enable the business users to visualise any proposed changes and hence increase understanding about the system requirements. 5.5.1 Advantages and disadvantages of prototyping Advantages: They clarify any uncertainty on the part of the analysts and confirm to business staff that their requirements have been understood. They help the business staff to identify new requirements as they gain an understanding of how the system will operate and what the system will do to support their work. They demonstrate the look and feel of the proposed system and elicit usability and accessibility requirements. They enable business staff to validate the requirements and identify any errors. They provide a means of assessing the navigation paths and system performance.  BCS Exam Notes Disadvantages: The prototyping cycle can spin out of control with endless iterations taking place. If the purpose of the exercise has not been explained clearly, business staff may make false assumptions about the progress of the work and believe that the solution is almost ready for delivery on the basis of an agreed prototype. Expectations can be raised unnecessarily by failing to match the final appearance of the system or its performance. A system that is on a stand-alone machine that is accessing six dummy data records is likely to be more responsive than a machine that is accessing a shared resource with thousands of other users. If there is likely to be a delay in the real response time, it is important to build that into the prototype. 5.6 Define user role analysis A technique used to identify and understand the actors who need to interact with a proposed business or IT system. 5.6.1 Advantages and disadvantages of user role analysis Advantages: A means of identifying where stakeholders have common interests or requirements. A more efficient approach to eliciting and analysing requirements. A strong basis for analysing scenarios. stakeholder perspectives, use cases and user stories. Disadvantages: Generic user role names cover a very wide stakeholder group, which makes it difficult to envisage how and why individuals might want to use particular system. 5.6.2 Personas An artefact associated with user role analysis whereby a user role is given more realism by the creation of a fictitious profile that comprises a named individual, and their personality characteristics and abilities. Personas can also be useful when analysing users of the business system who have particular accessibility requirements. For example a persona representing customers who have a specific disability might be defined in order that their accessibility requirements may be fully explored and understood. 5.7 Define quantitative approaches In requirements elicitation, techniques that aim to uncover quantifiable data. Quantitative approaches are used to obtain data that is needed to quantify the information that has been collected during workshops, interviews or when using other qualitative techniques. Quantitative data may include the following: the number of people using a particular system. the number of complaints received during a set period. the number of bookings processed each day. 5.7.1 Surveys or questionnaires Surveys can be useful to get a limited amount of information from a lot of people as interviewing them individually or running a series of workshops is not practical or cost-effective. The three main areas to consider are: the heading, classification and data sections. Heading section: This is where the purpose of the survey is explained. It is important that the heading section explains the rationale for the survey, how the data is intended to be used and, where appropriate, any incentive for its completion. A well-formed heading section helps the respondents to understand why the information is needed and as a result may significantly increase the volume of responses. Classification section: This is where the details about the respondent are captured. This data provides the basis for categorising the respondents using predefined analysis criteria, like age, gender or length of service. Data section: This is where the main body of questions is posed. It is vital to think carefully about the phrasing of the questions. They must be unambiguous and, ideally, allow for straightforward answers such as 'yes/no', 'agree/neutral/disagree' or 'excellent/satisfactory/inadequate'. Where opinions are sought, the Likely scale is often used. This scale asks for an answer within the following range: strongly agree, agree, neither agree nor disagree, disagree, strongly disagree.  BCS Exam Notes 5.7.2 Activity sampling Activity sampling is also a quantitative form of observation and is used when it is necessary to know how people divide their work time among a range of activities. Process: 1. Identify the activities to be recorded. This list should include a 'not working' activity as this covers breaks or times away from the desk. It might also include a 'not-related' task, such as first aid or health and safety officer duties. 2. Decide on the frequency and timings, i.e, when and how often to record the activities being undertaken. 3. Visit the study group at the times decided upon and record what each group member is doing. 4. Record the results. 5. After a set period. analyse the results. 5.7.3 Document analysis Document analysis involves reviewing samples of source documents or reports to uncover information about an organisation, process or system. The documents may be in physical form or may be software-based. Analysts sometimes need to define questions to ask about a business area or problem situation and this can be difficult. Document analysis helps to identify many questions, each of which helps to develop the analyst's understanding. The following questions may be asked about each document: How is the document completed? Who completes the document? Are there any validations or controls on the document? Who uses the completed document? When is the document used? How many are used or produced? How long is the document retained by the organisation, and in what form? What are the details of the information shown on the document? Where is the data or information obtained? Are other names used in the organisation to refer to any of the items of data? Are all the data items on the document still needed, or are any redundant? Is there other data that is not entered on the document, but would be useful for this process? 5.8 Describe the following two diagrammatic techniques used to record a business situation 5.8.1 Rich pictures A pictorial technique offering a free format approach that allows analysts to document whatever is of interest or significance in the business situation. A rich picture allows the analyst to document all of the organisational, human and cultural aspects as well as process and information flows of a business system. The unstructured nature of the technique allows the analyst to build a personal visualisation of the information using pictorial representation. Its strength is that the process of building the rich picture helps the analyst to form a mental map of the situation and see connections between different issues. 5.8.2 Mind maps Mind maps are a useful tool for summarising a lot of information in a visual form. The information is structured to highlight connections between ideas and topics. They provide a means of representing all of the issues that have been uncovered about the situation but ir, an organised manner. The business system or problem under consideration is drawn at the centre of the diagram with the main topics or issues shown as the first level of branches radiating from the central point. Each of these branches is labelled to indicate the nature of the particular issue. The labels should use as few words as possible and ideally should be just one word. The branches might represent particular processes, equipment and systems used, relationships between the staff who conduct the work and so on.  BCS Exam Notes 6. Analysing and Managing Stakeholders (10%) 6.1 Identify stakeholder categories using the stakeholder wheel Customers: These are the people or organisations for whom the organisation provides products or services. They are stakeholders because anything done in the way of change has a potential effect on them. It may be useful to subdivide the term 'customer' into specific categories, such as large or small, regular or occasional, wholesale or retail, corporate or private, commercial, non-profit or public-sector, civilian or military, domestic or export. Partners: These are the organisations that provide specialist services to the organisation or work on its behalf. Examples of partner organisations may be a reseller of products or services, or an outsourcing company that provides catering services. Suppliers: Suppliers are stakeholders because they are interested in the way the organisation does business with them, what it wishes to buy, how it wants to pay and so on. Many change initiatives have the effect of altering the relationships of organisations with their suppliers and, as with the customers, such changes need to be managed carefully to make sure that they achieve positive and mutually beneficial results. They may be subdivided into the following major or minor, regular or occasional, domestic or overseas. Regulators: Many organisations are now subject to regulation or inspection by external authorities. Regulators are concerned that any changes proposed by an organisation comply with the rules they enforce. For example, laws and regulations that govern an organisation's financial conduct or professional standards, such as those required of the medical profession. Employees: The people who work in an organisation clearly have an interest in the way it is run and in changes that it makes. In a small firm, the employees may be regarded as individual stakeholders in their own right but, in larger organisations, they are probably best considered as groups. Managers: There are also the professional managers of the organisation, those to whom its direction is entrusted. In a large organisation, there may be many layers of management and each may form a distinctive stakeholder grouping, for example board-level senior managers, middle managers, junior managers and supervisors. Owners: For a commercial business, the owners are just that - the people who own it directly. The business may be, in legal terms, a sole trader or partnership, or it could be a limited company, in which case the owners are the shareholders. For public limited companies, the majority of shares are held by institutions such as investment companies and pension funds and so the managers of these share portfolios become proxy owners. Competitors: Competitors vie with the organisation for the business of its customers and, therefore, they have a keen interest in any changes made by an organisation. Their reactions to any changes have to be considered; for example, how a competitor might react and whether they might try to block an initiative or to produce a form of counterproposal.  BCS Exam Notes 6.2 Describe the Power/Interest grid technique to analyse stakeholders Having identified the stakeholders, the next step is to make an assessment of the weight that should be attached to their issues. No stakeholder should be ignored completely but the approach to each will be different depending on (i) their level of interest in the project and (ii) the amount of power or influence they wield to further or obstruct it. In using the power/interest grid, it is important to plot stakeholders where they actually are, not where they should be. Strategies can then be explored for managing them in their positions or, perhaps, for moving them to other positions that might be more advantageous for the success of the project. Some or high interest but no or low power/influence: These groups can be very difficult to manage effectively as, although they may be very directly affected by a change project, they feel powerless to shape its direction in any way. This can result in frustration and a sort of passive resistance to change that, though overcome by positional power, can lead to delay and less- than#optimal results. The management strategy for these stakeholders is to keep them informed of what is going on and of the reasons for the proposed change. However, this can be a rather passive approach and, in many circumstances, more effort should be devoted to selling the benefits of the project. This call best be done by being as honest as possible about the need tor change, and highlighting the positive aspects of the change and the negative consequences of not making them. Frequent and focused communication regarding progress is also necessary when managing these stakeholders. No or low to high interest but some power/influence: his is a rather varied group. It includes some stakeholders like middle or senior managers who do have some power or influence but, because their interests are not directly affected, are not very concerned about the direction a project is taking. Regulators may also fall into this category although they will only become involved if there is a suspected breach of their rules. This group can also include those with a higher level of interest in the project but who have only limited power or influence. The best approach with this group is to keep them supportive of the project. possibly by issuing frequent information updates to them, and also by increasing their involvement with the project. As the old saying has it, it is better to have them inside the glasshouse throwing stones out than outside throwing them in. No or low interest but high power/influence: These are probably very senior managers who, for one reason or another, have no direct interest in the project. This may be because it is too small or unimportant for them to bother with or it may be that it is in an area that doesn't interest them. For example, the marketing director for an organisation is unlikely to be concerned about a project to streamline the stationery purchasing procedures and it may be assumed that this stakeholder can be ignored. However, this is actually a rather risky approach. The marketing director may become very interested in the stationery procurement system if items such as pens or sticky notes are unavailable in time for an important meeting or conference. Where a situation arises that might cause these stakeholders to take a greater interest in the project, it might be prudent to address their needs directly, possibly via one-to-one meetings, in order to ensure that they do not start to raise concerns or even decide to exert their influence. In some situations, the project team may wish to encourage the increased interest of  BCS Exam Notes influential stakeholders, for example, if it was felt that their support would help achieve the project objectives. Where this is the case, it may be necessary to highlight any aspects of the project that have a direct impact upon the stakeholders business area; some form of discussion will be required that, with very influential stakeholders, would typically involve a meeting. Some interest and high power/influence: These stakeholders have some interest in the project, and they have actual power over what happens. The key strategy to manage these stakeholders is to keep them satisfied, so that they do not take a more direct (and hence, possibly, more obstructive) interest in the project. However, in some circumstances, the strategy may be to encourage these stakeholders to become more actively involved in a project. For example, if the finance director for an organisation can be persuaded to be positively involved in a project, they may be a powerful force for success, since they can make resources available that would otherwise be hard to obtain. High interest and high power/influence: These are the key players, the people who are both interested in the project and have the power to make it work or not. Often, the key players are the managers of the functions involved in a project. Initially, it is important to determine if individual key stakeholders are positive or negative in their approach to a project. If positive, then their enthusiasm must be sustained, especially during times of difficulty. It is also important to appreciate the concerns and opinions of key stakeholders and these will need to be taken into account when making any recommendations. These are the people to whom any final recommendations will be presented and who will have the final say on any decisions. They need to be kept informed at all stages of the project so that none of the recommendations comes as a shock to them. 6.2.1 Resulting stakeholder management strategies 6.3 Describe stakeholder responsibilities using RACI A RACI chart (Responsibility Assignment Matrix) is a way to identify your project teams’ roles and responsibilities for any task, milestone, or project deliverable. By following the RACI acronym, you can clarify responsibility and reduce confusion. RACI stands for: Responsible. This person is directly in charge of the work. There should only ever be one Responsible role per task so you know who to go to with questions or updates. If a task has more than one Responsible person, you can lose clarity and cause confusion. Instead, aim to add additional collaborators as some of the other RACI roles, which can have more than one person. Accountable: The Accountable person is responsible for overseeing overall task completion, though they may not be the person actually doing the work. There are two ways to assign an Accountable role. Sometimes, the Accountable is the project manager (or even the Responsible, though in that case the person is taking on two different roles during the task workflow). In these cases, the Accountable is responsible for making sure all of the work gets done. In other cases, the Accountable is a senior leader or executive who is responsible for approving the work before it’s considered complete. Like the Responsible role, there should only ever be one Accountable. Consulted: This will be the person or people who should review and sign off on the work before it’s delivered. There may be multiple Consulted roles for each task, project milestone, or deliverable. Informed: This is the person or group of people who are informed about the progress and completion of work. They probably are not involved in any other aspect of the deliverable. Example of a RACI chart To build a RACI chart, list every task, milestone, or deliverable for your project. Then, identify who the Responsible, Accountable, Consulted, and Informed team members are for each one. Let’s say you’re updating the homepage on your website. Project stakeholders include: Copywriter, Designer, Head of website, Web developer. You want to create a RACI chart for five tasks and deliverables: 1. Update homepage CTAs 2. Update customer story on homepage 3. Revamp website design 4. Improve homepage loading speed 5. Update homepage design  BCS Exam Notes 7. Improving Business Services and Processes (12.5%) 7.1 Explain the business process hierarchy The business process hierarchy comprises three levels: Enterprise level: the value stream required to deliver products or services. An organisation may identify several value streams, each of which comprises a set of activities that together offer a value proposition to customers. The customers' value expectations should be understood when analysing a value stream. Event-response level: the business process that forms the organisation's response to a business event and encompasses a set of tasks, each of which is performed by a designated actor. Together these tasks deliver the defined outcome from the business process. There may be several event#response level business processes for each value stream activity. Actor-task level: the task, which is formed of a set of steps, that is carried out in response to a task-initiating event. Each task may require access to information, may be subject to performance measures and may be constrained and governed by business rules. 7.2 List the following techniques used to model the enterprise level processes An enterprise level process model shows the core areas of process that together deliver a product or service to the customer and fulfil the stated value proposition of the enterprise. 7.2.1 SIPOC SIPOC framework: The supplier, input, process, output, customer.  BCS Exam Notes 7.2.2 Value chain analysis A concept developed by Michael Porter to identify the primary and support activities deployed within organisations to create a value proposition to their customers. The value chain is helpful to structure thinking about the areas of process required to deliver a value proposition. The value chain comprises two areas of activity: primary and support. 7.2.3 Value propositions A clear statement of the value that an organisation offers customers through the delivery of a product or service. A value proposition is a key concept for organisations and has three areas of focus: Clarifying the outcomes offered by an organisation from the delivery of its products or services that the organisation believes will be perceived by customers to be beneficial. Demonstrating to customers that what is delivered will achieve what they desire or need. Differentiating organisations from their competitors. A value proposition can be a powerful mechanism where an organisation understands what customers require and value, and aligns this understanding with their values. 7.3 Describe the following aspects of the event response level 7.3.1 Business events Business events take place outside the business process under consideration and trigger the process to begin. The events may occur outside the organisation or may be internal. Some events are time-related where a business process is automatically initiated at a pre-defined point. Type of event Description Examples External Events that occur outside the area Customer-initiated business of business under consideration. events: booking made, order Typically, these events originate placed, purchase order received, from the consumers or suppliers. complaint received. Supplier- initiated business events: goods received, invoice received. Internal Events that occur within the Business manager-initiated: grade business area under review finalised; product change consideration. Typically, these decided; new supplier requested; events originate from senior staff recruitment requested. members of staff. Time-Based Events that occur at a given point End of month; 2 p.m. each Friday; in time. These events are midnight each day; end of financial predictable in advance and are reporting period. likely to occur with a time-based frequency.  BCS Exam Notes 7.3.2 Creating business process models Business analysts often build models that represent a current process, for the purpose of documentation, training or process improvement. This model is known as an 'as is' business process model. There are many standards for modelling business processes and they may be applied to both 'as is' and 'to be' business processes. Each standard has a defined notation set, that includes the following common elements: the overall layout of the model; the symbols used to denote the elements of the model, such as an event or task: the sequencing of the symbols. Two popular notation standards are provided by the Unified Modelling Language (UML) activity diagram and the Business Process Model and Notation (BPMN). 7.3.3 UML activity models Elements of a UML activity diagram: Event: The event that triggers the business process. This is shown as a filled-in circle. Actor: A named person, group or IT system with responsibility for carrying out one or more tasks. Task: A round-cornered rectangular box that represents work conducted by an actor in one place at one time. Swim-lane: A 'row' of tasks that are conducted by one actor; a boundary is shown for each swim-lane to distinguish the work of one actor from that conducted by another actor. Where a task is completed by two actors together a task should be shown straddling both swim- lanes. Decision Point: A diamond-shaped box that represents the application of a business rule in order to determine the next task to be performed. Each process flow emerging from a decision point is clarified using a 'guard expression', which is shown in square brackets. The guard expression represents the business rule that determines whether or not the process can progress in a particular direction of flow. There may be several flows emerging from a 'decision diamond', each of which has a guard expression stating the rule that has to be satisfied. Fork and Join: Two lines are used to indicate where parallel processing is taking place Outcome: The situation resulting from the completion of the business process. This is shown as a bullseye - a lilied-in circle within an outer circle. Process Flow: An arrow shown from an initiating event to a task, between tasks or from a task to a final outcome. Timeline: A timeline indicating the length of time taken to conduct tasks within the process. This is an optional element but can be very helpful when considering organisational or customer timing requirements. 7.4 Describe the following aspect of the actor-task level A business process model shows the work carried out to complete the business process but at an overview level of description. The actor-task level of the process hierarchy concerns the work conducted within each individual task, which is the next aspect business analysts need to explore.  BCS Exam Notes 7.4.1 Analysis considerations at actor-task level 7.5 Describe analysis of the following aspects of the as-is process model A representation of a, business process within an organisation as it is currently performed. 7.5.1 Identifying problems Problems with business processes tend to fall within the following categories: Lack of customer focus: The process does not consider customer requirements and expectations so fails to provide what is needed: for example, there may be issues with the accuracy, timeliness or costs relating to the products or services offered. The business processes may focus on meeting the needs of the organisation rather than the needs of the customers. Lack of organisation focus: The process meets customer needs but at significant expense to the organisation. For example, there may be a lack of technological support, requiring excessive manual intervention in the process or some tasks may be redundant or duplicated for historical reasons. The needs of customers and the organisation must be considered when identifying problems with an 'as is' process. The organisation model at the top of the process hierarchy can help to clarify the value proposition offered and the value expectations of the customers. This information helps to determine the performance levels required of the business process and to establish where there are gaps. Any gaps between the required and actual performance levels should be analysed and improvements identified. 7.5.2 Analysing the handoffs A 'hand-off' occurs when one actor passes control of the process to another actor. This is clearly identified on a business process model where the process flow can be seen crossing from one swim-lane to another. Handoffs are often a cause of problems in business processes as they may cause information to be lost, communication to fail or work bottlenecks to occur as one actor relinquishes responsibility but the next actor fails to act in a timely manner - or even at all! Actors are often busy completing their own tasks and assume that any outputs they produce are dealt with immediately, but, in practice, this may not be the case. Handoffs are often the root cause of process problems in all types of organisation. Identifying where handoffs occur, and analysing them to identify potential problems, is a key element of business process improvement.  BCS Exam Notes 7.5.3 Analysing the tasks and procedures Where 'as is' processes have been in place for some time and changes have been made in an incremental way, problems may have been introduced inadvertently. The problems may concern the ways in which different actors perform their individual tasks. The business analyst should consider the following areas to identify where tasks contain inefficiencies and inconsistencies: Duplication: Changes that may have caused them to duplicate part or all of the work carried out elsewhere. Redundancy: Tasks, or steps may have been required at one time but are now unnecessary. Lack of standardisation: Different templates and standards are used when carrying out the tasks. Inefficient work practices: Additional information or outputs have been required of the task, but these features have only been provided through the efforts of individuals and IT system workarounds. Inappropriate measures: Over time, the measures used. to control the work of the tasks have become less relevant. 7.6 Identify generic approaches to improving business processes Generic business process improvement strategies may be applied individually, in combination or within a more formal framework such as Six Sigma. Simplification: Eliminate redundant tasks either by combining or removing them. The general principle is that all tasks should contribute to the overall success of the process. Any task that does not contribute to achieving the process objectives should be eliminated. This strategy reduces the running costs and resources used by the process, and removes the handoffs and any related delays. This can result in further improvements such as a reduction in errors and duplication. Redesign: Workarounds are often created to deal with business scenarios that are not covered by the 'as is' process. These workarounds are likely to be inefficient as they are developed to adapt tasks in ways that were not originally intended. It is also possible that different actors handle such scenarios in different ways. The process may be improved by redesigning the work carried out within tasks to incorporate the scenarios. Bottleneck Removal: Bottlenecks result when there is a mismatch in the capacities of related tasks. For example, there is a mismatch if task A deals with 50 transactions per hour and these are passed on to the actor carrying out task B, which can only deal with 40 transactions per hour. In this example, the bottleneck may be removed by increasing the resources undertaking task B or by analysing the tasks to see if it is possible to simplify the work. Real life processes are often very complex and require detailed analysis to identify such capacity mismatches. It may be necessary to use process modelling tools to simulate tasks and examine the performance and resource requirements of proposed process redesigns Change Task Sequence: The sequence of the tasks within a business process can be changed to improve performance. It is also possible to define a 'to be' process where tasks are carried out in parallel in order to improve productivity and timing. Redefine Boundary: The boundary of an 'as is' process may be changed in order to improve the process. This may involve extending or reducing the tasks within a process; for example, by outsourcing tasks or even complete business processes to specialist organisations. Technology may also be used to redefine the boundary of processes so_ that external stakeholders, such as customers or suppliers, carry out tasks in place of the business staff. Examples of such boundary redefinition involve placing orders or booking rooms online Automate Processing: Automation can carry out processing with greater reliability and speed. I t can also result in the standardisation of data that supports the processes. Process automation may be achieved through the following approaches: Bespoke software development. The business process model and the task descriptions provide an excellent basis to define the detailed requirements of a bespoke IT solution. Software products. Off-the-shelf software products incorporate best practice processes. They are typically used to support standard functions such as finance or HR. Workflow management systems. These systems control the flow of electronic documents or transactions through the various tasks of a process.  BCS Exam Notes Six Sigma is a highly methodical and structured approach to process improvement that uses data and statistical measurement to identify where improvements should be made to obtain the greatest business benefit. The aim is to reduce errors so that all processes meet or exceed customers‚ expectations and that there are no more than 3.4 defects per million occurrences. Six Sigma follows a five step approach known as DMAIC: Define the problem. Investigate the situation to understand the objective of the change project and to find out where the symptoms and problems lie. There may be more than one problem, some more serious than others. Measure the data. Collect data that illustrates the problems, including data that identifies where they occur within the process. The focus should be on those areas that are more serious. Analyse the problem. Analyse the data to understand why problems are occurring, Identify and test propositions that explain the causes of the problems. Identify the root causes of problems. Improve the process. By addressing the root causes of the problems. Define options for improving the situation and evaluate these options. Design, test and implement the chosen solution. Control the effectiveness of the solution. Monitor it to ensure that the process has been improved and to prevent the original problem from reoccurring. 7.7 Define the purpose of customer journey maps Customer journey maps examine processes from the customer's perspective. There are some key elements that should be considered when developing a customer journey map.  BCS Exam Notes 8. Defining the solution (7.5%) 8.1 Describe the gap analysis process Gap analysis is a systematic process, whereby the existing situation is compared with the desired or target system in order to identify where there are differences and where changes need to be made. Performing a gap analysis is straightforward. First, identify the area to evaluate and state its ideal outcome. Next, analyse its current state. Compare that with the ideal results, and quantify the difference. Finally, make a plan to bridge the gap. The basic steps for performing a gap analysis are explained below. Identify the area to be analysed and identify the goals to be accomplished. For example, you may want to figure out why your factory is not meeting its output target. The goal will be to discover the causes that contributed to targets not being met, and recommend how to remove the causes. Establish the ideal future state. If everything worked according to plan, where would you be? Analyse the current state. What causes contributed to the targets being missed? For example, were the workers not trained well enough? Was the production floor short-staffed? Were required materials consistently available? Did the layout of the production floor slow things down? Compare the current state with the ideal state. How far from the target was actual production? For example, did you expect to produce 1,000 units per hour, but only managed to produce 800 units per hour? Describe the gap and quantify the difference. In the unit production example there would be a 20 percent shortfall. After researching the potential causes, outline the contribution of each to the gap. In this example, we may find that insufficient training caused 5 percent of the gap, staffing problems caused 7 percent, material shortages caused 2 percent, and inefficient layout of the factory floor caused 14 percent. Companies can use other ratings systems to quantify the difference that can be as basic as simple terminology like good, fair, and poor, to something more detailed like a 1-50 scale. Summarize the recommendations and create plan to bridge the gaps. Decide what needs to be changed and determine what steps need to be taken to fix things. In this example, the team performing the analysis may decide the layout issue is the easiest to tackle and will have the greatest impact, so they might recommend ways to address it. Then they could work with the supply chain and staffing teams to create recommendations for those issues as well. They would summarize their ideas and present it to management to begin planning the improvements. 8.2 Explain the use of POPITTM in gap analysis The POPIT model ensures that all internal business aspects are considered when investigating a business area. It helps a business analyst identify where problems exist. This holistic approach helps ensure the analyst considers all relevant areas.  BCS Exam Notes 8.3 Describe the process for developing options Identifying options is best achieved through discussion, typically in a meeting or workshop, where brainstorming and other creative thinking approaches can be employed. Modelling techniques such as business activity modelling or business process modelling and the results of the gap analysis, also help to generate options. The aim is to identify a variety of possible options before considering which are most beneficial. Even if some ideas seem unsuitable, they may provide part of the actual solution or give rise to similar, but more workable, suggestions. Options may also be identified by studying what other organisations have done to address the same issues. 8.3.1 Types of options The basic option deals with the most pressing issues, as quickly as possible and at minimal cost. This option may be based upon business process changes that require little if any technology change, or may involve the purchase of an off-the-shelf software product that can be installed relatively quickly and requires only limited changes to other POPIT dimensions such as the People skills and the Processes. In some circumstances, this may be a short-term option that can be enhanced at a later stage. The extended option adds some additional features to the solution but costs more and takes longer. This may require the customisation of a purchased software product or the bespoke development or enhancement of an in-house application. The POPIT dimensions may be affected to a greater degree than required by the basic option. The exhaustive option offers a comprehensive solution but takes the longest time and is the most expensive. This option may involve the purchase or bespoke development of a software product that offers extensive functionality and also meets a wide range of non-functional requirements. The impact on all of the POPIT dimensions is likely to be extensive. 8.4 Describe the purpose of design thinking Design thinking encourages the use of product design concepts and techniques such as prototyping, learning from trying out ideas, divergent and convergent thinking and, most importantly, keeping a customer focus in mind. The application of a design thinking approach helps to uncover innovative options that may not have been identified when using more transitional approaches. 8.4.1 Divergent and convergent thinking A key element of design thinking is concerned with enabling divergent and convergent thinking. Participants in the design thinking process are encouraged to think expansively about various aspects such as where problems exist, the issues that cause concerns, the range of perspectives and personas in play, and ideas for possible solutions. This is then followed by an evaluation session to eliminate, harmonise or summarise ideas into a manageable set. A key factor in successful divergent and convergent thinking concerns identifying the point at which sufficient suggestions have been generated and the focus should shift to reviewing the ideas that appear feasible and offer a potential way forward. This can be difficult to navigate successfully so requires a design thinking facilitator who possesses skill, knowledge and experience. The Design Council offers a Double Diamond model that represents the use of divergent and convergent thinking at two key points: when defining the challenge to be addressed and when developing the solution that will resolve the challenge and deliver the required outcome  BCS Exam Notes This model encapsulates the key principles of design thinking. The constant focus is on addressing the problem or opportunity to achieve a desired outcome. The needs and goals of customers are always kept in mind as this is a customer-centric approach. Participants work collaboratively and engage in both divergent and convergent thinking. Where possible, customers are involved in the design thinking process in order to support co-creation of products and value. The emphasis is on iterating to test, learn and improve.  BCS Exam Notes 9. Making the Business Case (5%) 9.1 Describe the lifecycle for a business case in business case development A business case is a key document in a business change project. It is where the analysts or consultants present their findings and Propose actions for senior management to consider. This chapter considers the purpose, structure and content of a business case and provides guidance on how to assemble the information and present the finished product. It is worth considering why a business case is produced.and asking, 'What is the point of a business case?' and 'What is it for?' A business case presents and evaluates one or more courses of action that will address a problem or enable the organisation to grasp a business opportunity. However, this does not necessarily mean that a course of action is recommended. Sometimes. a business case evaluates a poorly conceived idea and demonstrates that it will not work. 9.2 Identify the areas of feasibility assessment Business feasibility issues include whether the proposal matches the business objectives and strategy of the organisation and – if it is a commercial firm – if the option can be achieved in the current market conditions. There is the question of whether the proposed solution will be delivered in sufficient time to secure the desired business benefits. The solution must 'fit' with the management structure of the organisation and with its culture, as lack of cultural fit is often a cause of projects failing to deliver predicted benefits. The solution must also align with the EA for the organisation. The proposal may be for major process change so may have to align with other processes, including those that are not changing: alignment with the processes defined in the business architecture must also be considered. Whatever is proposed must be possible given the organisation's capabilities. Finally, many sectors are now heavily regulated and the proposed solution must be one that will be acceptable to the regulators and comply with relevant laws.  BCS Exam Notes Assessing technical feasibility involves considering whether or not the technology to deliver the solution is available. The proposed solution must meet the organisation's demands in terms of system performance, availability, reliability, maintainability and security. The solution should be scalable to meet changes to the organisation's circumstances. Few IT systems are completely detached from other systems and so the issue of compatibility must be considered. If the solution involves an off-the-shelf software product, thought should be given to the amount of customisation that would be required and whether this would cause technical difficulties. Finally, consideration is needed regarding whether the proposed solution has been proven or, alternatively, if it places excessive reliance on new technological developments. Many organisations would prefer a less ambitious but reliable solution to a more advanced one that comes with a lot of technological risk. Financial feasibility concerns whether the organisation can afford the proposed solution. The organisation needs either to have the required funds available or to be in a position to borrow them. There may already be a, budget imposed. Every organisation has rules or guidelines about what constitutes an acceptable return on its investment (ROI) and methods of calculating this are considered later in this chapter. Even if a project ultimately pays for itself, there may be points where it may have unacceptably high costs and so cash flow must also be considered. Finally, all organisations specify some time period over which payback must occur and in the case of IT projects, the payback periods are often very short, sometimes within the same accounting year as the investment 9.3 Define the structure and contents of a business case The structure and content of most business cases are similar and tend to include these elements: Introduction Management (or executive) summary Description of the current situation Options considered Option description Analysis of costs and benefits Impact assessment Risk assessment Recommendations Appendices, with supporting information  BCS Exam Notes 9.3.1 Categories of costs and benefits Cost-benefit analysis is a key aspect of a business case. Before examining this subject in detail, it is worth mentioning that it can be more persuasive to present the benefits before the costs. In other words, what is presented is actually a benefit-cost analysis even though by convention it is always referred to as a cost- benefit analysis. Costs and benefits are either incurred, or realised, immediately or in the longer term. They are also either tangible, which means that a credible value can be placed on them, or intangible, where this is not the case. Tangible costs may include the following: Project staff costs Business staff costs Equipment Infrastructure Packaged software Relocation Staff training and retraining Ongoing costs Intangible costs may include the following: Disruption and loss of productivity Recruitment Tangible benefits may include the following: Staff savings Reduced effort and improved speed of working Faster responses to customers Reduced accommodation costs Reduced inventory Other costs reductions Intangible benefits may include the following: Increased job satisfaction Improved customer satisfaction Improved management information Greater organisational flexibility More creative problem-solving time 9.3.2 Impact assessment Whatever the impacts from a particular option, they need to be stated in the business case. It must also explain the changes required to exploit fully the opportunities available, and the costs these changes will incur. Impacts include: Organisation structure: It may be necessary to reorganise departments or functions to exploit the new processes and systems. For example, to create a single point of contact for customers or to create more generalist rather than specialist staff roles. This is likely to be unsettling for both staff and managers and a plan must be made to handle this. Interdepartmental relations: The relationships between departments may change and there may be a need to introduce service level agreements or redefine these relationships in other ways Working practices: New processes and systems invariably lead to changes in working practices and these must be introduced carefully and sensitively. Management style: Sometimes, the style that managers adopt has to change. For example. if the organisation's management hierarchy is reduced and customer facing staff are empowered to make decisions, the management style is likely to change. Recruitment policy: The organisation may have to recruit people using a different recruitment approach. Appraisal and promotion criteria: It may be necessary to change the targets, objectives and incentives for staff in order to encourage them to display different behaviours, such as increasing their customer focus. Supplier relations: The ways of working with suppliers may have to be redefined. For example, implementing a collaborative customer/supplier relationship approach rather than one that is adversarial.  BCS Exam Notes 9.3.3 Risk assessment No change comes without risk and it is unrealistic to think otherwise. A business case is immeasurably strengthened if it can be shown that the potential risks have been identified and that suitable counter measures are available. A comprehensive risk log (sometimes called a risk register) is probably not required until the change project starts but the principal risks should be highlighted in the business case. For each risk, the following should be recorded: Description: The cause of the risk should be described and also its impact. For example, 'uncertainty over the future leads to the resignation of key staff, leaving the organisation with alack of experienced staff'. Impact assessment: This should attempt to assess the extent of the harm that would be suffered if the risk occurred. It is preferable for quantitative measures to be identified but, if this is not possible, a scale of 'small', 'moderate' or 'large' is sufficient. Probability: How likely it is that the risk will materialise. Precise probabilities may be calculated but it is sufficient to use a scale of 'low·, 'medium' or 'high', Countermeasures: The countermeasures are concerned with reducing the likelihood of the risk occurring or to lessen its impact if it does. It may also be possible to transfer the impact of the risk onto someone else, for example, through the use of insurance. Ownership: For each risk, it is necessary to decide who is best placed to take the necessary countermeasures. This may involve asking senior managers within the organisation to take the responsibility. 9.4 List the key features relevant to the production of a business case within an Agile context The key features relevant to the production of a business case when using an Agile approach are: Time horizons are shorter and results (positive or negative) appear sooner. Budgets are smaller and there is less up-front commitment to large expenditures. Risks are accordingly reduced, as the organisation is only proceeding in an incremental way- and they are reduced further by the extensive use of prototyping to try out ideas and make sure they work before implementing them on a large scale. Where ROI is concerned, there may be a partial return at an earlier point in time and the gains from earlier phases in a programme can assist in funding the later stages.  BCS Exam Notes 9.5 Identify the elements of a CARDI Log A business case documents the risks of a proposed project and it may also set out any constraints, assumptions or dependencies on which it has been based. Since all of these are likely to have ongoing effects throughout the project, this is a good point at which to set up logs that assist in managing them Constraints: The main constraints on any project are those of the 'iron triangle' - time, cost (or resources) and product/quality. But other constraints may need to be taken into account as well, such as the need to comply with certain legislation, to use certain standards or to make sure an IT solution runs on a specific platform. Assumptions: The business case, and thus the project, may rest on certain assumptions. For example, that government funding may be available for part of the project. These assumptions should be documented and actions identified to test whether they are valid. Risks: The risks documented in the business case form the start of the overall risk log for the project and are augmented as the work progresses. The log should document the risks themselves, their probability of occurrence and scale of impact, the actions proposed to avoid or mitigate them and who should own each risk. As well as new risks arising during the project, others are likely to change and can be retired if they do. not arise. Dependencies: Because modern organisations are so complex, an individual project often has dependencies on other projects, or may be depended upon by other projects. For example, a project to introduce a new IT system may depend on a project to recruit people with the required skills. Capturing details of these dependencies makes sure that they are kept in mind at all times. Issues: An issue is something that has occurred on a project that could have an effect on it (for good or ill) and therefore needs to be managed. Some issues are risks that have materialised. For example, if it is known at the outset that the project team is inexperienced, this is an issue rather than a risk because it has 100% probability of occurring. As with risks, the issues part of the CARDI or RAID log documents what each issue is, what should be done about it and whose responsibility this is. 9.6 Explain the purpose of the following investment appraisal techniques Business cases need to include calculations that use the quantified costs and benefits to identify the financial implications of each option. In this part of the business case, the tangible costs and benefits are contrasted so see if, and when, the project will pay for itself. 9.6.1 Payback The most straightforward technique concerns a 'payback' calculation, which is in effect a cash-flow forecast for the project. An investment appraisal technique where a cash-flow forecast for a project is produced using the current values of the incoming and outgoing cash-flows; no attempt is made to adjust them for the declining value of money over time. 9.6.2 Discounted cash flow and net present value An investment appraisal technique that takes account of the time value of money. The annual net cash flow for each year following the implementation of the change is reduced (discounted) in line with the estimated reduction in the value of money. The discounted cash flows are then added to produce an NPV, which is the amount an investment is worth once all of the net annual cash flows in the years following the current one are adjusted to today's value of money. The NPV is calculated using the discounted cash flow approach to investment appraisal. 9.6.3 Internal rate of return A calculation that assesses the ROI from a project, defined as a percentage rate. This percentage is the discount rate at which the NPV is equal to zero and can be used to compare projects to see which are the better investment opportunities. Alternatively, this rate may be used to compare all projects with the return that could be earned if the amount invested was left in the bank.  BCS Exam Notes 10. Establishing the Requirements (10%) 10.1 Explain the requirements engineering framework Requirements engineering is a framework of activities that are applied when defining requirements and encompasses a range of elicitation, analysis and modelling skills. Requirements provide the basis from which business and IT solutions are designed and developed so this is a key area of competence for business analysts. Requirements elicitation: This stage is concerned with drawing out requirements from the stakeholders, in particular those who perform the work of the organisation or are the intended users of the software product. Requirements analysis: This stage is concerned with reviewing and analysing the elicited requirements to remove duplication or error, negotiate conflicts and contradictions, evaluate feasibility and allocate priorities. Requirements documentation: This stage is concerned with producing narrative and diagrammatic definitions of the requirements, at varying levels of accuracy and completeness. Requirements validation: This stage is concerned with reviewing requirements in order to assure that they are defined at the required level of quality. Requirements management: This stage is concerned with managing changes to the defined requirements and ensuring the desired level of traceability is achieved. 10.2 Identify the following actors in requirements engineering An actor is an individual or group who is fulfilling a particular role. There are some key roles involved with RE work and they represent two broad stakeholder groups: the business representatives and the project team. 10.2.1 The business representatives Several actors represent the organisation or business area during a project. The roles that are conducted depend in part on the approach taken to the requirements work and the nature of the project. Key roles are the project sponsor, the product owner, the SME and business stakeholder roles, which may be at a tactical (managerial} or operational (staff} level.  The project sponsor (or accountable executive} represents the business in ensuring that business objectives are met.  The product owner role originated from Scrum but has attained wider acceptance across Agile software development and business change projects. The product owner is the custodian of the product or solution backlog, the repository of the requirements, and is empowered to make decisions regarding the product development on behalf of the organisation  BCS Exam Notes  The SME (sometimes known as the domain expert) should have experience and knowledge of industry best practice and bring a breadth of understanding to the RE work. The knowledge of the business domain offered by an SME helps the other roles to gain a greater depth of understanding of the requirements  Business staff are the individuals or groups who carry out the work of the business so will implement the new business processes and use the new or enhanced software product. They work within the operational business areas that are led by business managers (who may be requirement owners and also play a key role in defining requirements). They have knowledge and experience of how the organisation operates so are required to describe current processes, procedures and documentation, highlight any difficulties they experience with these processes and identify the requirements for new or improved solution features 10.2.2 The project team Project team roles also vary depending upon the context and approach adopted for the project. Key roles include the project manager, the business analyst; developers and software testers.  The project manager has overall responsibility for the project as defined in the PID or ToR. In particular, the project manager has to ensure that the project objectives are met and the deliverables are produced.  Business analysts are responsible for carrying out the REwork. They must ensure that the requirements are well-formed and defined, in line with the project approach and standards. and provide a basis for a solution that will help to achieve the business objectives and realise the business benefits. Working closely with business staff, they elicit, analyse and document the requirements, applying a range of elicitation, analysis and documentation techniques as appropriate to the project context.  The developer creates the software product in line with business requirements. During this process, developers confirm the technical feasibility of the requirements and help the analysts to appreciate the implications of some of the requests. Developers also assist in the creation of high-fidelity prototypes of the requirements. This helps business staff to visualise what they have requested. identify further requirements and confirm the analysts' understanding.  The software tester is responsible for trying to prove that the system does not work and to identify where this is the case. Testing cannot guarantee that a software product is completely errorfree; however, when the tester struggles to identify defects it may be declared that the software product is satisfactory. 10.3 Identify the types of requirement 10.4 Describe the hierarchy of requirements  BCS Exam Notes 10.5 Describe requirements elicitation techniques Visualisation: Rich pictures, mind maps and fish-bone diagrams are extremely useful ways of visualising situat