Reading : Requirement Engineering.

Some very useful info found today~~

"Requirements Engineering (RE) is a set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real-world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software-intensive technologies."

‘Requirements’ suggests that there is someone out there doing the ‘requiring’ – a specific

customer who knows what she wants. In some projects, requirements are understood to be the

list of features (or functions, properties, constraints, etc.) demanded by the customer. In

practice, there is rarely a single customer, but rather a diverse set of people who will be affected

in one way or another by the system. These people may have varied and conflicting goals. Their

goals may not be explicit, or may be hard to articulate. They may not know what they want or

what is possible. Under these circumstances, asking them what they ‘require’ is not likely to be

fruitful.

‘Engineering’ suggests that RE is an engineering discipline in its own right, whereas it is really

a fragment of a larger process of engineering software-intensive systems. The term

‘engineering’ also suggests that the outputs of an RE process need to be carefully engineered,

where those ‘outputs’ are usually understood to be detailed specifications. It is true that in some

projects, a great deal of care is warranted when writing specifications, especially if

misunderstandings could lead to safety or security problems. However, in other projects it may

be reasonable not to write detailed specifications at all. In many RE processes, it is the

understanding that is gained from applying systematic analysis techniques that is important,

rather than the documented specifications.