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 Trish Reader, 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.