• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Are UI Requirements Software Requirements?

User Interface design is often assigned responsibility for look-and-feel. While I understand the importance of UI design, I am highly dissatisfied by its reliance on “heuristics” and, frankly, the uneven quality of those who profess expertise in the subject.

I submit that UI needs a haircut — that we should limit the scope of what falls into the realm of UI. I think look-and-feel might be a better overarching category, but even that is too broad. The underlying flaw is that practical UI is rarely formally tested and less frequently permanently linked to business objectives.

The next revolution in requirements will be traceability or — as I prefer to say — connectivity. To me, traceability implies a one-way progression from objective, to requirement, to specification, to development, to test, with each transition as a one-way gate, during the passage through which one must abandon all hope of returning. Connectivity, on the other hand, is the continuous, two-way link between

  • Business Objectives
  • Marketing Objectives
  • Functional Requirements
  • Development
  • Testing
  • Usage

Such that any shift in one puts pressure on the others. It is connectivity that provides for not only rapid development, but presents the possibility of instantaneous development. Being able to modify a product this way depends wholly on being able to pick up the thread and see where it tugs. Before this was left to intuitive judgments, which were imprecise and incomplete leading the product into an inevitable “slow drift” away from the original business objectives.Imagine that you wanted to capture a certain “feel” as a marketing objective…

Why? Well, let’s say that you believe “slippery” is the feel that would increase sales for a certain segment (amphibian programmers, say). If you can make that testable connection, even if it proves that there is no correlation, you have created an underlying framework to test your inference.

Even the softest requirements should be “connected” to business goals. If creating such connections seems like too much trouble for the requirement, chances are you’re not dealing with a requirement in the first place.

No comments yet.

Leave a Reply

Your email address will not be published. Required fields are marked *