What is the Best Requirements method? That's a mighty big and difficult question to ask, for several reasons. Everyone has a different idea of "best", but also of "requirements method".
While I could try to analyze various methods according to various statistics, it would still only give a one-sided view on the subject. In addition I only know a few methods very well so that would leave out other methods.
A different approach, the one that we take here, is to ask you, the participant in the requirements process.
(more...)
Tags: survey questionnaire requirements
Filed under Requirements Management | No Comments »
Many courses and books on requirements will tell you that a good requirement describes the “what” of a need of a customer (or more generally, stakeholder). They will tell you that you shouldn’t write down the “how” (they call that ‘design’) because it pushes you in a technical direction and causes you to miss out on other good solutions.
That’s good advice in the sense that you shouldn’t restrict yourself to a solution if another solution satisfies the needs of a customer better. But when is something a design, and when is it a requirement? If you’ve thought about it, you realized that it is hard to draw the line. (more...)
Filed under Quality Assurance, Requirements Management | 3 Comments »
One of the most visible aspects of agility is making decisions when they are needed, and not making them all up-front, before any development work is done. But some decisions are needed before the rest of the project is executed.
An agile approach to software development has many advantages in most organisations. Because change is inherent, in business needs, in technology, in knowledge, in people, it makes a lot of sense to use a process that takes change as a given and embraces it, instead of trying to defend against it.
One of the tenets of agile approaches is to decide things as late as possible. At the same time, we want to make software that people will use and like and that has real value to them. And sometimes these two goals are at odds with each other.
Filed under Agile, Requirements Management | 2 Comments »