Parliament Watch Belgium
A debate graph contains the requirements for and steps towards realization of the Parliament Watch Belgium initiative. It uses the Volere Template and the implementation is worth seeing.
From Renaud Phelizon
Renaud Phelizon, senior consultant at Arismore Paris has kindly agreed to share his experiences in combining the Volere Requirements Techniques with the Togaf framework. The following is the talk that Renaud presented at the Open Group conference in Cannes. Download a PDF of Renaud’s presentation
Volere Case Study from: Bartosz Andrzejewski , Systems Analyst
The project: a Knowledge Management system. It consists of tools for knowledge contribution, verification and search. It interfaces several adjacent systems.
The industry: Provider of infrastructure for telecom carriers. Due to confidentiality agreement I cannot divulge the name of the client.
There was one, neverending, constant issue between the company and its supplier:
Is this a Change Request or is it a bug?
‘We found a bug’ – the company claimed
‘This is a change request’ — the supplier answered
Software specifications were created by the supplier . I was astonished, that specifications didn’t contain diagrams, mockups, nor other models… Usually just plain (although chaptered) text…
It reportedly had occurred in the past, that the supplier’s IT-specification‘s content was copy-pasted from the client’s high-level business requirements specification.
Introducing two basic artifacts at the very beginning clarified a significant percentage of controversial areas:
- Use cases were broken down into UML Activity Diagrams
- Mockups of screens became mandatory element of design spec, where user-computer interaction was required
And then, the techniques contained in “Mastering the Requirements Process. Second Edition” brought aid.
- From the context diagram we were able to derive flows of information.
- From the flows of information we were able to derive activity diagrams for Product Use Cases.
- From detailed activity diagrams analysis we were able to derive atomic functional requirements
- Screen mockups — this led to reveal need for defining speed & latency requirements
At the outset, requirements were only stated. The rationale and fit criteria came later. Introducing the entire Volere methodology in one step would have been a shock. And — in fact — a wrong step. Remember about Pareto principle: removing 20% of causes are able to remove 80% or problems.
Nowadays, the supplier has been swapped with a reliable one.
The project changed:
- The binding requirements are gathered in a dedicated software database, not in MS Word.
- They are atomic requirements.
- Disputes about “a bug/a CR” disappeared.
- Traceability has been introduced — export of requirements from RM software to QA software
- Since fit criteria have been introduced for performance requirements, there have been no quarrels between our Service Manager and the supplier like: “It works slowly” — “It works well”.
Hint: when creating a fit criterion for speed&latency requirements on worldwide-available systems, always include info about the location, where the test shall be performed. The same system will react with different latency in the location, where servers are located and on the other side of the globe. Defend from being accountable for poor network infrastructure in some countries.
Volere template in fact is a checklist. You can always have it to hand and verify with various stakeholders, whether anything was skipped or neglected. During my jobs in various companies I met the common situation, that very important stakeholders consciously neglect non-functional requirements.
Next Volere artifacts are pending introduction.
One can ask, whether after the introduction of above-mentioned Volere artifacts and practices, there is a need for improvement of requirements engineering and management.
Of course. There always is. Start from suppressing customer’s/client’s designing spree. How?
I wouldn’t ask, If I had a silver bullet for it.
From Desiree Purvis, Senior Business Analyst, Bank of New Zealand, Wellington, New Zealand
I’ve been working in the business analysis profession for (gulp!) over 18 years. Like many of my peers, I fell into in the role, having started as a programmer first. There was very little formal training in my early career. Many of the techniques I use have been picked up “on the job” – I generally take a “pick ‘n’ mix” approach, matching the technique to the business need.
Although I haven’t used the Volere Requirements Process end-to-end “in anger”, in my humble opinion it is the most complete end-to-end methodology for elicitation, documentation, analysis, and communication of requirements. What Volere provides you is the means to deliver consistent, unambiguous requirements that are traceable, testable and complete.
However, calling it a methodology is a bit of a misnomer. One doesn’t have to follow the process pedantically – the various components can be used individually, or collectively, and/or in conjunction with other techniques, depending on what is required for that project. The components provide you with a great set of tools to ensure you’ve covered all your bases. In my previous consulting role. where I worked for various clients, and in my current role, that really suits my style. For example, I have used the Specification Template as a sort of “checklist” to develop a product description document (for which we didn’t have a ready-made template). I often use scenarios to validate my business use cases. And I firmly believe that business context diagrams are a must for understanding and communicating the impact of change – to a system / process / whatever – on the organisation.
The structure of the Volere process has also been a godsend in terms of coaching BAs. Juniors I’ve worked with agreed that the role and tasks of business analysis made so much more sense after attending the Mastering the Requirements Process course. And intermediates and seniors that have attended have returned to the office enthused and inspired by Suzanne and James’ approach. I look forward to further developments in Volere and hope to contribute where possible in the future.
From Brett Greiner, Health Intelligence, New Plymouth, New Zealand.
This is a good illustration of using different models depending on the feedback from the stakeholders – Suzanne Robertson
I am contacting you to say that the Altiris workshop using the Volere requirements process worked very well. We already have the product called Altiris developed by Symantec Limited, which changed the approach. The business wanted an understanding of the business in how they were going to manage incidents logged by users.
This was a steep learning curve, but taught me very quickly how to apply the key aspects, especially around the Rich Picture then moving onto the Context Model. Everyone could visually see the scope and interactions of the business environment.
I then did the BUC of the main event, then started doing a BUC future, but that was not worthwhile, so it was decided we went to the PUC future state.
The SME wanted a diagram to understand the PUC in detail, as the PUC became overloaded as they were deciding the process as they went (and by the sounds of it, there was no standard process). In doing a single Activity diagram, I found that I needed to break the diagram up into smaller parts because the Activity Diagram was becoming circular rather than the typical start-to-end flow. The Activity Diagram was broken into smaller chunks because at specific activities a number of actions could have occurred.
From Valentina Miano, Information & Communication Technology, Eni, Italy
Eni is an integrated energy company. It is active in 77 countries, with a staff of 78,400 employees. It operates in oil and gas exploration, production, transportation and marketing, in petrochemicals, oilfield services construction and engineering.
In this complex scenario, ICT people operate in cooperation with the business areas to ensure the collection and qualification of requirements and the preparation of cost/benefit analysis.
To support these activities, we have applied Volere method.
We reviewed and adapted our template for the requirements document to the Volere method. We focused, in particular, on work scope, distinction between functional and non-functional requirements. We also use a lot of check-lists, and we find those very useful.
In applying Volere method, we found many benefits and also some difficulties. I have listed them here:
Benefits of the Volere method:
- It reduces risk of unexpressed and / or dissatisfied requirements
- It facilitates the work of the structures of delivery that can tap into this wealth of information and start from a well-defined context
- It reduces the risk of scope changes
- It facilitates the work of colleagues who have similar initiatives
- In some cases, the detailed analysis made it possible to start directly with the realization (skipping the feasibility study)
- It helps to “go back” to the business requirements in cases where the user directly proposes the solution.
- It requires great availability from the business, especially in terms of time dedicated to the business analyst.
- When we have to give a very quick response in terms of evaluation, or when we are gathering requirements for existing systems or low complexity projects, sometimes there isn’t enough time to fully apply the complete methodology. This means it must be applied with flexibility to favour the agility.
- It may happen that, even if concepts are known, terminology is quite different from the one we have been used to. It may also depend on language diversity. So it is important to assure internal circulation.
From Shamal Faily, Oxford University Computing Laboratory
Abstract: End-User Development has received a lot of attention in the research community. Despite the importance of Requirements Engineering in the software development lifecycle, comparatively little exists in the way of prescriptive advice or case studies on both Requirements Engineering and End-User Development. This paper argues that enduser developers can obtain practical benefit by adopting professional Requirements Engineering practices. We report on how these practices were fostered within a workplace environment and illustrate that evaluating the effectiveness of teaching such practices can lead to a better understanding of the relationship between End-User Development and Software Engineering in general.
This paper was presented at the 3rd International Workshop on Requirements Engineering Education and Training. It is copyright IEEE.
From Peter Doomen, Enterprise Architect, SD Worx, Belgium
Ten years ago, when I was a junior business analist, I attended a course by Suzanne Robertson. After the course, I began to use the context diagram and gradually mastered the technique to guide interactive workshops on all kinds of projects: from the development of payroll and HR software to the restructuring of the work in the HR department of one of our customers.
I cannot stress the importance of the context diagram enough. Often neglected by beginning business analysts, this simple diagram, if constructed together, makes it clear for stakeholders why they are in the meeting, what the problem is, and where the solution can be found.
Furthermore, the context diagram is the best way to start to describe the business process in a software-independent way. This helps people focus on the real problem without diving into premature solutions.
For me, the Volere method is unique in two ways: on the one hand, it might be the most flexible method for business analysis available: any business problem can be tackled this way.
On the other hand, the different techniques, templates and activities form a complete set. For new users, they start with the basics (context diagram, business use cases, product use cases, and atomic requirements). More advanced users can delve into stakeholder analysis, business information modelling and innovation techniques.
Last but not least, expert users will find out how to add their own toolbox to the Volere method. As an example, I found the following idea very useful. During a workshop about the current process for a certain project, lots of issues came up. I took a red marker and added a number to the to the corresponding arrow of the context diagram, one for each issue, and wrote the issue on a separate flipchart. Stupid as this sounds, it shows how powerful the Volere method is and what you can do with it during a workshop (see diagram).
An example of how to extend the Volere context diagram to show issues with the as is process (the example is fictitious).
After ten years, Volere is for me like a toolbox: I use the hammer pretty much every day, while the locking pliers only come out once a month or so. But when I need it, I know it’s there for me to use.
From T.R., Independent Consultant, Vancouver, Canada
As a consulting business analyst for information technology projects, I am normally brought on to a project at the initial conceptual stages. I am involved in the project heavily at the beginning and when the project goes into development, my input is to clarify requirements. As the project goes into test and implementation, I might be called to assist with test scripts and user training.
Projects I work on usually involve a lot of change in business process across multiple functional groups. We are focused on determining the business problem as it relates to the business drivers, and from there, the finer details of the project scope is identified. These high level requirements shape the project and once confirmed with the business, gathering of business requirements proceeds.
During the course of gathering business requirements, further business drivers, are identified. We discover project and business process issues, business and technology constraints, information about the business, the users, and their use of technology. We discover requirements that are out of scope, some of which end up being in scope.
In order to document all this information in a concise way, and facilitate the effective downstream documentation such as design, test and implementation documentation, a requirements gathering method and requirements template is required. Sometimes the requirements documentation is used as a communication tool with the business and requires sponsor sign-off, and other times it is used only within the project team. In either case, I like to use the requirements document as a single source of requirements and other information gathered for the project. If the project is very large, then the requirements document might point to other smaller documents that hold specific information (such as matrices about requirements, or single or groups of use cases, etc.).
I have been using the Volere template for many years. It provides me with a framework within which I can house all the information gathered on a project. It is organized in a logical way, and it is inclusive. I go back to the Volere template again and again whether to start a new template from the beginning, to incorporate sections from Volere into my client’s ready-made template, or I check in with the Volere template to spark questions I might like to ask to complete my investigations.
The Volere Template is organized in a way that makes sense to me and aligns with my own process of gathering requirements. I always start with the people (the users and other stakeholders), and what we already know for sure (facts and names). Then we try to define the domain and interaction between groups and systems (context). From there, we need to define each requirement in a way that is measureable and traceable. We want to remember to ask about performance and other non-functional requirements. And, we want a place in the document to note training, out-of-scope requirements and other project work breakdown details.
I am happy to report many successes that I can attribute to the Volere Template. Most notably, in 2004, in tandem with a requirements weighting method put forward by my teammate, I used the Volere Template as the basis for a systems integration project for the Vancouver Organizing Committee in preparation for the 2010 Winter Olympic Games. The project was put to tender and our team won the bid! The part I played in the win can be directly attributed to my passion and clarity in my proposed requirements gathering method and template – based on the Volere Template. As a side-note, the project from start to finish was a resounding success!
New users should not feel they need to use everything in the Volere Template. I would suggest the template be used as a starting point. Each project is different. For example, I work primarily on business system changes. I modify the template to include less technical elements. But for an infrastructure project, the softer business elements are unnecessary so I remove them.
As well, the Volere Template can be used with other methods. I often need to gather requirements as I also record and define user scenarios. I do this in a number of ways such as use cases and business rules, but I usually also incorporate useful sections from the Volere Template as well.
I like the Volere Template because it has everything – the method, instructions, and notation – in one document. I use what I need for a given project.