Is "Requirements Engineering" a Misnomer?

James Robertson questions use of the term “Requirements Engineering” on the Yahoo Requirements Engineering Group .

It is not engineering. It became known as “engineering” because some academics wanted to be seen practicing a discipline that was a “hard” science. However, talking to stakeholders, understanding what they want, reading between the lines of what they say, inventing features, persuading developers to build the specified product are not engineering subjects.

When I first read his comment, I thought, Roberts was being a bit nit-picky and that it is basically just a question of semantics. Granted, this isn’t the type of topic that will help you do your job better, but, given some more thought, I chose to post about it because I think it’s interesting from a philosophical perspective.

Although I’ve used the term “requirements engineering” myself, I’ve long thought that business analysis is more an art than a science. The question is somewhat related to a topic I addressed recently in questioning whether a good BA needs strong technical or domain specific skills to be successful.

In my view, a BA’s most important competencies are soft skills, like the ability to facilitate knowledge transfer. to establish and mantain relationships, to articulate ideas clearly through speech and writing, to effectively manage meetings.

When you think of an engineer, hard skills such as the various science and technology disciplines come first to mind. It’s easy to see where one could question whether the BA has a place in the engineering tent, and I actually see that as a positive. In fact, I think that anything that chips away at the conception of business analysis as exclusively IT work is probably a good thing for the future of the BA role. I’ll describe why I think that way in my next post.

Do you have a problem with the term “requirements engineering”? Do you even care? How about the hard skill/soft skill comparison? Think that’s a fair assessment? As always, I’ll look forward to your comments on this.

Tags: analysis, Elicitation, Specification

Category: Business Analysis