Comments on: Let the UI drive the requirements http://www.dancingmango.com/blog/2007/05/24/let-the-ui-drive-the-requirements/ For more than a decade Marc has been a passionate advocate of placing the customer at the heart of business, working with clients in finance, retail, government and entertainment sectors, helping them craft compelling cross channel customer experiences. Marc champions lean and agile approaches for making customer driven innovation happen. He brings design thinking and creativity to clients, engaging across the organisation with a focus on delivery as well as ideas. He is currently writing a book on Agile Experience Design to be published this Autumn. Sun, 25 Sep 2011 23:33:07 +0000 http://wordpress.org/?v=2.9 hourly 1 By: Prashant http://www.dancingmango.com/blog/2007/05/24/let-the-ui-drive-the-requirements/comment-page-1/#comment-27026 Prashant Thu, 24 May 2007 13:11:59 +0000 http://www.dancingmango.com/blog/2007/05/24/let-the-ui-drive-the-requirements/#comment-27026 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. 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.

]]>