BCS Business Analysis Pre-Course Reading.pdf
-
Upload
murali-ramakrishnan -
Category
Documents
-
view
149 -
download
3
description
Transcript of BCS Business Analysis Pre-Course Reading.pdf
-
BAFOUND-PCR_V2.4
Business Analysis Foundation Pre Course reading
-
Business Analysis Foundation BAFOUND-PCR_v2.4
Page 1
Business Analysis Pre-Course Reading
1. Business Analysis covers a very broad range of subject areas and skills. The Foundation Certificate in Business Analysis expects us to understand this broad range and will test our understanding of a wide range of subject areas.
2. The syllabus (v3.3) is arranged as follows and the course you are about to
undertake will have a similar emphasis:
What is Business Analysis (2.5%) The competencies of a Business Analyst (2.5%) Strategy Analysis (7.5%) The Business Analysis Process Model (5%) Investigation Techniques (15%) Stakeholder Analysis and Management (5%)
Modelling Business Systems (10%) Modelling Business Processes (10%) Gathering the Requirements (7.5%) Documenting and Managing Requirements (5%) Modelling Requirements (10%) Delivering the Requirements (5%) Making a Business & Financial Case (10%) Implementing Business Change (5%)
3. Although there are no formal pre-requisites to entry into the course, delegates who have either an IT background, perhaps in systems design & development, or have a basic understanding of the process management environment will be at significant advantage.
4. Most courses will have a mix of experienced and less-experienced managers, and similarly IT staff with more or less experience of the Business Analysis environment. This provides a forum for lively debate and learning.
5. To assist understanding, BEFORE the course commences QA expects all delegates to have read the pre-course reading document which is an extract from the BCS textbook Business Analysis Second Edition edited by Debra Paul, Donald Yeates and James Cadle. The book will be given to you on day 1 of the course.
-
Business Analysis Foundation BAFOUND-PCR_v2.4
Page 2
THE FOUNDATION EXAMINATION
40 Multiple choice format questions. This is a one hour, "closed-book" examination where you need to score 26 marks or more to pass. The
Foundation examination will be on the afternoon of Day 3 and your paper will be independently invigilated and marked by BCS.
BCS ACCREDITED TRAINING PROVIDER
QA as an Accredited Training Provider is responsible for design and creation of
the Business Analysis courseware and the delivery of the training, and although
QA administer the examinations, all questions will have been approved by BCS.
PLEASE REMEMBER TO BRING YOUR PRECOURSE MATERIALS WITH YOU
WE LOOK FORWARD TO WELCOMING YOU ON YOUR BUSINESS ANALYSIS
COURSE
-
1 What is Business Analysis?
pcr_01_introduction to business analysis.docx Page 3
1.1 What are the origins of Business Analysis?
Technology developments have enabled organisations to implement new business
models and focus on their core processes and competencies. However for many years
there has been a growing dissatisfaction in business with the support provided by IT
and recognition by senior management that IT investment often fails to deliver the
required business benefit. Business Analysis is a relatively new discipline that promises
to overcome these problems by ensuring that business needs are aligned with
implemented business change solutions.
1.2 The development of Business Analysis
Drivers include:
Outsourcing
In an effort to reduce costs, and sometimes due to a lack of IT expertise, many
organisations have outsourced their IT operations. The advantages of reduced cost
often are replaced by problems once the arrangement has been in place for a while.
Issues relating to supplier management and requirements communication occur. This
has been a catalyst for the development of the business analysis function as
organisations recognise the importance of business representation in the development
and implementation of IT systems
Competitive advantage of using IT
Organisations have discovered that for IT systems to deliver competitive advantage:
The needs of the business must drive the development of IT systems
The implementation of IT systems must be accompanied by the necessary
business changes
The IT requirements must be rigorously and accurately defined.
The first two areas required the development of the business analysis role.
Successful business change
Increasingly organisations have broadened their view from IT projects to business
change programmes. In addition the business change lifecycle was developed, and the
roles of programme manager and business change manager have been defined. The
business analyst has a role to play in the definition of requirements, change design and
development, business acceptance testing and, after implementation, benefits review
and realisation.
-
1 What is Business Analysis?
pcr_01_introduction to business analysis.docx Page 4
Importance of the business analyst role
The business analyst can help identify solutions to business issues and opportunities
which are not always provided by IT. Ensuring that predicted business benefits are
achieved is increasingly important in a global economic environment where budgets are
limited and organisations cannot afford to waste financial resources.
Use of consultants
Many organisations use consultants because:
They can be employed to deal with a specific issue on an as-needed basis
They bring a broader business perspective
They can provide an objective view of the company
However the use of consultants is often criticised because of the:
Lack of accountability
Absence of any transfer of skills
Cost
-
1 What is Business Analysis?
pcr_01_introduction to business analysis.docx Page 5
Business analysts argue that they can provide the same services as external
consultants and can operate as internal consultants with the following advantages:
Lower costs
Speed , as they are knowledgeable about the business domain
Retention of knowledge within the organisation
They will have to live with the impact of the actions they recommend.
1.3 The Scope of Business Analysis Work
Some business analysts may be required to undertake strategic analysis and identify
business transformation actions, but most will have a role to play in supporting this
activity.
IT systems analysts are responsible for analysing and specifying the IT system
requirements in sufficient detail for a system to be built or a software package
purchased. However the business analyst is responsible for considering a range of
business options to address a particular problem of opportunity. The options may, or
may, not include IT. In some organisations, where there are no systems analyst roles,
the business analyst works closely with the IT developers and so may include the
specification of the IT requirements as part of their role.
The core business analysis role is:
To investigate a business system where improvements are required
To recommend actions that would overcome a problem or achieve business
benefits
To make recommendations for business changes supported by a rigorous
business case.
-
1 What is Business Analysis?
pcr_01_introduction to business analysis.docx Page 6
1.4 Taking a holistic approach
When identifying areas for improving a business system, the business analyst must
consider all aspects of the operational business system. This is known as taking a
holistic approach, which is essential for the business to obtain business benefits.
A useful mnemonic to remember the four views of a business system is POPT.
The business analyst may be required to support the implementation of the business
change. The holistic view offers an effective structure for identifying the range of areas
to be considered when planning the implementation.
1.5 The role and responsibilities of a business analyst.
The core business analyst role definition:
An internal consultancy role that has the responsibility for investigating
business situations, identifying and evaluating options for improving
business systems, defining requirements and ensuring the effective use of
information systems in meeting the needs of the business.
In addition business analysts in a more senior or specialist role may be involved with:
Strategy implementation
Business case production
Benefits realisation
Specification of IT requirements.
-
1 What is Business Analysis?
pcr_01_introduction to business analysis.docx Page 7
Extract from
Debra Paul, Donald Yeates and James Cadle (2010), Business Analysis (2nd Edition),
BCS.
-
2 The competencies of a Business Analyst
2 The competencies of a Business Analyst v1 Page 8
2.1 What are the competencies that we need to develop?
Here we will define a competency as something a business analyst needs in order to
perform his or her job effectively. The competencies are grouped: Behavioural skills and
personal qualities, Business knowledge and Techniques. A useful mnemonic to
remember these groupings is BBT.
Behavioural skills and personal qualities:
Communication
Relationship building
Influencing
Team working
Political awareness here we are thinking about internal politics, the ability to
work out what is and is not politically acceptable in an organisation.
Analytical skills and critical thinking
Attention to detail
Problem solving
Leadership developing a vision, taking ownership of that vision and ensuring
actions to achieve that vision are implemented, are leadership characteristics
that apply to all types of work, including business analysis
Self-belief
Business knowledge
Finance and the economy
Business case development*
Domain knowledge the sector in which your organisation operates .e.g. private,
public, not-for-profit
Subject matter expertise
Principles of IT
Organisation Structure and design
Supplier management different contractual arrangements which are available:
o Time and materials
o Fixed price delivery
o Risk and reward
Techniques
Project management
Strategy analysis*
Stakeholder analysis and management*
-
2 The competencies of a Business Analyst
2 The competencies of a Business Analyst v1 Page 9
Investigation techniques*
Requirements engineering*
Business system modelling*
Business process modelling*
Data modelling*
Managing business change*
Facilitation techniques
Competencies marked above with * are covered in the course.
2.2 How can I develop my competencies?
A first step is to understand the competencies required of a business analyst in your
organisation, considering current and future requirements, then compare them to your
own skills set. There are three ways in which business analysts can develop their
competencies: training, self study and work experience.
Your organisation may use a framework such as the Skills Framework for the
Information Age (SFIA) pronounced sofia the British Computer Societys model.
SFIA and SFIA plus include six categories of skill including business change. Different
levels of skill are defined for each category and are numbered:
1 follow
2 assist
3 apply
4 enable
5 ensure, advise
6 initiate, influence
SFIAplus provides more detail than SFIA and should be treated as a standard, whereas
SFIA may be tailored to an organisations needs. SFIAplus enables organisations to
classify and benchmark their IT skills and to train and develop their teams to meet the
defined skill requirements.
The BCS International Diploma in Business Analysis is a professional qualification in
Business Analysis. The Foundation Certificate in Business Analysis which you are
taking is one of the four certificates you will need to pass, and take an oral exam, to
complete the Diploma.
Extract from
Debra Paul, Donald Yeates and James Cadle (2010), Business Analysis (2nd Edition),
BCS.
-
3 Strategy Analysis
3 Strategy Analysis v1 Page 10
3.1 What is strategy?
A popular definition is given by Johnson, Scholes and Whittington (2008):
Strategy is the direction and scope of an organisation over the long term,
which achieves advantage for the organisation through its configuration of
resources within a changing environment and to fulfil stakeholder
expectations.
3.2 How is strategy developed?
We can identify several starting points:
Strategy associated with an individual e.g. Ken Morrison of Morrison
supermarkets, the founder of a business or a newly introduced manager e.g.
Stuart Rose at Marks & Spencer
Decentralised and empowered organisations where all managers are
encouraged to use the techniques of strategy analysis and be intrapreneurial or
internally entrepreneurial. Groups of manager may meet to determine strategy by
reviewing the market and their own business progress.
Strategies resulting from a formal planning process. This is essential for some
organisations; especially those for which strategy is truly long term e.g. Railtrack.
The three different ways in which strategies come about are described by Johnson,
Scholes and Whittington (2008) as seeing strategy development through three different
lenses. These lenses are:
The design lens of formal planning sees strategy resulting from detailed and
comprehensive analysis by top management, which is pushed down through the
organisation.
The experience lens (intrapreneurial) where the collective experience of the
organisation and its culture operate on existing strategy to give it a new form.
The ideas lens for entrepreneurial strategies which are the result of an
innovative climate or the introduction of new thinkers.
We also have to recognise another force in the making of strategy: politics. Rather than
strategy developed in a rational way, it is developed through the promotion of specific
ideas of the most powerful groups. This power comes from:
Dependency departments are dependent on those departments that have
control over the organisations resources e.g.HR.
Financial resources who controls the funds needed to invest in new ideas,
products or services.
Position where the individuals live in the organisational structure.
-
3 Strategy Analysis
3 Strategy Analysis v1 Page 11
Uniqueness no other part of the organisation can do what the powerful group
does.
Uncertainty groups can cope with the unpredictable effects of the
environment.
Finally there is the garbage can model for strategy formulation, which is said to be
most appropriate where there is collective uncertainty about what to do. The garbage
can stores ideas, processes and solutions that were rejected as solutions to earlier
problems. When there is a need to do something a choice opportunity we look in the
garbage can and find a collection of ideas and solutions that we can use now.
Whichever approach to strategy development we take, it is important to provide a
written statement of our strategy because:
It provides a focus for the organisation at all levels
It provides a framework for the allocation of investment and other resources
It provides a guide to innovation
It enables appropriate performance measure to be put in place
It tells the outside world, our stakeholders, about us.
3.3 External Environment Analysis
Most organisations face a complex and changing external environment of increasing
unpredictability. It is essential that we monitor this environment and its effect on our
strategy. PESTLE analysis provides a framework to examine the external environment.
This is an examination of the political, economic, sociocultural, technological, legal and
environmental issues in the external business environment.
Having examined the external environment, we should now consider the competition
our organisation faces .Michael Porters five forces model (Porter 1980) is an analysis
tool that helps to evaluate an industrys profitability and hence its attractiveness.
-
3 Strategy Analysis
3 Strategy Analysis v1 Page 12
In the centre is the competitive battleground, where rivals compete and competitive
strategies are developed. Organisations seek to understand the nature of the
competitive environment, and the interplay of the five forces, in order to develop
strategies against the threat they pose.
There are some weaknesses to Porters framework. Most often mentioned is that
government is not treated as a sixth force. Porters response is that the role of
government is played out though each of the five forces legislation affects rivalry and
new entrants - and so has not been ignored. It is also difficult to apply this model to not-
for-profit organisations.
Having worked on our PESTLE and Porter analyses we have gathered useful data on
the attractiveness of our business and the external conditions it may face. As there will
be a degree of uncertainty in trying to understand possible future impacts Scenarios
may be used to look at medium and long-term future, and evaluate possible different
futures. Scenarios begin by identifying potential high-impact and high-uncertainty
factors in the environment and evaluating their impact, our worst case scenario. Ideally
four or more possible scenarios should be considered.
The external environment creates opportunities and threats and can give an outside-in
stimulus to the development of strategy.
3.4 Internal Environment Analysis
Every organisation needs to ask whether it has the capability to change to fit the
environment in which it operates. To understand the organisations capabilities we will
-
3 Strategy Analysis
3 Strategy Analysis v1 Page 13
look at two internal analyses: the Resource Audit and portfolio analysis using the
Boston Matrix. But first we must understand the current business positioning and to do
this we use the MOST analysis to examine the current mission, objectives, strategy and
tactics, and consider whether they are clearly defined and supported within the
organisation. We can define the MOST terms as follows:
Mission describes what business the organisation is in, and what it is intending
to achieve
Objectives - the goals against which the organisations achievements can be
measured
Strategy the approach that is going to taken to achieve the mission and
objectives
Tactics the detailed means by which the strategy will be implemented.
Reflecting on core competences starts the strategy process from inside the
organisation, and so is an inside-out approach based on the belief that
competitiveness comes from the ability to create new products and services from a set
of core competences. The resource audit can help identify strengths and weaknesses
of these competences by examining the tangible resources:
The physical resources e.g. buildings, plant, equipment, land
The financial resources that determine the organisations financial stability
The human resources
And the intangible resources:
The know-how of the organisation
The reputation of the organisation
Many businesses have a diversified range of products and services. Portfolio analysis
of a business helps organisations to achieve balance with a mixture of high-growth,
profit-maximising, investment-needing and declining products and services. The
strategic business units (SBUs) parts of an organisation for which there is a distinct
and separate external market are identified and the relationship between each SBUs
current or future revenue potential is modelled against the appropriate management of it
using the Boston Box.
-
3 Strategy Analysis
3 Strategy Analysis v1 Page 14
A successful product or service starts as a wild cat and goes clockwise round the model
until it dies or is revitalised as a new product, service or SBU.
3.5 SWOT Analysis
SWOT (Strengths, Weaknesses, Opportunities and Threats) analysis is often used to
pull together the results of an analysis of the external and internal environments.
3.6 Implementing Strategy Implementing new strategies implies risk because it involves change. We need to consider the context for the strategy, the role of the strategic leader and tools to assist strategy implementation, the Balanced Business Scorecard (BBS) and the McKinsey 7-S Model. First the context:
Time how quickly does the new strategy need to be implemented? Scope how big is the change? Is it incremental or transformational?
-
3 Strategy Analysis
3 Strategy Analysis v1 Page 15
Capability is the organisation used to change? Readiness is the whole organisation, or part affected, ready for the change? Strategic leader is there a strategic leader?
The strategic leader has a key role in enabling the successful implementation of strategic change. The key characteristics seem to be that the strategic leader does the following:
Challenges the status quo
Establishes and communicates a clear vision of the direction to be taken
Models the way Empowers people to deliver their parts of the strategic change
Celebrates success The McKinsey 7-S model
This model supposes that all organizations are made up of seven components. Three are often describes as hard components strategy, structure and systems and four as soft- shared values, style, staff and skills. If there is a change in one component, others will be affected. All seven levers therefore need attention if the implementation is to be successful. The Balanced Business Scorecard (BBS) This can be thought of as the strategic balance sheet for an organization since it captures both the financial and non-financial components of a strategy. When
-
3 Strategy Analysis
3 Strategy Analysis v1 Page 16
implementing strategy it is essential to identify critical success factors in both financial and non-financial components and use associated key performance indicators to monitor progress in each area towards achieving the strategy and vision.
The acronym CLIF will help you remember the four components of the BBS. The BBS was developed by Kaplan and Norton (1996). Extract from
Debra Paul, Donald Yeates and James Cadle (2010), Business Analysis (2nd Edition),
BCS.
-
4 The Business Analysis Process Model
4 The Business Analysis Process Model v1 Page 17
The Business Analysis Process model is a framework within which both standard
modelling techniques and organisational templates can be used. The framework
enables the Business Analyst to determine the most appropriate tools and techniques
for each situation, and incorporates the best practice principles of requirements
engineering.
4.1 An approach to problem-solving
Isaksen and Treffingers (1985) creative problem-solving model provides a useful
framework for understanding business problems and developing creative solutions. The
model emphasise the need to investigate and analyse rather than leap to quick,
possibly premature, solutions.
When applied to business analysis the model may be used as follows:
Mess finding understand the complexity of the problem situation, document
with a rich picture or mind map
Data finding analyse opinions, concerns, knowledge and ideas identify where
supporting data will help quantify this information
Problem finding using the work of the two previous stages uncover the heart
of the problem
Acceptance
Finding
-
4 The Business Analysis Process Model
4 The Business Analysis Process Model v1 Page 18
The first three stages are concerned with understanding the problem, the next two
stages focus on developing solutions:
Idea finding use creative problem solving techniques to generate a wide range
of ideas e.g. brainstorming, assumption reversal, random words or pictures.
Solution finding evaluate the ideas that could provide solutions to the
problem(s)
The final stage is Acceptance finding, which is concerned with managing the
implementation of the solution.
Did you spot the picture of the dog and the mnemonic to help you remember the
stages of this model? My Dog Pants If Shes Active.
4.2 The Business Analysis Process Model
This model sets out the key stages for a business analysis project, with each stage
representing the areas that need to be considered. Some projects may require a
detailed exploration of all the stages, other projects may focus on a subset of the
model, possibly just one stage. The course will consider each of the stages,
identifying the inputs to each stage, the techniques used in the stage and the
outputs from the stage. Briefly the stages are:
Investigate situation- uncover issues and problems in the business
Consider perspectives analyse stakeholders and consider their
perspective of the situation, their view of what the business should be doing.
Analyse needs identify where improvements can be made to the business
system by doing a gap analysis
Evaluate options examine the potential improvements identified so far
developing some business options, evaluate them for acceptability and
feasibility and produce a Business Case
-
4 The Business Analysis Process Model
4 The Business Analysis Process Model v1 Page 19
Define requirements - gather and document the detailed requirements for
changes to the business system recommended and signed off from the
Business Case.
4.3 Delivering changes
Once the business analysts have analysed the situation, developed options for
improvement and defined the requirements to be delivered, it is important to
consider how the requirements will be delivered, the changes implemented and the
business benefits realised. The business analyst will support others in the project
team to deliver the changes.
Extract from
Debra Paul, Donald Yeates and James Cadle (2010), Business Analysis (2nd Edition),
BCS.
-
5 Investigation Techniques
5 Investigation techniques v1 Page 20
If analysts are working with an unfamiliar client organisation (or division or department)
they should spend time gathering background information prior to beginning the
investigation stage of the Business Analysis Process model, by studying:
company reports
the company website
procedure manuals and documentation
the organisation chart of the target area of the company
5.1 Investigation Techniques
The techniques can be categorised broadly as qualitative understanding what is
needed and quantitative- concerned with volumes and frequencies.
The qualitative approaches are:
Interviews usually a one-toone meeting
Observation
o Formal observation watching a specific task being performed
o Protocol analysis business staff perform a task and describe each step
as they perform it
o Shadowing following a business user for one or two days to find out
what a job entails
o Ethnographic study the analyst spends an extended period, possibly
several months, in the target environment
Workshops a structured meeting, ideally lead by an independent facilitator.
Scenarios the business user tells the story of a transaction from trigger to
outcome, capture the happy-day scenario first
Prototyping - creating a demonstration system to help clarify vague
requirements, may be mock-ups on paper using flipchart sheets, pens and packs
of Post-it notes.
We will consider the advantages and disadvantages of each technique during the
course. A variety of discovery and documentation techniques may be used in a
workshop. Discovery techniques include:
Round robin
Brainstorming
Brainwriting
Post-it exercise
Stepwise refinement
-
5 Investigation Techniques
5 Investigation techniques v1 Page 21
Documentation could be by:
Process models
Rich pictures
Mind maps
Context diagrams
Use case diagrams
Task scenarios
Focus groups are a type of workshop which tends to be concerned with business and
market research.
The quantitative approaches are:
Questionnaires useful for a limited amount of information from a large
audience, particularly if they are geographically dispersed.
Special purpose records business users make a record about a specific issue
or task, could be as simple as a five bar gate tally.
Activity sampling a quantitative form of observation, where the amount of
time taken on a range of activities is recorded by the business analyst
Document analysis reviewing completed forms, screen layouts and reports to
uncover detailed information about an organisation, process or system.
5.2 Documenting the current business situation
While carrying out the investigation the analyst will need to record the findings to
understand the range of issues and business needs. Meeting reports will be produced
for each interview and workshop. In addition there are diagrammatical techniques that
are also useful in documenting the investigation and analysing the situation:
Rich pictures a free format representation of the entire business situation
Mind maps a tool for summarising a lot of information visually, showing
connections between ideas and topics
Business process models to understand how a process is carried out a
swim-lane diagram or an activity diagram may be drawn
Spaghetti maps show the movements and interactions of stakeholders when
performing particular tasks and processes
Fishbone diagrams also known as Ishikawa diagrams. The technique is
known as root cause analysis.
-
5 Investigation Techniques
5 Investigation techniques v1 Page 22
A business needs log can be produced once the key causes of the problems have
been identified and we can begin to consider how the problem may be addressed which
may lead to some high level business requirements.
Extract from
Debra Paul, Donald Yeates and James Cadle (2010), Business Analysis (2nd Edition),
BCS
-
6 Stakeholder Analysis and management
6 Stakeholder Analysis and Management v1 Page 23
Effective stakeholder management is essential for the success of a business analysis
project. The main responsibility for stakeholder management rests with the project
manager, but all project team members have a role to play in identifying stakeholders,
helping to understand their needs, managing their expectations and monitoring any
changes during the project lifecycle.
When does stakeholder management take place? Throughout the project lifecycle.
6.1 Stakeholder categories and identification
A stakeholder is anyone who has an interest in, or may be affected by, the issue under
consideration. Generic stakeholder categories that apply to many projects are:
Partners
Suppliers
Regulators
Employees
Managers
Owners
Competitors
Customers
To ensure that the identification of the stakeholders is as complete as possible a
workshop may be held with people who are knowledgeable about the organisation and
the proposed project.
6.2 Analysing Stakeholders and stakeholder management strategies
The next step is to analyse the attitudes towards the project, assess their interest in the
project and the amount of power or influence they have, which will determine their ability
to support of obstruct it. The stakeholder analysis may be plotted on a grid and then
management strategies can be applied:
-
6 Stakeholder Analysis and management
6 Stakeholder Analysis and Management v1 Page 24
No interest and no power/influence ignore as regards day-to-day project
issues
Some or high interest but no power/influence keep these stakeholders
informed during the project and of the reasons for the proposed change
No, some or high interest and some power/influence keep onside by frequent
positive communication
No interest but high power/influence Watch these stakeholders, they may be
senior managers who have no direct interest in the project, but their attitude and
interest may change during the project
Some interest and high power/influence Keep them satisfied, their interest
may be indirect but they have real power
High interest and high power influence these are key stakeholders, they must
be kept informed at all stages of the project. They require constant active
management.
6.3 Managing stakeholders
Stakeholders positions on the grid may not stay in the same place during the life of the
project, their power or interest may change, and our management of them must change
-
6 Stakeholder Analysis and management
6 Stakeholder Analysis and Management v1 Page 25
accordingly. Therefore stakeholder analysis must be a continuing activity throughout the
project, and even afterwards to find out what the stakeholders thought of the final
outcome. Once stakeholders initial positions have been plotted, a plan should be drawn
up for what to do with each of them. Plotting stakeholders attitudes may be helpful. We
may classify attitude as:
Champion: actively works for the success of the project
Supporter : in favour of the project, but not very active in promoting it
Neutral : neither for or against the project
Critic : not in favour of the project but not actively opposed to it
Opponent : works actively to disrupt, impede or derail the project
Blocker : obstructs progress, maybe for reasons outside the project itself
The plan could be recorded on a spreadsheet:
Extract from
Debra Paul, Donald Yeates and James Cadle (2010), Business Analysis (2nd Edition),
BCS.
-
7 Modelling Business Systems
7 Modelling Business Systems v1 Page 26
Once we have identified and analysed the different stakeholders, we can begin to think
about their views with regard to the business system under investigation. Before going
on to model the business processes, we need to be clear about the values and beliefs
of stakeholders. We can use this understanding to develop models of desired future
business systems, which we can then assess against current real-world situations.
7.1 Soft Systems Methodology (SSM)
This methodology was developed by Peter Checkland (1981) to deal with business
systems, which he described as human activity systems. This soft systems model is
proposed as an alternative to the hard systems thinking approach, which assumes the
goals and objectives of business systems are clear. Checkland and others recognised
that business situations are rarely clear-cut, are often messier and that the softer
human aspects i.e. stakeholders thoughts and concerns, must be taken into account for
successful business change.
SSM begins with an investigation into a real world situation of concern and Checkland
proposed we use rich picture to document it. The different world view of each
stakeholders is then developed using a CATWOE and formalised as a sentence, known
by Checkland as a root definition, but we prefer the term business perspective. From
each business perspective a model of the stakeholders desired business system is
produced, then the differences between these conceptual models are considered and
the models are brought together in one consensus model, which represents the desired
future system.
-
7 Modelling Business Systems
7 Modelling Business Systems v1 Page 27
This model is then compared to real world models, including the rich picture we
produced earlier. By carrying out a gap analysis we can identify feasible, desirable
changes that need to be made to the existing business system. This leads us to taking
action to improve the problem situation, and could involve changes to the People,
Organisation, Processes and Technology.
7.1 Business Perspectives
The key stakeholders are asked how they view, from their own perspective, the purpose
and objectives of the part of the organisation that is within the scope of the change
project. SSM offers a useful framework for defining and analysing business
perspectives, given by the mnemonic CATWOE. The elements of CATWOE are:
C= customer: the beneficiary of the transformation
A= actor: those responsible for carrying out the business activities within the
scope of the view being considered
T= transformation: the activity at the heart of the system, that transforms input
to output
W= Weltanschauung or world view: an encapsulation of the stakeholders
beliefs about the organisation or business system
O= owner: the person, or group of people, who have the authority to change or
even stop the business activities being performed
Environment: the conditions and rules under which the business system
operates which are outside the control of the owner e.g. the PESTLE factors
When using CATWOE it is important to begin by understanding the Weltanshauung or
world view, since this encapsulates the beliefs that underpin the rest of the CATWOE.
After this define the transformation, and the customer, and then consider the actors,
owner and environment. Checklands root definition is developed as a sentence that
ties the CATWOE elements together.
7.2 Business Activity Models (BAM)
A BAM is a conceptual model that shows the business activities we would expect to
see in place given the business perspective from which it has been developed. Ignoring
what is currently happening in the business system; we use the BAM or root definition to
reveal the activities that comprise the system envisaged by the stakeholder. The
principles are:
Draw one BAM for each business perspective
Bring all the BAMs together in one consensus BAM
The BAM helps with analysing the business situation and identifying
improvements
-
7 Modelling Business Systems
7 Modelling Business Systems v1 Page 28
The model is concerned only with WHAT the activities are not WHO carries them
out or WHERE they are carried out.
Business systems are described using five types of business activity and the
dependencies between them. The types of activity, and the order they should be drawn,
on are:
Doing activities relate directly to achieving the transformation described in the
business perspective, and may be called primary task activities
Enabling activities - ensure resources and facilities needed by the doing
activities are obtained and deployed
Planning activities define the rules regarding the resource required, and
performance of these resources is to be measured
Monitoring activities collect metrics to check the performance of activities
against targets set as part of the planning activities
Control activities act on other activities when monitor activities have identified
the need for some action, usually when targets have not been met
Activities are drawn as ellipses and the logical dependencies between the activities are
shown by an arrow. See the Library Business Activity model below:
-
7 Modelling Business Systems
7 Modelling Business Systems v1 Page 29
7.3 Producing a consensus model
The BAMS produced up to this point have each been derived from an individual
perspective from a key stakeholder. By merging these models, to take account of all the
stakeholder perspectives, we can produce a consensus model. This will involve
negotiation with stakeholders to resolve conflicting views, and may take place in a
facilitated workshop. The kinds of consensus are:
Global consensus which assumes a neutral model exists for organisations of
a particular type
One hundred percent consensus stakeholders readily agree that an activity
is needed
Consensus through accommodation stakeholders with conflicting views
agree to compromise. The creation of additional activities and/or modification of
existing activities may be necessary to achieve this consensus.
7.4 Business events and business rules
Once the consensus model has been created add business events and rules. Business
events happen in the real world and they trigger the business system to do something.
We must document the events and relate them to the activities they trigger, either by
adding to the BAM or is associated documentation. There are three types of business
event to consider:
External: events which originate from outside the system boundary
Internal decision points: decisions made by business managers
Scheduled points in time: events that occur regularly
For the activities identified in the BAM there will be rules governing their performance.
Business rules are of two main types:
Constraints: restrict how an activity is performed. They may include laws,
regulations and business policies which cannot be challenged
Operational guidance: procedural rules that dictate how activities should be
performed, which can be changed
These business rules would emerge in discussion of the activities with the stakeholders
and should be documented to support the BAM.
-
7 Modelling Business Systems
7 Modelling Business Systems v1 Page 30
7.5 Critical Success Factors (CSF) and Key Performance Indicators (KPI)
The CSFs are things the organisation must be good at in order to succeed e.g. excellent
customer service. They provide insights into the planning, enabling and doing activities
on the BAM.
The KPIs are the things an organisation measures to find out how well it is doing
e.g.Customer satisfaction rating of 85% or higher each month.These may be identified
by considering the planning activities. Checking up on the KPIs should be reflected in
the BAMs monitoring and control activities.
7.6 Validating a Business Activity Model
To ensure that the BAM is complete and internally consistent Checkland provided the
following checklist:
Objectives and purpose (of the system): must be explicit
Connectivity: the activities must all be connected
Measures of performance: must exist and expected levels must be set
Monitoring and control mechanisms: control activities must have the power to
change other activities when performance levels are not met
Decision-making procedures: must exist and be influenced by control activities
Boundary: the extent of the system must be clear, and communications across
the boundary defined explicitly
Resources: staff, materials and other resources used by the system must be
acquired, allocated, replenished and accounted for
System hierarchy: a business activity should be in the scope of only one control
activity
7.7 Use of the Business Activity Model in gap analysis
The BAM represents a theoretical (conceptual) model of the activities we would expect
to see in place in our future business system. We compare this model to the current
reality in the organisation by doing a gap analysis to identify:
Some activities are in place and are quite satisfactory
Some activities are in place and are not satisfactory
Some activities are not in place at all
This enables us to identify activities that can continue, activities that need improving and
new activities that will need implementing.
-
7 Modelling Business Systems
7 Modelling Business Systems v1 Page 31
Extract from
Debra Paul, Donald Yeates and James Cadle (2010), Business Analysis (2nd Edition),
BCS.
-
8 Modelling Business Processes
8 Modelling Business Processes v1 Page 32
The business processes are the means by which an organisation carries out its internal
operations and delivers products and services to it customers. We will look at
techniques for modelling business processes, covering both the organisational view of
process modelling and the more details business process models.
8.1 Organisational context
The traditional view of a business is based on the specialist functional areas such as
sales, accounts and operations.
The functional view is useful for internal management and staff to see how the
organisation is structured and where they fit in, but this view in internally oriented which
is of no interest to the organisations customers. This view is also static, since it does
not show what the business does over time to respond to an event such as a customer
request for a product or service. This is in contrast to the process view which
emphasises the need for cooperation between all the participants to achieve the desired
level of customer service.
8.2 Alternative view of an organisation.
Paul Harmon (2007) offers an alternative view. His organisation model represents both
the internal processes and the external world, it is developed in two stages: first the
external forces that influence the organisation are considered and then the internal
business process is analysed.
-
8 Modelling Business Processes
8 Modelling Business Processes v1 Page 33
8.3 The organisational view of business processes
Once we have understood the circumstances in which the business operates, we can
focus on what the business does when reacting to the external environment. What are
the internal business processes? Starting with a high-level view of processes that
operate across the business we need to show the end-to end set of processes that
convert the inputs from suppliers to the outputs for the customers. This high-level view
may be shown:
To build a business process model we take this high-level view and break the process
down into a series of related processes which can be shown on an outline process map:
Business process models show a more detailed view of the processes than on a
process map.
-
8 Modelling Business Processes
8 Modelling Business Processes v1 Page 34
An alternate approach to building a process map is to look at the products and services,
and consider what processes are required to deliver them. Michael Porters value chain
provides a means of analysing the activities performed by an organisation. It identifies
the primary and support activities that will be required to deliver value to the
organisations customer and potentially differentiate the organisation from its
competitors.
8.4 Value propositions
A value proposition is a definition of an organisations product or service that will
demonstrate to customers that we understand and can satisfy their needs. Kaplan and
Norton have identified the main attributes that make up a successful proposition. The
product attributes are:
Functionality what the product does
Price
Quality how well the product performs
Choice do we provide a standard product or service, or can it be tailored to
meet the customers needs.
Availability or timing how quickly can we respond to customer requests
8.5 Business process models
A business process is triggered by a business event and includes five components: the
tasks that make up the process, the process flow, the decision points, the actors that
carry out the tasks and the outcome of the business process. There are no universally
agreed set of terms in business process modeling. The following conventions are
adopted here:
-
8 Modelling Business Processes
8 Modelling Business Processes v1 Page 35
Process refers to a set of activities starting with a triggering event and ending
with some output being delivered
Task refers to an activity within the process carried out by an actor
Step refers to the activities carried out within a task
There are many standards for modelling business. Two of the most popular are the
UML activity diagram technique (example below) and the Business Process Modelling
Notation (BMPN).
To build a business process model first identify who takes part in the process, this
enables us to identify the actors or roles. An actor may be an individual, a group, an
organisation or an IT system. Each actor is shown in a separate partition or swimlane
and arrows are used to show the flow of work between the tasks and the swimlanes.
The flow of work from one actor to another is known as a handoff. The customer
swimlane is normally placed at the top and the action on the model goes from left to
right on a horizontal layout, following the time axis, and from top to bottom as different
actors are involved in the process. Tasks should be labelled in a verb-noun format and
where possible use specific verbs, avoiding words such as manage or handle.
8.6 Analysing the business process model
Analysing the business process model helps us to identify problems with the existing
process before producing a replacement process. Handoffs are a frequent source of
problems in a business process because they can cause delays, errors and bottlenecks
to occur.
act Le Grand Pied
Billing D
epartm
ent
Chie
f Cle
rk Create project
Assign resources
Post
assignments
to treaders
Receive actuals
from treaders
Update diary
Send actuals to
bil l ing
Receive actuals
from chief clerk
Calculate total
charge
Raise inv oice Despatch invoice
to client
Receive payment
from client
Record
payment
FlowFinal
Receive payment
from bill ing
Close project
Receive
client call
Notify chief clerk
payment received
ActivityFinal
[complete]
[incomplete allocation]
-
8 Modelling Business Processes
8 Modelling Business Processes v1 Page 36
Look for piecemeal modifications which have been made to parts of the process,
without considering the process as a whole, causing inefficiencies and inconsistencies.
These problems arise over time and may include:
Duplication of work
Lack of standardisation
Inconsistent measurement or control
8.7 Improving business processes
By removing problems identified in the as is process and challenging assumptions,
upon which the current process was built, we can improve the process. The approaches
to take include:
Simplifying the process
Remove bottlenecks
Change the sequence of tasks
Redesign the process
Redefine the process boundaries
8.8 Process measurement
As well as designing improved business processes we must define how well that
processing must be carried out, how it will be measured. There are two perspectives on
performance measurement: for internal management purposes and for external
customers.
Internal measures are often derived from organisational objectives, critical success
factors and key performance indicators, defined at each level of the organisation. The
problem is that the focus here is on what the organisation wants to achieve and not on
what the customer values.
External measures relate to what the customer expects to have delivered. The three
main areas to consider when improving a business process are
the time it takes to complete a process or task
financial measures, such as costs and prices
the quality measures associated with accuracy and effectiveness
Process and task measures
The customer will have an expectation of the organisations performance in delivering
the product or service. Internally, the process may be made up of several tasks each of
which will need to be allocated performance measures.
-
8 Modelling Business Processes
8 Modelling Business Processes v1 Page 37
These measures need to work collectively to achieve the overall performance measure
for the product or service. A timeline may be added to the swimlane diagram to show
task durations.
Performance issues
Measures and targets need to be chosen with care, especially when managers are
given incentives to achieve those targets. Targets change the way people behave and
this can lead to sub-optimisation where seemingly better performance in one part of
the business can result in poorer performance for the business as a whole, and hence
failure to meet customer expectations.
8.9 Six Sigma
An alternative approach to process improvement developed by Motorola in the 1980s
and based on ideas from statistical process control. Six Sigma follows a five-step
approach: define the problem, measure the data, analyse the problem, improve the
process by removing the root causes, and then introduce control to prevent the original
problem from reoccurring and to maintain the benefits of the changes made, the
DMAIC approach.
Extract from
Debra Paul, Donald Yeates and James Cadle (2010), Business Analysis (2nd Edition),
BCS.
-
9 Gathering Requirements
pcr_09_gathering the requirements v1.docx Page 38
9.1 Why is it so difficult to get the requirements right?
Well whenever you meet anyone from the business user team and ask them what it is
they need, or what is the problem, the chances are you will be given all sorts of
information, opinion, view, want, wish, hope and solution.
All muddled together without any clear view of what is the most important or critical
requirement, if indeed you have all the requirements.
Is it unreasonable to expect clear, concise requirements from people, well possibly it is,
but the business analyst should strive to achieve this as the requirements are the basis
for the future development and will form the bedrock of all that happens next.
Typical problems with requirements have been identified as;-
Lack of relevance to the objectives of the project
Lack of clarity in the wording
Ambiguity
Duplication between requirements
Conflicts between requirements
Requirements expressed in such a way that it is difficult to assess whether
they have been achieved;
Requirements that assume a solution rather than stating what is to be
delivered by the system
Uncertainty amongst business users about what they need from the new
system
Inconsistent level of detail
Business users and analyst taking certain knowledge for granted and
failing to ensure that there is common understanding.
Some of these problems arise because there are no clear terms of reference for the
project, although the business have selected an option from the choice presented to
them in the business case, it is still possible for them to have personal ideas about what
is being proposed.
A Useful mnemonic to remember for the terms of reference is OSCAR which stands for:
Objectives of which both business and project objectives should be defined.
Scope the aspects to be covered, typically defined by specifying the activities
and deliverables of the project. Also areas that are out of scope.
Constraints any constraints that apply such as budget, timescale or standards
that are applicable.
-
9 Gathering Requirements
pcr_09_gathering the requirements v1.docx Page 39
Authority the business authority for the project, ensuring that there is an ultimate
arbiter to handle any conflicts between business users and their requirements.
Resources the people and equipment available to the project.
Recognising that it is essential that the requirements are well structured, correct,
concise and complete before further work takes place has led to the necessity for a
requirements engineering process.
9.2 REQUIREMENTS ELICITATION is the first activity, which is concerned with
gathering information and requirements from the business stakeholders.
The business user will be asked, by means of an interview or a workshop or some other
fact finding technique to tell the business analyst what they know about their job.
Usually you will be given lots of explicit knowledge; knowledge of procedures and
data, the things that they can easily remember. What is difficult for people to recall or
share is the tacit knowledge that is born of performing a task frequently and intuitively.
Examples of difficulty with gathering requirements:-
Skills explaining how to carry out actions by using words alone is very difficult
and sometimes people forget the detailed steps.
Taken-for-granted information - very difficult to ask about things you dont
know, that you dont know.
Front story/back story- you can be told what the standard approved process is
but this might not be how they actually do their job, there might be work arounds
in place that they dont want to admit.
Conceptualising requirements trying to imagine how the system will work in
practice can be difficult; various techniques will help with visualisation.
-
9 Gathering Requirements
pcr_09_gathering the requirements v1.docx Page 40
Your finger you fool - cultural differences mean that, what one group might
consider normal practise another country might not understand.
Intuitive understanding, usually born of considerable experience - very
difficult to enunciate but over time people just know what to do, if asked to
describe how or why they did something they might not be able to describe the
steps.
In addition to an individuals tacit knowledge there will be organisational tacit
knowledge where again things are just known rather than documented and written
down. These include:-
Norms of behaviour and communication these evolve over time in every
organisation.
Organisational culture.
Communities of practice different parts of the organisation may have their
own ways of working which are not universally shared. A business analyst would
need to be aware of these if there are crossfunctional changes.
Organisation history
Types of tacit and explicit knowledge
Tacit Explicit
Individual Skills, values, taken-for-granted knowledge, intuitiveness
Task definitions, job descriptions, targets, volumes and frequencies
Corporate Norms, back story, culture, communities of practice, organisation history
Procedures, style guides, processes, knowledge sharing repositories, manuals, company reports.
9.2.1 Requirements elicitation techniques
The fact finding techniques have already been described in chapter 5, but where you
have tacit knowledge there is a need to reveal this information and wherever possible
change it into explicit knowledge by means of documentation and dissemination.
Specific fact finding approaches will be more successful than others and these include:-
Become an Apprentice by shadowing or protocol analysis
Scenario role-playing and prototyping can Enact a particular process
Tell a story or build a scenario and Recount what is happening
Do some observation and Observe what actually happens
-
9 Gathering Requirements
pcr_09_gathering the requirements v1.docx Page 41
Use these approaches to get the tacit information, report and record, what information
you get and disseminate this to your team. The mnemonic AERO may help you
remember these approaches.
Maiden and Rugg (1996) produced the following table of techniques and which
knowledge types they were useful for.
Technique Explicit knowledge
Tacit knowledge
Taken for granted
Front/back story
Skills Future Requirements
Interviewing XX X X X X X
Shadowing XX XX XX XX XX X
Workshop XX XX XX X X X
Prototyping XX XX XX X XX XX
Scenario Analysis
XX XX XX X X XX
Protocol Analysis
XX XX XX X XX X
As we gather the requirements we will need some organised way to hold all the
information, this is covered in building a requirements list, ultimately an organised
requirements catalogue will be produced. The business needs log, covered in chapter
5, is an input to the requirements list. The list should contain basic information in three
columns, Requirement, Source and comments, all of which will be built on to form the
requirements catalogue.
9.3 REQUIREMENTS ANALYSIS the second activity in the requirements engineering
process.
Separating the elicitation and the analysis of the requirements gives the business
analyst the chance to look again at the requirements and to ensure that they meet the
quality criteria so they should be:-
Clear, concise, feasible, aligned with the project objectives, not in conflict with other
requirements nor overlapping or duplicating.
-
9 Gathering Requirements
pcr_09_gathering the requirements v1.docx Page 42
Firstly it is useful to group the requirements according to the following categories:-
BUSINESS GENERAL Business Constraints
Business policies
Legal
Branding
Cultural
Language
Business Continuity
SOLUTION FUNCTIONAL Data Entry
Data Maintenance
Procedure
Retrieval
BUSINESS TECHNICAL Hardware
Software
Interoperability
Internet
SOLUTION NON-FUNCTIONAL Performance
Security
Legal and Access
Backup and recovery
Archiving and retention
Maintainability
Availability
Usability
Capacity
Next apply a series of filters in order to ensure that the requirements are well defined:-
Overlapping or duplicate requirements
Unravelling multiple requirements
Necessity checking
Feasibility evaluation (technical, business and financial)
Removing conflicts
Checking for solutions
Confirming quality, checking for requirements which are:-
Clear Concise Consistent Relevant
Unambiguous Correct Testable Traceable
Naturally there will be some need to tidy up following this activity with the following
actions needed:-
Accept the requirement as it stands and document it in full in the requirements
catalogue
Reword the requirement to remove jargon and ambiguity
Merge duplicated or overlapping requirements and reword them
Take unclear, ambiguous or conflicting requirements back to the business users
for clarification.
-
9 Gathering Requirements
pcr_09_gathering the requirements v1.docx Page 43
Hierarchy of requirements
Requirements are often related to each other, some general and technical requirements
refer to business policies that are elaborated and expanded in the non-functional and
functional requirements. Understanding the hierarchy of requirements helps ensure that
they are consistent and coherent. When we define the functional requirements the
business context and basis that underpins and supports it is clear, similarly we
understand why the non-functional requirements are so important to the business.
Finally, make sure that the requirements are SMART, specific, measurable,
achievable, relevant and time-framed.
9.4 VALIDATING REQUIREMENTS the third activity in the requirements engineering
process.
The requirements will need to be validated to ensure that in the rewording or rephrasing
activity nothing has been lost and that they still represent an accurate statement of the
business representatives requirements.
A review group, workshop, (led by a chairperson with a business analyst on
hand)made up of key stakeholder groups as listed below must check the requirements
to see that they meet their needs, suggested participants are:-
The business sponsor in business alignment and within scope.
The business owners - address business needs
The domain expert they reflect business practice
The developers they are technically feasible
The testers that they are testable
Project Office - compliant with quality and business standards.
The outcome of the review will be
1. signed off where all the requirements are satisfactory
2. Minor amendments will require modification before the review chairperson
accepts the document and then it is signed off.
3. Major amendments will require another review following significant reworking
9.5 REQUIREMENTS DOCUMENTATION is concerned with the development of a
well-organised requirements document; this is covered in chapter 10.
9.6 REQUIREMENTS MANAGEMENT anticipates the need for change control of
the requirements, because it is highly likely that there will be some level of
change during the project, and control is needed to ensure this does not de-rail
the project.
-
9 Gathering Requirements
pcr_09_gathering the requirements v1.docx Page 44
Who is involved in this requirements engineering process?
As expected there are two groups who are involved:-
The business representatives:-
The project sponsor. Their role is to ensure the project is successful overall, the
sponsor owns the solution.
The domain expert (or subject matter expert). The people who provide high
level advice on the requirements, they bring a breadth of knowledge about the
business area.
The business users. These people will be the new users of any changed
environment, they are directly impacted by any changes and will ultimately be
using any processes as Business as Usual (BAU).
The second group are the project team or teams who will be responsible for
developing the solution.
The project manager manages the team to ensure delivery of the new or
amended artefacts, the business system and the IT solution. Performs all the
expected management functions to keep on track and within the business case,
which is constantly monitored.
The business analyst performing the requirements engineering work and then
developing the business outputs needed.
The developers will check the technical feasibility of some of the requirements
and help the business analyst appreciate the technical implications of them. The
developer will be able to produce prototypes to help the business users to
visualise what they have requested.
Extract from
Debra Paul, Donald Yeates and James Cadle (2010), Business Analysis (2nd Edition),
BCS.
-
10 Documenting and managing requirements
pcr_10_documenting and managing requirements.docx Page 45
10.1 There are many reasons for needing good documentation.
1. It enables communication within the project team and provides a basis
for ensuring that all of the related requirements are consistent with
each
2. It provides a firm basis for validating the requirements by
stakeholders.
3. Any further work to develop and test the business solution will use
the documentation as input to these activities.
10.2 THE REQUIREMENTS DOCUMENT
Structure the document needs to be clearly laid out and should wherever possible
follow a standard template to ensure nothing is forgotten.
Content -
Introduction and background business situation and drivers for the
project
Business Process Models to be process and optionally the as is
process
Function model context or use case diagram of the proposed
software solution
Data model as appropriate to the solution (ERD or CLASS diagram)
Requirements catalogue developed from requirements list (chapter 9)
Glossary of terms
Additional business specific documents
Documenting a requirement
The requirement list created in chapter 9 is further developed to become the
complete requirements catalogue using where possible a standard template or
possibly a software tool for the purpose.
Contents should include:-
1. Unique requirement identifier for each requirement to aid traceability
2. Requirement name
3. Requirement description
4. Source
5. Owner
6. Author
7. Type of requirement
-
10 Documenting and managing requirements
pcr_10_documenting and managing requirements.docx Page 46
8. Priority
a. M must have
b. S should have, need it in 2nd increment
c. C - could have if time and budget allowed
d. W wont have this time
9. Business area
10. Stakeholders
11. Associated non-functional requirement
12. Acceptance criteria
13. Related requirements
14. Related documents
15. Comments
16. Rationale
17. Resolution
18. Version history
Producing a full definition for each requirement will be extremely time-consuming
and not in all cases necessary so consider the following:-
The stage of the analysis, might be too soon to have much detail
The nature of the solution, IT or business process change
The priority, if it is rated as W, wait until it becomes an M or S priority
The SDLC
10.3 MANAGING THE REQUIREMENTS
The elements of the requirements management lifecycle are:-
Requirements identification Unique id.
Cross-referencing Backwards from traceability to a requirement from any later stage in the business change or SDLC including testing.
Forward to traceability to identify any requirement and track where it has been developed and implemented.
Origin and ownership The source of this requirement and the future business owner who will be responsible for using it.
Configuration management Configuration management is all about controlling changes within a project and protecting requirements from unauthorised change. Mechanisms must be put in place to ensure correct Configuration is adhered to these include:-
-
10 Documenting and managing requirements
pcr_10_documenting and managing requirements.docx Page 47
Configuration identification
Configuration control ensuring work products are base lined.
Software support Where and how the requirements will be managed, a software tool would be useful
Change control Documenting the proposed change (a change request)
Consulting the stakeholders
Deciding on the change
Extract from
Debra Paul, Donald Yeates and James Cadle (2010), Business Analysis (2nd
Edition), BCS.
-
11 Modelling Requirements
PCR_11_ Modelling requirements.docx Page 48
11.1 Any document which contains lots of words will be constrained by the
individuals who write it and the people who read it, their own knowledge will always
influence their understanding.
Not so with a model which has been drawn to precise modelling notation and rules,
once verified, the models can be interpreted unambiguously.
This syllabus uses well recognised and commonly used models from two standard
approaches:-
Unified modelling language (UML) for both data models (CLASS DIAGRAMS)
and process models (USE CASE DIAGRAMS)
Structured methods data model an Entity Relationship diagram (ERD)
11.2 Modelling System Functions.
A function may be defined as a set of actions that the business users want the IT
system to support in order to achieve a specific goal, such as ACCEPT ORDER.
In the UML a use case is something that an actor wants the IT system to do, it is
a case of use of the system by a specific actor and describes the interaction
between the actor and the system. Each use case will have a stated goal and will
contain a description of the actions that the system must perform in order to achieve
the goal.
The use case diagram will consist of the following elements:
Actors - whoever requires a service from the system, could be people, time
or another system.
Each use case is shown in an oval and represents a function that the system
will perform in response to a trigger from the actor, the naming of use cases is
always verb-noun
The system boundary is indicated by a line around all the use cases with the
actors on the outside, this identifies the scope.
Associations indicate which actors will need to interact with which use case.
-
11 Modelling Requirements
PCR_11_ Modelling requirements.docx Page 49
Use case diagrams are particularly helpful during a workshop as they are easily
understood by business users and provide an excellent framework for discussion.
The extent that a business analyst on this course needs to understand use cases is
elementary; however there are a couple of things that should be considered for
inclusion.
The use of and
o is used to identify common processing, where something
always happens. As each use case will eventually be coded,
duplicated information can be taken out and put into a standard
component so that it is only coded and tested once.
o is used where, under certain, specified conditions, some
additional processing is required, exceptional or infrequent things. The
extend items are permitted within the business rules and extend the
*functionality of the use case.
-
11 Modelling Requirements
PCR_11_ Modelling requirements.docx Page 50
ENTITY RELATIONSHIP DIAGRAMS
These diagrams are used to identify the data structures required within any
organisation and are generally created and maintained for a whole organisation.
Specialist data modelling skills are required and many organisations will have expert
data analysis staff.
The purpose of the diagrams is to identify the data that is of importance to any
organisation, to record the details of where the data is held and the relationship
between one set of data and another.
The terminology used is:-
An ENTITY something of interest to the organisation that the business needs
to hold details about such as:-
o Something physical - an order, a customer a supplier
o Something conceptual a booking or an appointment
o Something active a meeting or a course
When drawing an Entity relationship diagram the entities are represented as
rectangles.
Hidden within an entity are the attributes, the bits of data that are held within
that entity, such as an order date, a customer name, a supplier address. The
attributes will be held within a data dictionary and will define the size and
format of the data itself, an order date would be numeric for example.
-
11 Modelling Requirements
PCR_11_ Modelling requirements.docx Page 51
Entities should be related to other entities by certain business rules and these
are represented by lines connecting entities. These lines are known as
relationships and the extent to which the entities are related is also included,
the relationship can be:-
o One-to-many
o One-to-one
o Many-to-many
This diagram tells the business analyst that an
Order will always have at least one Order item
and could have an unlimited number of order
items.
An Order item is always linked to one and only
one Order.
It is a One to many relationship.
Here the diagram tells the business analyst that
a Customer may not have an Order but if they
do have an order they could have an unlimited
number of Orders.
An Order is always linked to one and only one
Customer.
It is an optional relationship.
Here we show a many to many
relationship which is permissible
during analysis but once we get
to design it would need to be
resolved as it usually indicates
something missing.
-
11 Modelling Requirements
PCR_11_ Modelling requirements.docx Page 52
When developing Entity Relationship diagrams business analysts and systems
analysts would be working together to get the information, which initially is a logical
representation of how the data is grouped. When the systems developer takes the
logical model into the design activity the models will turn into databases and files as
appropriate.
Every entity identified will hold information relating to its contents, a Customer entity
will hold data about the companys customers, if a company has 10,000 customers
then we would expect the customer file to hold 10,000 occurrences of customer
data, all of them different with some unique way of referencing them, usually a
customer number..
All relationships within an ERD
should be named so that the
diagram can be read in a
clockwise manner.
A Customer must be allocated to
a Sales Region. A Sales region
may be responsible for many
Customers
The last relationship we consider
is an exclusive relationship where
you can have either one or the
other but not both.
-
11 Modelling Requirements
PCR_11_ Modelling requirements.docx Page 53
CLASS MODELS
Class models are used in the UML to represent the data connections in a similar way
to the Entity Relationship Diagrams, there are notational differences as you would
expect, but there are also interpretation and usage differences to be understood too.
ENTITY RELATIONSHIP DIAGRAM CLASS MODEL
ENTITY CLASS
OCCURRENCE OBJECT
ATTRIBUTES ATTRIBUTES
RELATIONSHIP ASSOCIATION
Not applicable OPERATIONS
A class will contain many objects, each object has a number of attributes, and in
addition a class diagram also shows for each class what the operations are that can
be performed on this class, these are the use cases identified in the functional
model. As each use case will mention the data attributes that it requires to perform
its functions, within the UML the data attributes are said to be encapsulated within
the use case This is a key feature of the Object Oriented approach that uses the
UML, fortunately in this syllabus you are not expected to know any more about OO
than that.
As with the ERD, the association lines show the connections between classes but
here, the line indicates that classes communicate via messages sent along the lines.
Multiplicity is also handled slightly differently on these diagrams. Where we had
crows feet to indicate many on an ERD, here we have the following symbols:-
1..*, is 1 to many
0..* is 0 to many
1..n indicates that you can use a specific number.
Both ends of an association will use the symbols
-
11 Modelling Requirements
PCR_11_ Modelling requirements.docx Page 54
Class models have a couple of special diagramming mechanisms:-
Generalisation and inheritance is used to indicate where shared data is
identified and separated into an additional class. Each class is said to inherit
the generalisation attributes and operations and vice versa.
An association class is used to resolve many to many associations which
as mentioned in the ERD section are not acceptable at the design stage.
Extract from
Debra Paul, Donald Yeates and James Cadle (2010), Business Analysis (2nd
Edition), BCS.
-
12 Delivering the requirements
PCR_12_Delivering the requirements.docx Page 55
12.1 Once the requirements have been defined attention shifts to how the solution
can be implemented, the work done so far could require a major programme of
projects or a straightforward project involving both IT and business changes.
Quite often the business change team will be involved with determining the delivery
approach, i.e. the way the changes will be implemented into the business.
The factors under consideration will be;-
The business context. The nature of the organisation and the project
that will provide the basis for deciding how the solution will be
delivered.
o The nature and underlying philosophy of the organisation, here
we can consider questions such as what type of organisation this is,
the nature of the business domain within which it operates and the
values and beliefs of the senior managers.
o The business context for the required change, for example, what
the organisation is hoping to achieve in terms of business benefit as a
result of this project.
o Constraints on the project, for example timescales for delivering the
solution, the budget, what resources are to be made available and the
standards for the organisation.
o The prioritised needs of the business, for example improved public
image may be more important than cost savings or vice versa.
o The drivers for the project, for example whether this project is based
upon a need to comply with new legislation or whether it is concerned
to offer additional or enhanced services to customers.
The lifecycle, the process adopted for developing and implementing the
solution.
o The business change lifecycle shows the overall process but does not
show how the IT solution will be delivered. The development
approaches to IT systems are known as systems development
lifecycles (SDLCs) There are a number of approaches that might be
used as these have developed over time.
o The waterfall lifecycle was the original way in which systems were
developed through a series of sequential stages, each performed once
the previous stage has completed. The sequence of the stages is;-
Feasibility study
Analysis
Design
Development
Testing
Implementation
-
12 Delivering the requirements
PCR_12_Delivering the requirements.docx Page 56
Output from one stage is input to the next, with sign off at the end of
each stage. Waterfall is still used in some places, and often for smaller
system changes. The principal benefit of this lifecycle is that it enables
good project management control. However the two major drawbacks
are the lack of testing until the solution was complete, and the difficulty
in making any changes throughout the lifecycle.
The V Model SDLC was introduced to link development activity with
testing activity. So all the phases of the waterfall are still performed but
each stage also has a level of testing linked to it, this makes for a more
robust development lifecycle.
o The stages and testing levels are;-
Define requirements -Ensure user acceptance
Design solution ----- -Test solution
Develop solution ----- Test modules
o There is an extended V model, which includes these additional
stages;-
Analyse business needs business Case > Review
Benefits
The incremental lifecycle takes the first three stages of the waterfall
model; feasibility study, analysis and design, as a separate unit of work
and then breaks down the rest of the development into increments to suit
business need. So, increment one will develop, test and implement the
most essential processes required by the business, increment two will then
develop, test and implement the next set of requirements and so on. IT
functionality is delivered in phases.
Boehms spiral model is used when requirements need to be clarified
during the build activity but control is still required over the whole
development. This approach greatly influenced the development of Rapid
Application Development (RAD). RAD has become hugely popular in
recent years as businesses need to change their requirements based on a
number of prototypes of the software. The prototype evolves and finally is
implemented in one delivery.
The approach, taken by both the IT development team and the business
analyst for the business artefacts, will involve methods and standards that
ensure