Here is a twist to the response to the question – what exactly does a Requirements Engineer do? I have seen quite a few responses that range from the funny to the factual to downright confusing. At a basic level, we define what software is supposed to do. But that is like saying a doctor dispenses medication or a tennis player hits a ball. They are both factually correct but do not come anywhere near capturing the essence of what they do.
So then, what captures the essence of what we do? I like to think we are agents of change in an organization. I do not say this flippantly so that it gives me a sense of self importance and imaginary orchestral music starts going off in my head as I traipse from one elicitation session to another, leaving glorious change in my wake.
The fact of the matter is that every project that I have ever worked on has envisioned significant change to the operations of the entire company or large parts of it. The driver for the change has been a combination of external forces that necessitated it or came from an internal impulse to do something better. A key component to enable the desired change to take place was the software being created to support this brave new world.
As Requirements Engineers we are at the forefront of that change. Long before there is any software, we are there with the users, helping them describe this new world, justifying their proposed actions, quantifying the desired outcomes and defining the metrics we will use to measure success or failure of the effort.
We then work with them to take the higher level goals or objectives and break them down into smaller actionable chunks. We help them sort out who does what and what needs to be automated. We keep drilling down layer by layer till we eventually arrive at a single statement – the requirement – that defines in simple, concrete, measureable and unambiguous terms what a small piece of the software should do.
Through all this, we are communicating and interacting with a dizzying array of people from every part of the company with different skills, cares, concerns and needs. We explain to them why we are creating new software, what it is expected to do, when it is likely to be available and the benefits thereof. We are the messengers of this change and also, paradoxically, the chroniclers as well.
Our success or failure is tied in large part to the message of change we bear, how well we convey it, capture it and disseminate it. For better or worse, we are the agents of change.
So the choice is yours the next time you are confronted with the question – what do you do? You can tell them you spend your day defining what software should do. Or you can tell them what you really do – that you are an …
