Blog - Business analysis training courses, online e-learning uk

Requirements – What’s the problem?

The definition of requirements in terms of solving problems and satisfying objectives, originally specified by the IEEE, is now widely used.

It is referenced by both the IIBA and the BCS international Diploma in Business Analysis. It is the definition that we often refer to at Capiro.

In this article for the IREB Requirements Engineering newsletter. September 2017, the authors examine this definition and some of its implications.

The IEEE definition of a requirement is probably not perfect – What is? But it does highlight that solutions cannot be defined in a vacuum – they need context. That context is the problem that needs to be solved or the objective that needs to be realised; problems stand in the way of the achievement of objectives.

The article emphasises the importance of looking at the big picture. Problems and objectives (goals) tend to be related to other problems and objectives. Proposed solutions will each demonstrate varying degrees of support for the achievement of corporate (strategic) objectives. Stakeholders will have differing opinions as to what constitutes a problem, a goal or a solution. Any one solution will have implications in terms of risks, costs, benefits, stakeholder support, implementation challenges and operational characteristics.

The authors invite comments on their article.

Please note that the IREB newsletter is free and that you can sign up with IREB to receive it regularly.

The business agility manifesto

The business agility manifesto offers a guide that organisations, business analysts and business architects can use to understand what business agility is about. But can the business agility manifesto help to achieve business agility?

Ever since the presentation of the agile manifesto, which was primarily related to computer programming, the word agile is appearing in ever greater number of contexts.

As Bertrand Meyer, in his book, ‘Agile, the Good, the Hype and the Ugly’, asks, “Who wants to say they are not agile?” And as many consultants, trainers and authors can confirm, use of the ‘A’ word is great for driving sales.

The subject of how to achieve business agility has been gaining increasing traction over the last few years.

Business agility goes beyond software development. It concerns, among other things, the ability of an organisation to continuously and safely adapt itself to

Changing environments
Changing customer expectations and demands

However, as with agile itself, there are many opinions as to exactly what business agility is. Now we have the Business Agility Manifesto. It offers a checklist that organisations can use to see if they have business agility.

The manifest’s authors are Roger Burlton, Ronald Ross and John Zachman.

These three men are all very well known in their own spheres of business processes, business rules and business architecture respectively. Along with business data, these aspects are critical to achieving business agility. We focus on them, for instance in our Three+One approach.

The authors describe the manifesto as a pathway forward – Into the ‘Knowledge Age’.

Will it trend? See what you think.

Data capture at the speed of thought

Yesterday’s technologies.

One thing that hasn’t evolved that much for the average computer user is how to get what they’re thinking into the computer. Most business analysts probably still think primarily of the old technologies.

We’ve had keyboards forever. And many business analysts spend a significant proportion of their time as an (untrained) typist.

Unless we can ‘touch type’, business analysis activities such as writing up interview notes, reports and business cases tend to be relatively slow and error prone.

We perhaps concentrate on our actions at the expense of the quality of our content. We ought to be able to use our minds more efficiently and more creatively.

Today’s technologies.

Voice input can help, but is problematic in a noisy office.

Various forms of scanner are great for a limited range of jobs.

It would be useful to make business analysis activities more efficient. And as a business analyst, you might want to offer your users something really innovative. Nice idea, but how easy is this in practice?

There have been some great innovations for specific roles such as surgeons who obviously need to work ‘hands free’ of everything except the tools of their jobs. We are getting an insight into what is coming. Which takes us to tomorrow’s technologies.

Tomorrow’s technologies.

How about being able to tell the computer your innermost thoughts without touching anything? An article in Wired magazine takes a look.

Check out Wired magazine’s article on Ctrl-Labs.

Levels and roles of business analysis

Levels of business analysis

Strategic: Business transformations; Portfolio management; Business change; Business architecture and Target operating models; Business agility; Benefits realisation.
Operational: Business processes; Business data; Management information and Decision support; Business rules; Business cases; Business requirements discovery; Problem analysis.
Tactical: Software requirements specification and management;

Business Analysis Roles and Qualities

Business analysis is a demanding function comprising many specific roles, e.g.

– Agent of change; Problem Solver; Modeller; Planner; Facilitator; Negotiator; Reporter; Mediator; Interpreter; Fact Finder; Interviewer; Reviewer; …

Business analysts need to be:

– Business and people oriented; Technically savvy; Effective networkers; Team players; Independent of politics; Self starters; …

Business Analyst Skills Profile

To fulfill the demands of the job, business analysts need a variety of skills, both hard and soft, e.g.

Understand the nature of business strategy, goal setting and business planning.
Able to think conceptually, to analyse and understand root causes of problems and to identify business based solutions to the identified problems.
Able to create business architectures and participate effectively in business change programmes.
Competent with business process modelling, business data modelling and business rules.
Requirements discovery and specification techniques for functional and non functional requirements.
Possess a large range of communication skills including making presentations, interviewing, facilitation of workshops, attending and running meetings and report writing.
Demonstrate inter-personal skills such as team leading and negotiation.
Apply project skills such as the creation of business cases, setting objectives, planning, estimating and project management.

What is a business analysis centre of excellence?

A framework for improvement

Business Analysis Centre of Excellence Framework

A Business Analysis Centre of Excellence (BACoE) (or Center of Excellence in the United States), is a framework that provides structure, context and content for improvement initiatives in business analysis and its relationship to other development centres.

A business analysis center of excellence is a tool for:

Ensuring that the capabilities of business analysts match the needs of the organisation
Implementing lessons learnt during programmes and projects
Working closely and effectively with all project stakeholders and participants
Assisting in portfolio planning
Assisting in managing the realisation of benefits identified in programme and project business cases
Working efficiently and effectively in all types of project
Helping to boost business agility
A source for the development of a business architecture

Optimising Business Analyst Performance

A business analyst’s role is very much about the continuous improvement of business capabilities. But the capabilities of each business analyst and the whole business analysis function also need to be continuously improved .

Unfortunately, business analysts and other team members often do not have the time, the independence, the authority or appropriate organisational structures to examine and improve their own capabilities and to optimise their own processes and performance.

Sometimes business analysis teams are not aware what a process of continuous improvement of their own capabilities might look like. Agile business analysis approaches can help, but even here it is not always easy to agree what should be done, how to go about doing it or finding the time to do it. This is where the Business Analysis Centre of Excellence (BACoE) comes in.

A Business Analysis Centre of Excellence (BACoE) (or Center of Excellence in the States), is a framework that provides structure, context and content for improvement initiatives in business analysis and its relationship to other development centres.

Why have a business analysis centre of excellence?

Business analysis skills, and suitably skilled business analysts, are critical to the success of change projects, particularly when it comes to:

Discovering the essence of the business problems to be solved and the business opportunities to be achieved
Solving those problems in a manner that is line with the business and IS/IT strategic objectives
Identifying and managing risks and benefits of the proposed solution in line with corporate and IT governance policies
Achieving business agility – the ability to respond rapidly and effectively to a changing world

The business analysis team obviously cannot achieve the above alone. A framework for cooperation, communication and negotiation with all business and IT stakeholders is critical to project success. This framework is supplied by a business analysis centre of excellence.

Who writes user acceptance tests?

The users should write and run the user acceptance tests?

Testing against requirements — What did the requirements say?

This is probably true, at least in theory, but as we shall see, things are rarely that simple; that’s life.

User acceptance testing (UAT) is the responsibility of the users. By ‘user’, we are typically referring to those stakeholders who will use the system to support their roles in the day to day operation of the business. At least some of these users have hopefully been involved in the elicitation of the user requirements. There are a few things to consider:

Do we know all the categories of user?
Do the users know how to create and run tests that will promote confidence in the software’s ability to comprehensively and reliably support the business operation?
Should user acceptance testing include any non business categories of user such as system administrators?
Should other categories of acceptance testing be conducted for non business categories of user?
Should any stakeholders that would not be described as users, of any description, be involved?

Let’s look first at what we mean by user acceptance.

What do we mean by ‘user’ acceptance testing?

Acceptance testing should demonstrate, to those who will be purchasing, using or managing the system, that the system is ready for prime time. In using the term, User Acceptance Testing, we should define what we mean by a ‘user’. We test acceptance generally by running the software system and checking for compliance with the the ‘acceptance criteria’, for that system; acceptance criteria are normally based on the requirements and in some cases are an alternative to writing detailed requirements; we discuss acceptance criteria later in this article.

Testing should ensure that the developers have:

Understood the requirements
Created code that satisfies the requirements

What testing does not do is check that the requirements are correct, i.e.

That the requirements really do represent what the users want
That what the users want, or say they want, is what the business really needs

For this article we’ll consider only those tests that implicitly assume that the requirements are correct, although note the comments on ‘acceptance criteria’ in the section, ‘Role of the requirements authors’.

What we ideally want to ensure is that the software system that has been created will support the regular operations of the business, including anticipated variants to the norm. To achieve this, we have to ensure that we test in the context of the relevant business processes, information systems and business rules; does the new system really support these things? We will implicitly assume that we are also testing the user (clerical) procedures and the user manuals.

Acceptance testing is typically among the last thing the project team are involved with before commencing handover of a new system to release management, the business and to the system administrators. By that time, everyone should have confidence that the system does work; bugs should not be surfacing at that stage. Bugs should have been eliminated during earlier testing phases such as unit, component, integration and system testing. Of course, some bugs will still crawl out during acceptance testing, but if too many of them surface, user confidence will vanish.

Before we consider who should, or shouldn’t, write the acceptance tests, we ought to consider who should, or shouldn’t, write those confidence promoting tests that are run prior to UAT.

Who should NOT write the tests, pre UAT?

The answer to this question is often based on the premise that the person who authored the object being tested is not the best person to write and run the tests; the author(s) may not be sufficiently objective. This suggests that programmers should not test their own code. We recognise of course that programmers typically do test their own code. Some organisation make a pragmatic compromise, with programmers doing the initial tests and more independent testing roles following this up with additional tests.

We are also aware that many people maintain that the programmers ought to test their own code. This is particularly true in environments where development team members are all generalists, i.e. everyone is supposed to do everything, or anything. Some agile environments promote this sort of approach. There is however, a good body of opinion that says that leaving the authors of the programs to do all the testing is not sufficient to promote confidence on the part of the customers and users. Furthermore, certain types of test such as performance, security and usability testing, perhaps using specialist tool sets, requires specialist expertise.

Who should be involved in designing and writing the tests, pre UAT?

We are excluding the program authors from this section simply because we have already discussed their possible roles.

There are many broad approaches that can be combined to identify the stakeholders who could or should be involved:

Requirements authors
Business stakeholders including independent subject matter experts
Technical and other specialist experts
The organisation’s specialist test team, assuming that it has one
External (outsourced) specialist testers; these may be expensive but they are independent, e.g. of project managers and business managers

Role of the requirements authors, pre UAT

Acceptance criteria come in various shapes and sizes, but essentially they are the basis of a mechanism for testing that computer code satisfies requirements. Requirements can be refined into ‘acceptance criteria’; if a requirement is not testable, it’s not a requirement. Alternatively, a user story might be defined as a placeholder requirement and the detail is defined as acceptance criteria; your choice.

The way that acceptance criteria are identified is all important. The process of specifying acceptance criteria may well challenge the thinking about the requirements themselves, e.g. their wording, rationale, priority and associations with other requirements.

Being obliged to write the acceptance criteria forces the requirements authors to immediately analyse the requirement for completeness or comprehensiveness, clarity, complexity and over engineering, precision and ambiguity; there is of course a lot of overlap between each of these terms. Acceptance criteria force examination of the basis of the requirement.

Depending on your approach to requirements, the authoring group might comprise users, business analysts, product owners and managers, user experience experts, subject matter experts and other concerned stakeholders, e.g. finance or legal. Again, depending on your approach, the authoring group might include developers and various groups with professional sounding titles such as engineer or architect.

In gathering or discovering requirements, the emphasis might have been, perhaps unwittingly, on quantity and speed over quality. Acceptance criteria should provide a counter to this; it should improve real productivity through early elimination of errors, omissions and misunderstandings. The authoring group could take a ‘hackathon’ approach to this task, brainstorming acceptance criteria and rewriting or adding detail to the requirements as necessary.

The kind of activity described in this section is a form of testing; it is a test of the requirements themselves. This form of testing is sometimes described as ‘static testing’. It is very effective at improving the quality of the delivered software product whilst speeding up the rest of the development process. Involving the users, product owners and subject matter experts should ensure that the requirements really do represent what the business wants and needs.

Testing using working software is called ‘dynamic testing’. Static testing supports dynamic testing. Our testing budget only allows a finite number of tests to be run; if static testing, hackathon style, has eliminated many issues, dynamic testing should also be should be more efficient.

Role of specialist test teams pre UAT

Specialist test teams can and should apply static testing techniques to the requirements; they should review the requirements, including the acceptance criteria, prior to developing the dynamic tests. They can do this as soon as the requirements are available. This practice offers additional quality checks on the requirements; have the developers, the testers and the users all understood the requirements in the same way; see requirements discovery is child’s play. Feedback should immediately be given to the requirements author(s).

Specialists test teams will run the dynamic tests of the software as soon as it is ready. There are typically multiple levels of test, e.g. component (unit) tests, integration (link) tests and system tests. At the start of integration testing, planners can refer to feedback from component testing. System test planners can refer to feedback from integration tests. The feedback should include sight of the expected and actual test results. Assuming that all is going well, these activities should add to the feeling of confidence about the system under construction.

So finally, who does write the user acceptance tests?

The acceptance criteria are basis of the user acceptance tests. By the time user acceptance testing starts, the team responsible for running them should have a comprehensive set of acceptance criteria.

For each acceptance criteria, one or more tests can be written and run. The exact number of tests will depend on such things as:

System criticality and strategic importance
Level of confidence gained so far
Time
Money

There is a choice of options for who runs user acceptance tests. Whoever does do it will obviously need to be familiar with the system. This familiarity might be gained by involvement in the development process, reading the requirements documentation, helping to establish acceptance criteria or receiving training in the system.

Options for who does it might include:

The users and product owners alone, perhaps with some training from specialists testers or business analysts
The users and product owners with the support of some combination of testers, business analysts, or others
The organisation’s specialist acceptance test team, if it has one
An external group of testers, e.g. a group from a consultancy that specialises in testing
Users as observers whilst a specialist team do the actual tests

There is no universally correct answer to this. It will depend on such things as:

Availability of staff
Risks associated with the operational system or systems involved
Nature and complexity of the system
Organisational capacity and expertise of available staff
Organisational culture
Other factors relevant to specific organisations

Who reviews the results of acceptance testing?

Ultimately the project sponsor must be accountable for the review and consequent decision about acceptability. In practice the sponsor is likely to rely on the recommendations of others, including the project manager and customer representatives such as product owners and product managers. It is the comprehensiveness and effectiveness of the entire process that will give weight to the quality of these recommendations. The entire team can make contributions, direct or indirect, to the writing and running of the user acceptance tests.

Keep me about informed course launches and special offers

How well do you know your business processes?

Processes and value

Strategic context for processes — The strategic context for processes

Organisations, commercial and non commercial, serve groups of people who can be regarded as clients or customers. It is essential that every organisation understands what these customers value. The organisation must create that value and create a strategy to deliver it.

Business process improvement must be based on:

Understanding of the customers
Awareness of what they value
Appreciation of the strategy to deliver that value.

This is the basis for boosting business agility.

Organisations create value – Business processes deliver that value

The above model demonstrates how any business process operates in the context of:

The external environment, that is outside their control but which they have to align with
Suppliers of resources linked in often complex and increasingly international supply chains
Partners
Customers for their services and products
Competition for their customers and their suppliers: this affects their costs and their pricing
Sources of finance
Executives and “owners”:

For more views on this model, see:

‘White Spaces Revisited’ by Rummler
‘The Basics of Business Process Mapping’, by Damelio

Top 3 rows of Zachman column, ‘How’ – The Processes

The top three rows of the ‘How’ column are concerned with defining and modelling the business processes. The language of these rows is the language of the business stakeholders.

Row 1: Contextual. Try to list all of your organisation’s core and support business processes.
Row 2: Conceptual. Try to identify the areas of activity that your organisation is concerned with. Highlight the dependencies between these areas. Peter Checkland pioneered the development of such models, in what he termed, ‘Soft Systems Methodology’. For more on this topic, see, ‘Soft Systems Thinking, Methodology and the Management of Change’ by Happeren and Wilson.
Row 3: Logical. Logical process models are popularly shown in the form of swim lane diagrams, a technique pioneered by Rummler. Popular notations for such models include Business Process Modelling Notation (BPMN) and UML Activity Diagrams.

Lower 3 rows of Zachman column, ‘How’ – The Processes

The lower three rows of the Zachman framework are concerned with increasingly technical views of how the business processes are supported by IT.

These rows are of interest primarily to technical strategists and architects and to those roles that are responsible for making purchasing decisions on systems software and hardware.

The business analyst should be able to contribute to discussions on IT strategy for technical support of business processes. The business analyst should therefore have, at least, an appreciation of the technology. They need to be aware of what technologies are available, e.g. for automating workflows.

Each process interacts with other elements

Processes do not operate in a vacuum — Process do not operate in a vacuum

The Zachman model demonstrated how business processes interacted with other architecutural elements. We reflect this in the accompanying diagram

A business process:

Creates, views, modifies and deletes business data
Is constrained by business business rules
Operates across locations and organisation units
Is the responsibility of particular stakeholders
Is triggered according to business timings
Has a rationale in terms of its support for business objectives

Core and support processes

Many of an organisation’s business processes provide routine support.

A critical subset are strategically important and deliver value created by a business. These are the core processes. The goals of these processes are crucially linked to the strategic objectives of the organisation.

All organisations must continually find ways to incrementally improve business process performance. Many such approaches to improvement are inspired by ideas from Japanese manufacturing sectors. See, for example, the publication, ‘This is Lean’, by Modig.

If any core business process is not effectively supporting the business strategy and goals we may need to take a more radical approach to improvement. Radical improvement was the subject of Hammer and Champy’s ‘Re-engineering the Corporation‘ some years back. That approach spawned a number of later ideas and approaches.

If there is a change to the environment in which the organisation operates, prompting a need to change strategic goals and approach, then one or more core processes will probably need to be changed.

Terms of reference for a better service

Why terms of reference?

Terms of reference are a key tool of business analysis. They are a vital control for:

projects
activities and work packages within the project
project governance and management
project team members

A useful mnemonic for possible elements of a terms of reference is BOSCARD. It provides a framework for a terms of reference and is the basis of a contract between the business analyst and other project team stakeholders.

BOSCARD

BOSCARD stands for:

Background: What is the background to this project? What is the problem to be solved or the opportunities to be realised? The business analyst is directly concerned with identifying the business problems and opportunities
Objectives: What are the objectives for this project and for the product or service that it will create? Objectives should relate to the statements in the ‘Background’ about problems and opportunities. Try to relate the project and product objectives to the higher level corporate objectives that this project will support through the provision of its products and services. Objectives can also be linked to the anticipated benefits that this project will realise.
Scope: Define what is IN and what is OUT of scope for the project or project activity. Scope can be represented graphically by using a context diagram: see below.
Constraints: Identify constraints such as time and money applicable to the project or project activity. Constraints may also define the format and standards applicable to the deliverables; e.g. ‘Apply in house standards when creating user stories’.
Authority: Identify the hierarchies of authority that govern the project or project activity.
Resources: Identify the people with a role within that project. For business analysis related activities, identify the people and the roles that will work with the business analyst. Also identify any non human resources that will be required, e.g. development tools, rooms, equipment, software licences, etc.
Deliverables: What the project or project activity is supposed to create. The business analyst is typically responsible for delivering the requirements. Other business analysis deliverables include problem analyses, analyses of business processes, business information (data and concepts), business rules, benefits, costs and risks

There is a natural partnership between the project manager and business analyst. The BOSCARD represents a form of contract between the project manager, the business analyst and other players in the project or project activity.

Context Diagrams

Context diagrams are a great way of demonstrating, discussing, agreeing and reviewing the scope as defined in the terms of reference. Context diagrams may be used show any of the following:

Scope of a project
Scope of (sub) activities within the project
Scope of a role or a project team member

The square at the centre of the context diagram can represent any of the following:

Organisation or organisation unit
The product or service that the project intends to create
A project
A project activity within an overall project
A project role or project member; this can show communication channels to and from other roles

The smaller squares surrounding the central one are referred to as ‘externals’ or ‘external entities’. They represent bodies that the central unit communicates with. What they are in any particular case will therefore depend on what the central unit is supposed to represent, e.g. organisation, product, project or team member. In these different cases, the externals could be:

External organisations such as customer and suppliers
Internal organisation units which will have to communicate with the project team
Computer systems which the product to be delivered will have to interface (inter-operate)
Work units that the concerned role or team member must communicate with

Who Writes the TOR?

The terms of reference are normally created by relevant sections of the project team.

For business analysis activities, the team may include:

Project sponsor
Business analyst(s)
Product manager / owner
Representatives of the concerned business areas
Representatives of the architecture, design, development, implementation, test and release management teams
Project manager
Representatives of the externals

Terms of reference for a role or an individual may be written members of the role or by the individual concerned.

Agreeing the TOR

Terms of reference must be agreed by all concerned parties.

Requirements analysis and modelling

Requirements analysis

As requirements are discovered (elicited) and captured, they should periodically be analysed; they can be analysed for completeness, correctness, priority, release date, ambiguity, clarity, testability, achievability, cost, risk, scope, cultural feasibility, etc. This is true whether the requirements are captured as user stories, use cases, business tasks or any other format.

The requirements analysis process involves checking backwards with the requirements owners (e.g. product owner(s)) and forwards with the stakeholders who will use the requirements in some way, e.g. to design, build. test, release or administrate the required system.

In checking back (requirements validation) with the owners of the requirements, we are trying to ensure that the real business needs have correctly identified and defined. Consider the goals of the project as well as the overall goals of the organisation, the business case, the priorities and the scope for the project; does the requirement respect these? Have the goals or the scope changed, perhaps with a change of sponsor for example? Do the requirements seem to be related to the original problem? Do we remember what that problem was? Have we identified and involved all of people and groups affected by the requirements?

In these reviews with business stakeholders, ensure that they really do understand the requirements as written. Is this what they wanted? The big question to ask is, ‘How will the requirements, as written, contribute to the solution of the original problem?’ This is the rationale for the requirement; it can sometimes be very difficult to get the stakeholders to clearly specify a rationale. If there is no rationale, the requirement needs to be dropped.

In reviewing the requirements with the people who will build or otherwise acquire as system that satisfies the requirements, we need to ensure that a system as represented by the requested requirements can be built and tested within the defined constraints. In the context of testing, and of development, we need to ensure that there are clear and unambiguous acceptance criteria. The obvious way of doing this is to have the requirements reviewed by the people who will be doing the building and testing; the architects, designers, programmers, testers and release managers.

A well constructed requirement should normally permit multiple solutions. Is this true of the requirements at hand or are they actually solution statements masquerading as requirements? If they are solutions, is this ok? Usually it is not.

That said, we also need to ensure that the required product can be developed within the constraints imposed by the business. Realistic costs can only be determined in the context of the design options, or potential architectures.

Assessment of requirements must therefore involve people with sufficient technical skills and experience to understand the likely implementation costs. If the organisation cannot afford the solution, or cannot justify that expense in terms of benefits, it is not worth continuing with the development.

If what is being requested is not feasible for any reason, e.g. technical complexity or cost, the designers and architects may be able to come to the rescue with an application of the 80:20 rule; e.g. make some changes to the requirements to be able to get most of what you want with less risk and cost.

Requirements reviews, as described here, should be done as early as possible. The earlier in the life cycle the problems are discovered, the quicker and easier it will be to resolve them. This increases the chances of achieving a workable solution first time. Obviously, just because it’s workable does not mean that it really will solve the business problem or will realise the opportunity; in the end, we just have to get it out there and see. This a justification for agile style developments with ‘minimum viable products’ and ‘failing fast’.

Analysis with Models

There are risks in relying purely on text to define requirements. Ambiguity is a problem. It can be difficult to assess completeness. One solution, or partial solution, to do these problems is to use models.

There are mixed opinions about the value of models, particularly formal models. One option is to use informal models, sometimes referred to as napkin models. These are easier for business stakeholders to create and can be less intimidating. Formal models however have more rigour; they are essential when we are intending to automatically generate applications and databases from models. Popular forms for formal models include UML and BPMN.

For Complex systems (with the capital ‘C’), there are other considerations in terms of value of models, but such highly specialist considerations are beyond the scope of this article.

Analysis and Prototyping

Another way of mitigating risks inherent in requirements defined as text is prototyping. Prototyping is popular but there are consequent risks such as the popularly quoted management of user expectations. Another risk is that we may suddenly find that we are no longer dealing with requirements but with solutions; as stated above, a well formed requirement should allow for multiple solutions.

When we are eliciting requirements, the prototype should be as minimalist as possible; the prototype should be used to encourage discussion about the real need.

When we are validating requirements, prior to purchasing a solution or starting system development, the prototype should be detailed enough to show what the system will look like. This gives stakeholders a chance to say, “Now that I’ve seen it, I realise that it’s not what I want.

Managing Expectations

Our analysis, including reviews, modelling and prototyping, should clarify everyone’s ideas and should give us confidence that we are on track to create what is really needed to solve the business problem or realise the business opportunity. Such clarity facilitates estimating the workload ahead and helps to set expectations and share a vision. All of this will be good news to the project manager and senior management.