But we collect requirements all the time, right? Every
time we build a software system. So how do people
cope with these difficulties? What are the best practices?
In practice, developers or analysts usually identify a whole bunch
of requirements. Sometimes the easiest and most obvious ones. They
bring those to the stakeholders, and the stakeholders have to
read the requirements, understand them, and if they agree, sign
off on them. And the problem is that in general,
these requirements documents are difficult to read. They are long, they
are often unstructured. They typically contain a lot of information. And
in general, they are not exactly a pleasant read. So what
happens is that often the stakeholders are short on time, overwhelmed
by the amount of information they're given and so they give
in to the pressure and sign. And this is a bit
of a dramatization clearly but it's clear that what we are
looking at is not an ideal scenario. Clearly this is not
the way to identify the real purpose of a software system to
collect good requirements. And since one of the major causes for project
failure is the inadequacy of requirements, we should really avoid this kind
of scenario. We should follow a
rigorous and effective requirements engineering process instead.