The UI is not even a product, system, or software requirement, which is what most people (mistakenly in my experience) think should be the subject of the requirements phase.
A UI is part of the physical product, system, or software design which details how the product, system, or software requirements will be implemented. Other parts of the physical design tend to be more technical, such as program and database specifications. Thus the physical design often is called the technical design.
In my opinion, regardless of the methodology being used, designing a UI is not appropriate while one is defining requirements. That said, designing a UI is one of the most common activities carried out in the name of requirements definitions. When folks think the UI design is a requirements definition deliverable, they almost certainly won't have accurate business requirements and probably won't have product/system/software requirements either. However, they are very likely to have creep.
For reasons that continue to confound me, even and often especially those who seem to know a lot about software development feel compelled to say something to the effect: Sure, that's well and good; but wouldn't a UI be helpful anyhow for defining requirements?
Let me reiterate. The product, system, and software you intend to create—including its UI—are NOT the user/customer/stakeholder's requirements.
Instead it's your presumed way of satisfying their requirements. Focusing on the UI, system use cases, prototypes, visualization, and other forms of product/system/software solution description in the name of requirements makes virtually it certain that the developers (which include analysts and testers as well as programmers) will not be paying sufficient attention to what is really needed.
In medicine, prescription prior to diagnosis is malpractice. The UI is a prescription; and thinking it will lead to proper diagnosis is misguided. The fact that many people believe it, including many supposed authorities, doesn't make it so. Just because most people believed the earth was flat prior to Columbus in 1492 didn't make it flat.
UI design has a role, as part of design, after the requirements are known accurately. The same is true for prototyping, which typically focuses on the GUI and shortcuts the guts. Requirements are mainly addressed in the guts, not in the GUI, which is why prototyping's value often is negligible for confirming, let alone defining, requirements.
Dig deeper on Gathering Software Requirements Use Cases
Related Q&A from Robin F. Goldsmith
Requirements management and the requirements process are sometimes used to mean the same thing, but customers should be aware that there are ...continue reading
To prevent feature creep, product requirements should satisfy the actual business requirements. Creep can occur when product requirements are ...continue reading
Testers often complain that software requirements specifications are too vague, but verbose requirements can have the negative impact of being so ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.