Bruce Crozier
Business Software Analyst
Applications
Design
Too
often applications design is left to the user and the programmer. With all due
respect, the user typically has not had the breadth of experience to see
possibilities and potential pitfalls in design solutions. And they lack the
technical knowledge to understand the possibilities and limitations of the
code. With all due respect, the programmer typically does not have the business
experience to understand the root needs of the user and the needs that the user
may not be expressing or even aware of. With all due respect, that’s why the
profession of software analyst exists.
Good
business applications design requires a solid understanding of business practices.
People who design a business application without understanding the business
need behind it tend to design as though the scenario (“user story” in today’s
jargon) is carved in stone. Sometimes all or part of the need is, indeed,
immutable, such as in tax calculations or vendor rebate reporting. But many
times what the user needs today is likely to be different tomorrow. What seems
like a simple warehouse location system might need to accommodate RF or bar
coding down the road. If the file system is designed without considering that
possibility then much time and money could be wasted. If the user desires a
pricing calculation based on the volume of units sold, has the designer allowed
for the possibility that dollars sold may be the criteria in the future? These
are, of course, very simple examples of potentially far more complex
considerations recognized by an experienced analyst.
Another
common mistake is to design for exceptions. Users typically outline the ninety
percent plus scenario of their need first but then go on to lay out scenarios
that are exceptions. Sometimes these scenarios represent only a tiny fraction
of the need. That does not minimize the importance of the requirement for the
application to be able to handle that scenario. In some cases, it may actually
be the driving force for the development project in the first place. But the
design needs to be weighted so that the user or the system isn’t wasting
resources going through steps that are only required in the exception.
These
are the types of things an experienced business software analyst should bring
to the design process. A good design cannot be successfully realized, however,
unless it is communicated to the programmer clearly and in great detail.
Unfortunately, there is no software that will read a general specification and
spit out all of the answers to the questions the programmer will ask—assuming
they think to ask them. It takes a certain aptitude to be able to think through
all of the logical possibilities of a design. Good programmers have this
ability but the designer needs this as well, or the programmer might answer
their own questions. If they get that far. Sometimes the design is so poorly
thought through that halfway through the coding process the programmer hits a wall
that they can’t code over, and the whole project must start over. The expense
of a lack of detail can be severe.
Design
is the part of software development that I enjoy most. It allows me to combine
my business experience, my aptitude for logical systems, and my communication
skills, and be creative. Much of what I do involves looking for mistakes and
fixing them after they’ve caused problems. Design is an opportunity to prevent
mistakes before the fact.
