These are some of the articles that we have written or borrowed (with permission). We hope you find them interesting.                

Volere Requirements Techniques: an Overview    by Suzanne Robertson and James Robertson

This is the first article in a series that explains the thinking behind the Volere requirements techniques. Subsequent articles will explore the practicalities of applying these techniques in your environment. Download pdf.

Requirements Auditing: Is the Specification Fit For its Purpose?    by Suzanne Robertson

How do you know whether the requirements specification is fit for its intended purpose? How do you know whether it is a good specification? Read this..

The (Proto)type of requirements thinking at IAG    by Andrew Kendall

Andrew Kendall is a senior business analyst at Insurance Australia Group, one of the largest insurance organisations in Australia. In this article Andrew discusses an approach to Volere requirements gathering. Read this..

Volere Requirements: How to Get Started    by Suzanne and James Robertson

In response to many requests, we felt that it was time to produce a guide to how to make a start using the Volere approach to improving your requirements. Read this..

Stakeholders, Goals, Scope: The Foundation for Requirements and Business Models    by Suzannne Robertson

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. Read this..

Reusing Requirements — Taking advantage of what you know    by Suzannne Robertson

The aim of requirements reuse is to save time and effort and build better relationships by avoiding the duplication of work. Requirements reuse is the ability to benefit from requirements knowledge that has already been captured. This executive summary and the full report are available from Cutter Agile Project Management Advisory Service.

Know Your Goals    by Ian Alexander

Some requirements people talk about Goals only in the sense of 'vague, unachievable, high-level aspirations'; others seem to mean almost the same as requirements, while scenario and Use Case people say that every scenario has a Goal. So it's understandable that newcomers often get confused and avoid the whole subject. But a Goal has a definite meaning to footballers, engineers, biologists, and psychologists, and it is a meaning that is very useful in systems development. Download Word file

Project Sociology — identifying and involving the stakeholders    by Suzannne Robertson

A major success factor for any project is having the right people involved in the right subjects at the right time. Download pdf file

Eureka! How analysts should invent their requirements     by James Robertson

The traditional job of the requirements analyst is to talk to the user, to find out how he works, ask what he wants, specify what is required and have it built. But wait. There is something missing from that: we did not improve anything. We need to insert a step into the requirements activity that I call "invent something better". This is about how we might go about inventing something better. Download pdf file

Collaborate for Quality — using workshops to determine your project's requirements  by Ellen Gottesdiener

Workshop participants, sometimes called a task group, are productive because collectively they have the right mix of skills and knowledge to create the work products. Members of the task group act independently, relying on one another's knowledge, experience, skills and perspectives. Download pdf file

On Setting the Context — Some Notes     by James Robertson

Getting the right context is one of the earliest activities of the development cycle, and the one that has the greatest potential to cause serious problems if it is done wrongly. By setting the right context, the delivered product has greater user acceptance, as it fits neatly into its operating environment. There are a few conventions for setting context, which if followed, always result in a significantly improved product. Read this...

Requirements Fundamentals — the basis for effective testing     by Suzanne Robertson

We accept that testing the software is an integral part of building a system. However, if the software is based on inaccurate requirements then, despite any amount of testing, the software will be unsatisfactory. Instead of limiting our testing to code, we should start testing as soon as we start work on the requirements for a product. Download pdf file

Requirements trawling — techniques for discovering requirements     by Suzanne Robertson

When you try and discover requirements for any kind of product, the difficulties are more complex because the source of the requirements is not just one person, it is all of the people who are stakeholders in the project. And all of these people have their view on what is important. It makes sense to have a variety of techniques for discovering the requirements. download pdf file 410K

Requirements Management — a Cinderella Story     by James & Suzanne Robertson

Why do the business requirements and the final software product often have little in common? Some observations about why the real requirements for the product often go undiscovered. Read this..

The Top 10 reasons for not doing requirements     James Robertson

The ten top reasons that we have heard why people do not do requirements. Read this..

This work is copyright � 1995 - 2002 Atlantic Systems Guild, but may be adapted for your internal use provided copyright is acknowledged. Please let us know what you are using it for.

top of page