Whatever language(s) you happen to use for coding applications and services, there’s no doubt that you are among the world’s best it. You’ve got the skill, the talent, the insight, and the brains to write efficient, compact code that runs flawlessly.
But, from what program specifications or documentation are you building these apps? Call me a mainframe-era dinosaur, but not a line of code written until at least two processes happened.
First, a business systems analyst interviewed stakeholders and translated their tales of woe into a clear, logical, unambiguous, easily followed set of requirements. That’s essential, because users rarely know what they want. (You agree with that, right?) When a department pleaded with IT (still called MIS in those days) for a new report, the savvy business analyst knew to look beyond the report request for fundamental process shortcomings. Generating a report, after all, is merely treating a symptom, not the underlying disease. It wasn’t unusual — at least if you were fortunate enough to have a really good analyst — for that one report request to eventually become a system that simultaneously solved a dozen seemingly unrelated problems.
Second, the business requirements document, following reviews, revisions, and sign-offs by all stakeholders — which magically transforms them into owners — was handed off to a systems analyst. It was this person’s job to translate the business requirements into a set of functional specifications, logical statements and if-then structures that programmers (not yet called developers) turned into actual program code.
Done right, this process, though glacially slow and deliberate, was often a thing of beauty, with buy-ins and approvals every step of the way. There could be no room for stakeholder/owners to complain that the delivered system was not what they wanted.
Today, things are very different. We don’t have months. New apps, systems, and user interfaces must be designed, built, tested, and deployed in a matter of weeks. Infrastructure is as much a part of system design as the software itself. Where everything once ran on machines somewhere down the hall, today, your apps run, well, somewhere. You’re calling on data from multiple sources, integrating data and processes on the fly, and delivering the results to potentially millions of devices owned by completely nameless, anonymous users.
That brings me back to the original question. When a project for a new application or system is dropped in your lap, what do you use as the specifications basis for writing code and designing an architecture? Does your organization have analysts who create detailed business and logical requirements? Are you instead saddled with this responsibility, and if so, do you know the business well enough to do a comprehensive job? Does someone have a chat with you over coffee and attempt to explain what he or she wants?
Share your experiences, good or bad, about defining app and systems requirements. We’d like to hear from you.