Well, I’d slotted a spot to talk about the benefits of requirements engineering when I actually held out a slight bit of hope of finding something to actually make it actually be something special. I mean, I do fully admire a mentality of designing from the ground up with the purpose of making a construct that performs the tasks to a standard required by the users, and through interaction methodologies that bend to their needs, and not the other way around.
Of course that’d be beneficial. But, we come down to problems with terminology, because when you point out a specific term like requirements engineering, you’re promising that it means something extra special. When it comes to the mentality that represents, there’s a problem inherent to that.
Well, the idea isn’t a bad one, but the truth of the matter is, requirements-based design is what any good design team should be doing to begin with. So as a term to describe “proper way of thinking” versus the improper tacking on of stuff to make it more user friendly after the fact, it does work.
But, as a specific new kind of methodology, it doesn’t hold up. In looking into it, I and my colleagues have discovered that beyond the basic idea of “what the user needs is what shapes the design from the beginning”, there’s nothing further or substantial about the philosophy associated with the literal use of this terminology.
Further, what information is out there, even on clinical sites, says a whole lot of nothing beyond that core concept. So, when I talk about the benefits of this, I’m going to be talking about the benefits of user-first thinking in general, because this term doesn’t frankly mean very much. At least not yet.
This term is probably getting so much momentum just because what little it does stand for on its own goes against the grain of conventional, very bad approaches to engineering for public-use designs. A purpose and set of tasks for something to perform to achieve this purpose is usually all that goes into initial inception of a design, in technology.
When user needs or requirements are discovered, modifications, patches and other surface polish is haphazardly placed onto it after the fact, causing the user-friendly interface and the very different internal mechanics to often be at odds, or hinder one another.
When you first envision your design with the context of what the user needs it to do, how they need it to behave, and the demands they and their most common devices will place upon it, you have a much better roadmap to design, from the ground up, a system that completely complies with these needs. That removes the problem of two disparate layers not wanting to play nice or agree on things.
It also helps stop inherently bad ideas from getting far enough along to incur wasteful costs for abject failure. If Microsoft and Apple would actually adopt some added requirements engineering mentality, then disasters like Quicktime and Windows 8 could have been averted because right away, they’d discover the designs don’t work for actual human beings. Better yet, the first design worked out would never have been the ones they have to begin with, as user requirements are a primary litmus for all things that go in.