Building a system is a complex task, somewhat like building a bridge. It is unfair to ask a user of a bridge (drivers and pedestrians) to design what a bridge would look like. Likewise, it is not prudent to ask users of a system to design what a system’s UI would look like. We’ve all driven and walked across bridges, but unless we are civil engineers, we wouldn’t know what structural specifications are required to build a bridge. It is also the case that system users cannot always visualize what they want, until they see what it will look like. Many “theorists” in the requirements management world write extensively about requirements documentation via use cases and such. It is important to have requirements documented. It is equally important to have UI mock-up’s that have been “test-driven” by the system’s user community. Ideally, the mock-up’s should be “working” UI’s. That is, the users should be able to click links, buttons, etc. and see the outcome, such as confirmation pages. Bottom line, requirements should never be baselined without UI mock-ups being baselined as well.
Comments
I was just having a discussion with Brian Rosenthal this morning about
this. In our circumstance, we actually have a formal JAD (Joint
Application Development) team, made up for client representatives and
developer representatives, so that together requirements can be
established (discovered?) while the feasibility of proposed
requirements are then quickly considered, discussed, and then either
approved or denied (or tweaked). But I am, personally, with you
Chanath -- customers know what they want in regards to business
problems and user experience, but not object models, Java interfaces or
Database schemas. Ha ha that thought makes me laugh. And something
that goes hand in hand with collecting the user experience aspect are
solid UI mock-ups that emulate requirements. Without them, and you
could meet every requirement and still fail to deliver a product that
the users would want to use.
According to an excerpt from IEEE Recommended Practice for Software Requirements SpeciÞcations on "prototyping" (user interface mockups fit into this category), you are right on the mark. Here is what it says about prototyping:
I once read an article (and darn it I can't remember where it was) that said something to the effect of "customers don't know what they want--get over it."
The thrust of the article was that users operate on IKIWISI - "I'll Know It When I See It" - and all the discussion and all the prose and all the UML in the world will not mean a thing to most users. All that matters to most users is pixels on a screen.
The author was not saying you should not do the UML and discussion and prose -- but that you should not expect the users to get into it, and you should definitely not sit back as a software developer and say "I need requirements" and expect anything rigorous.
The article was saying -- and you seem to be saying as well -- that it's our job as IS professionals to understand our customer's needs and propose solutions to them on their own terms. It's not reasonable to expect them to understand what we need to write software and to hand us programming specs on a silver platter.
Post new comment