Business Analysis and Screen Design: Why and How

by Jason Questor
Founding Partner and EVP Learning Systems

The distinction between requirements and design specifications is a frequent point of confusion for many businesses implementing a business analysis practice.  Where does one leave off and the other begin? This week, while teaching a course on this very topic to one client, another sent me an email asking the same question — “Do business analysts actually get involved in helping to design screens, including the naming of screen components?”  The short answer is yes, but with important qualifications.

An important aspect of business analysis is the formal elicitation, organization and documentation of requirements.  Requirements (needs, objectives, goals) describe the nature of a problem or opportunity, not design specifications, which focus on how you will address and solve the situation. For example, a need may be to satisfy thirst. There are many ways to resolve this (water, juice, soda, etc.). A significant and common issue in business analysis occurs when stakeholders do what is called “solutioning” – telling the business analyst what they want to solve a problem — “I need a Coke®”. What is the actual need here – to satisfy thirst, to cool off in hot weather, to get a quick energy boost from the sugar and caffeine?  In IT projects, solutioning can take the form of saying that the requirement is to purchase a particular product, rather than describing the nature of the need, which could be “I need something that will allow me to track and manage the cost of contracted work”.  Describing what you think is the answer without addressing the question raises the potential of spending money on a solution that will not address an undiscovered need.

An important part of requirements for computerized solutions focuses on the user interface, known as the Presentation Layer. Business analysts do indeed work with users to uncover their requirements for screens and screen components (data entry fields, data retrieved and displayed from databases, on-screen calculations, the labels attached to screen components, etc.) but this is all from the point of view of what is needed, not how it may eventually appear (design).  For example, a user may say “On this screen I need the following information included” and work with the business analyst to the extent of creating screen mock-ups and definitions for screen components – “I need to display the customer’s account balance.  Let’s call it CUSTOMER ACCOUNT BALANCE and the computer will access the database and display that number here.”.

The caveat is that resulting screen mock-up is a requirements prototype not a design prototype. The actual appearance of the final solution may be different based on organizational standards and human factors considerations. Also, the names attached to specific screen components by software developers may be very different due to technology considerations and existing legacy code.  What must be stressed here is that, from the requirements point of view, things like field type and field naming must make sense to the business user, using business terminology, not tech-speak. That same field of CUSTOMER ACCOUNT BALANCE may be referred to as FIELD-2347 by developers and in the actual computer code. It would make no sense to describe it this way to business users, although many failed requirements documents do exactly that, leading to confusion and anxiety in signing off on requirements documents.  Ironically, since the early 1960’s software developers have been urged to use “meaningful data names” (to the business), but even in 2012, that is often not the case.

From Strategic Business Analysis: Building Business Value ©2012 Jason Questor. Jason is founding and current President of the Toronto Chapter of the International Institute of Business Analysis, and writes and speaks extensively on the subject.

ACHIEVEBLUE course BA708: Integrating Use Cases into Application Level Libraries includes extensive coverage on how business analysis practitioners work with users to create effective and efficient user interfaces.