A Monthly Article from our Speakers
Current Article of the month
Stakeholders, Goals, Scope:
The Foundation for Requirements and Business Models
When we published the first version of the Volere requirements template (http://www.volere.co.uk) we identified stakeholders (sections 2 and 3), goals (section 1), and scope (sections 7 and 8) as the foundation stones for discovering the relevant requirements. Since then we have applied Volere on many projects in many different industries. This article summarises experiences in using the Stakeholder, Goal, Scope approach as well as providing some new guidelines for using a variety of business analysis models for discovering requirements.We use Volere (the Italian verb for to wish or to want) as the name for our work on requirements techniques, models, templates and services.
What to do First?
When we started to use the Stakeholder, Goal, Scope (SGS) approach to discovering requirements we found that we did not necessarily do things in the same order every time. People ask “ Should we do a stakeholder analysis first, or analyse the goals or try to define the work and product scope”? The answer was “it depends” – not a very useful guideline. On consideration we realised that in fact we do not do any one of these things before the other, we do them in parallel. This makes a lot of sense because discoveries about one will lead you to questions and answers about another. The diagram in Figure 1 summarises the Stakeholder, Goal, Scope trio.The Stakeholders define the human society that has some effect on the success or otherwise of the project. A project stakeholder is someone who gains or loses something (could be functionality, revenue, status, compliance with rules…) as a result of that project.The Goals define the success criteria for the project. They answer the question – how will we know if this project is or is not a success? The goals are used to guide the project and to help the project team make choices about where to concentrate their efforts.The Scope defines the boundaries of the investigation and the boundaries of the product to be built by the project. We have learnt that it minimises confusion if we build two scope models – one for the investigation and one for the product.
Figure 1. The Stakeholder, Goal, Scope (SGS) cycle explores and defines the requirements space.
Running an SGS Workshop
Our favourite way to run a Stakeholder, Goals, Scope workshop is to stick large sheets of paper on all four walls of a room. If you are lucky then you might have a room with whiteboards instead of walls. Make sure that you are well equipped with marker pens, post it notes, sticky tape, scissors, and, if possible, a digital camera. Now label each of the walls with one of the headings: Goals, Stakeholders, Scope, Other Things. Stick a copy of the Volere table of contents (http://www.volere.co.uk) on the Other Things wall to help to guide you.It does not matter which wall you start on and you can certainly jump from one to the other – it works much better if you do these things in parallel. The important thing is to explore each subject and then ensure that you can connect your findings. The following are some effective techniques for trapping your knowledge about each dimension of your project.
Ask each of the workshop participants for their interpretation of the main goal of the project by considering the Purpose, Advantage and Measurement (P.A.M)Ask each person to write on a post it note and stick on the Goals wall:
- A one sentence description of the Purpose of the project
- What is the business Advantage
- How would we Measure the business advantage
Stand together around the wall and get each person to explain their view and facilitate a discussion. The objective is to establish whether there is a common goal and what additional questions need to be answered.During this, and all the other exploration activities, have someone standing near each of the other walls and writing down any Stakeholders, Scope or Other Things onto the appropriate wall.
Stand around the stakeholder wall and analyse your stakeholders by drawing a stakeholder map (Figure 2). For each of the circles on the map, ask which stakeholders do we have to fit into this circle?
Figure 2: A stakeholder map helps to discover the appropriate stakeholders and identify their interests in the project.
Use the stakeholder analysis template (Figure 3) as a checklist to help youthink of all the appropriate stakeholders and to be more precise about what knowledge they need to contribute to the project.
Figure3: This is an extract of the stakeholder analysis template, it is downloadable from http://www.volere.co.uk
When you are standing at the Scope wall, you are focusing on defining the boundary of your investigation. In other words, what sort of information do you need from which stakeholders and how does it all fit together? A convenient way of expressing your scope of investigation is to draw a context diagram (Figure 4).
Figure 4: The Context Diagram is the basis for identifying the business events that you intend to study in detail, The precise scope is defined by the interfaces to and from the adjacent systems. Each of the adjacent systems maps to one of the stakeholders on the stakeholder map.
Exploring Other Things
During a Stakeholder, Goal, Scope workshop people will think of other points, subjects, ideas that are outside the purpose of the workshop but you do not to forget them.
Volere Table of Contents
PROJECT DRIVERS1. The Purpose of the Product2. Client, Customer and other Stakeholders3. Users of the ProductPROJECT CONSTRAINTS4. Mandated Constraints5. Naming Conventions and Definitions6. Relevant Facts and AssumptionsFUNCTIONAL REQUIREMENTS7. The Scope of the Work8. The Scope of the Product9. Functional and Data RequirementsNON-FUNCTIONAL REQUIREMENTS10. Look and Feel Requirements11. Usability Requirements12. Performance Requirements13. Operational Requirements14. Maintainability and Portability Requirements15. Security Requirements16. Cultural and Political Requirements17. Legal RequirementsPROJECT ISSUES18. Open Issues19. Off-the-Shelf Solutions20. New Problems21. Tasks22. Cutover23. Risks24. Costs25. User Documentation and Training26. Waiting Room27. Ideas for Solutions
That is why the “Other Things” wall is there. Suppose someone identifies a risk, or mentions an important security requirement, or has a design idea. Just write each one onto a post it note, tag it with the appropriate Volere contents number and the name of the person who raised it and stick it on the wall. Then, when you are ready to explore each subject you will have a starting point.
Organising the SGS Deliverables
The purpose of the SGS workshop is to provide a foundation for discovering and defining relevant requirements. You can test whether you have this foundation by attempting to partition the scope of the work into business events leading to business use cases. [Rob 1, Rob 2]. The business use cases provide the basis for building analytical models and defining the detailed atomic requirements.Everything that you produce during the SGS workshop provides the basis for discovering relevant requirements. and tracing them throughout the project’s life. By taking this systems engineering approach, all your project knowledge has formal connections and you can trace each requirement to the relevant stakeholders. To learn more about this approach start by downloading the Volere template from http://www.volere.co.uk.