Let the UI drive the requirements
Conventional approaches to building software applications start with a Big Idea. Someone needs (to define an application) “a program that gives a computer instructions that provide the user with tools to accomplish a task“.
Someone picks up the big idea and breaks it down into a smaller list of “requirements”, things that the application must do to fulfil the Big Idea. In conventional waterfall development Business Analysts will spend a while documenting the list of requirements in some detail – in agile approaches they will do it as they go in a far more “lightweight” manner. Maybe a technical architect will draw up a blueprint design of the solution. Regardless, soon the developers will start writing code. With either agile or waterfall the user interface usually only starts to emerge at this stage. Until then, everything is coded in words (and maybe some boxes and arrows showing flow). Only late in the process does the UI emerge.
Returning to that definition of an application, IT development seems to spend most of its time in the “a program that gives a computer instructions” world, and often looses sight of “provid[ing] the user with tools to accomplish a task”.
How about a different focus. Start with the user interface. Take the Big Idea and illustrate it. Draw pictures of what the tools will look like, how the user will interact with them. Sketch storyboards, wireframes, lo-fi prototypes, paper mock-ups, call them what you will. Use this as the primary requirements document, supported by explanatory text and detail where we required. These may be stories or use cases, but let the visual representation of the big idea drive the requirements rather than it being almost an afterthought. Start with the UI and specify the functionality from that rather than the other way round. After all, it will be the UI that the user uses to accomplish their task, not the computer instructions.
I dont think UI alone will give you the answer to the underlying details. Things that happen beneath the cover – well thats what they do.
Can you draw a user interface for SWIFT messaging between 2 banks ? YOu could, for argument sake, show screens with information updated by the SWIFT message on the user’s screen. However, not everything in that message is related to what the user sees. What about any validations etc or downstream processes ?
Obviously that was just an example and not very well though through. My point being that UI is just one of the tools to drive out requirements and should be used where feasible within the context of analysis. Process flows, flowcharts, activity diagrams etc give you a different mechanism for driving out requirements depending on how they fit within the problem domain.