Where application development is concerned, the ability to produce great code is just one small component of overall success. Just as essential is the ability for the developers to clearly grasp the business requirement - and deliver against an accurate functional specification.
It is for this reason that the roles necessary for the creation of effective applications, which meet functional and technical specifications accurately, include those of the developer, the business analyst, and the business managers who initially conceived the need for custom development to solve a problem.
It is a fact that the process for the creation of an application is not always clearly understood. From the business owner, to the user, to the developer, there are different perspectives and different expectations at play. As requirements pass through this chain, inconsistencies or assumptions can be introduced, which can derail the process.
Talking in tongues
It comes down to effective communication - but that is made more challenging by the reality that the various links in the value chain are, to all intents and purposes, speaking in different languages. For any IT project, this is often where things fall down. When taking requirements from a user who has a particular viewpoint, preconceptions and reality filter, to compiling these into a functional specification, there has to be some mechanism to ensure there is no loss of intent in the process.
Using the functional specification, the developers then turn what started out as a freeform thought or concept, into lines of code, which comprise the application.
Assumptions are rife when dealing with the different levels of the application development value chain, and this is where the process can get horribly tortured.
Nick McKenzie is technical director at nVisionIT
The business analyst plays a central role in the process of understanding the requirement and 'translating' it so developers can produce the application accurately and with the necessary functionality. But the business analyst, too, cannot work in isolation from the developers.
Often it is believed that the technical team should be brought in only once the functional specification is determined, but it is essential that they are included in the application design sessions.
The business analyst plays an essential role in understanding what the client requires, but they cannot always fully appreciate what is possible from a coding or technology perspective. The programmer's input is therefore necessary to manage the expectations of the client; without this input, the functional spec runs the risk of being written just to get signoff from the client without objection.
Dealing with assumptions
It is said there is a hidden message in the word 'assume' - it makes an ass out of you and me - and while slightly crude, this rings true for application development.
Assumptions are rife when dealing with the different levels of the application development value chain, and this is where the process can get horribly tortured. Assumptions usually come about as the result of the familiarity, which each link has with their work. The business owner, for example, might include one line in a specification: To do A you need to have B. However, B is not specified. He assumes that because he knows what B is, that the business analyst and the programmers will also know it.
B could be of such consequence that it can completely change the scope of a project. This highlights the need for requirements traceability.
When developers are writing code, they need to know how it relates to requirements, how those requirements fit into scenarios and how those scenarios roll up to form a complete product.
The answer to what is a tricky and recurrent challenge for software developers lies in process and approach, which comes from years of experience. But it also lies in using appropriate tools to support the process and approach.
You want whatever tool you are using to understand that you are writing a functional specification. In the process, the tool helps check assumptions and create outputs that your downstream development applications can use - such as, for example, generating a work breakdown structure from the use cases detailed in the functional specification.
Such tools also allow more people to participate in application design, effectively including all the links of the chain, and equipping developers to write applications at a much higher level of abstraction.
Together with proven process and approach, such tools are a step forward in ensuring that application developers consistently and accurately meet the requirements of their clients.
In the next Industry Insights...
The bugbear of scope creep and changing expectations over time can scupper the success of what may start out as a straightforward custom application development project. In the next Industry Insight, I will tackle the sometimes thorny reality of customer expectations and how to manage these effectively to ensure the application delivered is the application that was originally ordered. In the third Industry Insight, I will introduce the concept of application life cycle management and how this affects the design, creation, delivery and management of custom applications.
* Nick McKenzie is technical director at nVisionIT.
Share