One of the less fortunate sides of internet journalism is that, along with lines of thought you see merit to, you also have to talk about things you think are absurd, vastly overhyped or just not good in some fashion. I’ve never liked discussing requirements engineering, and the fact I have to do it twice this week just makes me a sad panda.
What is It:
Nobody seems to agree entirely on what requirements engineering strictly means. Wikipedia defines it as engineering and design based on enabling users to meet certain goals and enable them to accomplish certain tasks.
This differentiates it from other engineering mentalities how, exactly? You got me. In all my research of this concept, I have yet to see enough distinction in this concept to differentiate it from just common sense design and usability approaches as they should be handled.
What it Thinks it Is:
It seems to think it’s revolutionary for the sheer fact that in the design and engineering process, all the possible needs of the user in performing the tasks outlined are first and foremost what governs the design process and the final shape of things.
But, honestly, this is what all design processes with a user base and purpose in mind on the outset should be doing. So, this term is pointless, this differentiation is pointless. This whole thing is an exercise in wheel spinning, quite severely.
What it Allegedly Entails:
This process claims to be special in that the process is mapped out before design, and tested with target demographic users to get a feel for what needs they have, and how to do engineering of the design first and foremost to accommodate what the user needs.
This is usually done in sets in parallel, and the most common solutions among them are kind of “unanimous”, and any needs brought to light by different groups are then tested and retested through requirements verification and analysis.
Again, though, all this really adds up to is actually applying usability testing and user input the way we all should be doing. I’d love to point out where this particular methodology goes a step further in bringing this point home, but if such an aspect exists, I have yet to see it evident anywhere in my study of this.
Surely There’s More:
When I decided it was best to start by overviewing the process, I did that with the hope that researching the procedural aspects of the concept would reveal to me where this takes extra effort in meeting user needs as the primary goal.
My conclusion is that the term does need to exist, but not as a “different” methodology but rather as a way to describe focusing on user needs and requirements versus building a thing, and then tacking on “ease of use” and requirements needs after the fact.
I do suppose that too many designers out there make that mistake, and so a push for so-called requirements engineering mentality is justifiable. But it really doesn’t seem much like a method so much as a standard to reach, in as far as I can come to understand. Sorry this one wasn’t as upbeat and informative as I usually am, but what can I really say about something that doesn’t even seem to be sure, itself, what it is?