Articles
These are some of the articles that we have written or borrowed (with permission) on requirements and software development topics.
This is the sixth article in the series that explains the thinking behind the Volere requirements techniques. This one looks at the most granular level of requirements.
Tim Lister sets down the skills, characteristics, and talents of the perfect business analyst.
This is the fifth article in a series that explains the thinking behind the Volere requirements techniques. Subsequent articles will explore various aspects of applying these techniques in your environment.
It appears that innovation is hard to do. It is not, but coming up with the good ideas is the easiest part.
This article was selected by IEEE Software magazine as one of the Top Picks for influential articles over the 25 years of IEEE Software.
This is the fourth article in a series that explains the thinking behind the Volere requirements techniques.
Requirements for Managing Requirements Cutter Consortium.
This report works through the Volere requirements knowledge model. This illustrates how some degree of formality opens the door to making choices appropriate for each individual project and leads towards the ability to reuse requirements.
This is the third in a series of articles on the Volere requirements techniques and explains how the business analysts translates a business need into a system scenario.
This is the second in a series of articles explaining the Volere requirements techniques.
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.
How do you know whether the requirements specification is fit for its intended purpose? How do you know whether it is a good specification?
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.
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.
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.
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.
