Requirements Engineering

I have often been asked by many of my non IT colleagues about what I do for a living. And when I tell them what I do, it often makes no sense with anyone. When it comes to IT, the most that the layman can follow is either writing the code to develop applications, or maybe the bit about testing the application. And while requirements analysis is an integral part of software development, it is considered as one of the less glamorous cousins of the technical architecture designing or even the development. The BAs in a project are considered as talkers who do nothing else but talk, and if any project needs to cut costs, its generally the BA who faces the axe. After all, anyone can talk...and thereby gather and analyse the requirements.

So I was quite happy to come across this white paper online today.

While it says exactly what I do for a living, the bit which impressed me the most was the problems that I face during the process of requirements engineering. Here is that excerpt which talks about these hurdles, and which science to approach to overcome those:

1) Cognitive psychology provides an understanding of the difficulties people may have in describing their needs. For example, problem domain experts often have large amounts of tacit knowledge that is not amenable to introspection; hence their answers to questions posed by requirements analysts may not match their behaviour. Also, the requirements engineer may need to model users’ understanding of software user interfaces , rather than relying solely on implementers’ preferences.
2) Anthropology provides a methodological approach to observing human activities that helps to develop a richer understanding of how computer systems may help or hinder those activities. For example, the techniques of ethnomethodology have been applied in RE to develop observational techniques for analysing collaborative work and team interaction.
3) Sociology provides an understanding of the political and cultural changes caused by computerisation. Introduction of a new computer system changes the nature of the work carried out within an organisation, may affect the structure and communication paths within that organisation, and may even change the original needs that it was built to satisfy. A requirements gathering exercise can therefore become politicised. Approaches to RE that address this issue include the “Scandinavian” approach, which aims to involve in the requirements definition process those most affected by the outcomes.
4) Linguistics is important because RE is largely about communication. Linguistic analyses have changed the way in which the English language is used in specifications, for instance to avoid ambiguity and to improve understandability. Tools from linguistics can also be used in requirements elicitation, for instance to analyse communication patterns within an organisation.

Requirements Engineering must concern itself with an understanding of beliefs of stakeholders (epistemology), the question of what is observable in the world (phenomenology), and the question of what can be agreed on as objectively true
(ontology)."

Interesting!