Again on Functional Specifications

Then there is the issue of incomplete functional specifications. The functional specification sometimes does not cover many items which the author may have taken for granted. However, this may be required for development and test teams to come up with their downstream design and planning. For enhancement projects, many a times, the author of FS documents, do not start a document from scratch. Various FS documents are available in the organizational repository. Documents with similar functionality forms the base of a new FS. In doing so, the author unknowingly misses out to remove old references and sections in the document. Also sometimes, key areas that are supposed to be covered in the FS are left out by mistake. All these come into light during the review process. However, donkey’s hours are spent by the guys reviewing these FS to figure out what is correct and what isn’t.

More on Functional Specifications

Then there are FS documents which get into details of technical design. May be the author, with a good intention to give a heads up to the development team, points out the programs to be analyzed for impact and enhanced if required. Other times, the author is not aware of the existing system functionality and works backwards from the existing code and prepares the FS by analyzing the existing code. This is not the right way to write a FS. However, in absence of proper supporting documentation, and may be lack of time from the end users to explain the current system behavior, there is no other alternative for the FS author, other than looking into the existing source code to find out what the system does. However, if the author is not technically sound, he does not figure out completely what the functionality is, and just dumps the code into the FS for the development team to figure out what to do with it. This is not the right way to go about it! What the author of the FS does not understand is that the FS is supposed to give the behavioral aspect of the system and not how this behavior is to be achieved. How that behavior is to be achieved is a question for the design/development team to grapple with. A FS as the name suggests should give only the emergent functionality of the system. There should be mention of different interfaces in the system and how the interfaces interact with each other, but rarely ever any code to tell how it may be achieved.

Functional Specifications and Gaps

Most of you would have spent considerable time preparing, reviewing or reading through pages of Functional Specifications (FS) for your projects. In fact, functional specifications are the start point for most of the project leads, technical developers and system testers. If the FS is not of good quality, all the downstream outputs like the Technical Specifications, Functional Test Plans, etc will follow the GIGO (Garbage In – Garbage Out) rule.

In my experience in enhancement type projects, the FS, normally details all that is required from the system. It flows down from the business requirements. This would have been okay if the project is a green field new development project, where everything is to be built from the scratch. But in typical enhancement projects, where there are modifications to be made to an existing code base to satisfy the new requirement, if the FS is a compilation of all that the system should do, it becomes no more than a user manual. And subsequently, when the development teams and the testing teams review the FS to figure out what changes are required to be done or what is to be the focus area of testing, they again have to fall back on the author of the FS or some other person with knowledge of the existing system, to point out the specific area of change. This clarification takes a lot of time and effort which could have been saved if the author of the FS clearly specified the area of changes.

Ideally, the FS should contain a section on the gaps between the existing functionality and the required functionality. For larger implementations, the Gap document should be a standard output for each functionality that is required.

Between the Gaps (Interfaces)

Generally an interface means a junction where there is touch point between different systems. Typically, there is some exchange of data at interfaces. Most of us are aware that in any project, managing the interfaces between various systems is of critical importance. The same is also true whenever there is any transition between anything in a project. Be it a transition whenever the project leader changes or the test manager changes or even in transition between one phase of the project to another. Whenever there is an interface, there are chances of data / information slipping in the handshake and it may pop its ugly head up later in the lifecycle of the project. What does a project manager do to manage these interfaces seamlessly?

Whenever there is an interface, the first thing to do is to define its boundaries. This is pretty straight forward while dealing with IT systems; but may not be so while dealing with processes or people. Difficult thought it may be, that is the prudent thing to do. In terms of project phases, we need to clearly define what is the entry and the exit criteria. These are the ones documented in the project plan. Similarly, for people interfaces, it would mean what are the communication channels, what are the escalation procedures and what are the bare minimum handover activities in case of team member transitioning from the project. When the project starts, there is lot of pressure on the work to be performed and apart from defining the system interface boundaries and in some cases, the phase entry and exit criteria, the human interface part is the most neglected one.

Once the boundaries are defined, the same needs to be validated. We need to refer to this as per the need of the project when the project progresses. Many times, we document everything, but do not make use of the same, again with the pretext of lack of time for these activities. Following this simple step will help us prevent valuable time and effort by keeping the important things from slipping in between the cracks.