What are Functional Specifications?

Contributed by Sivaraj Functional specifications (functional specs), in the end, are the blueprint for how you want a particular report and transaction to look and work. It details wh at the report will do, how a user will interact with it, and what it will look l ike. By creating a blueprint of the report or transaction first, time and produc tivity are saved during the development stage because the programmers can progra m instead of also working out the logic of the user-experience. It will also ena ble you to manage the expectations of your clients or management, as they will k now exactly what to expect. A key benefit of writing up a Functional Spec is in streamlining the development process. The developer working from the spec has, ideally, all of their questio ns answered about the report or transaction and can start building it. And since this is a spec that was approved by the client, they are building nothing less than what the client is expecting. There should be nothing left to guess or inte rpret when the spec is completed. Functional Specification A functional specification (or sometimes functional specifications) is a formal document used to describe in detail for software developers a product's intended capabilities, appearance, and interactions with users. The functional specifica tion is a kind of guideline and continuing reference point as the developers wri te the programming code. (At least one major product development group used a "W rite the manual first" approach. Before the product existed, they wrote the user 's guide for a word processing system, then declared that the user's guide was t he functional specification. The developers were challenged to create a product that matched what the user's guide described.) Typically, the functional specifi cation for an application program with a series of interactive windows and dialo gs with a user would show the visual appearance of the user interface and descri be each of the possible user input actions and the program response actions. A f unctional specification may also contain formal descriptions of user tasks, depe ndencies on other products, and usability criteria. Many companies have a guide for developers that describes what topics any product's functional specification should contain. For a sense of where the functional specification fits into the development proc ess, here are a typical series of steps in developing a software product: Requirements: This is a formal statement of what the product planners informed by their knowle dge of the marketplace and specific input from existing or potential customers b elieve is needed for a new product or a new version of an existing product. Requ irements are usually expressed in terms of narrative statements and in a relativ ely general way. Objectives: Objectives are written by product designers in response to the Requi rements. They describe in a more specific way what the product will look like. O bjectives may describe architectures, protocols, and standards to which the prod uct will conform. Measurable objectives are those that set some criteria by whic h the end product can be judged. Measurability can be in terms of some index of customer satisfaction or in terms of capabilities and task times. Objectives mus t recognize time and resource constraints. The development schedule is often par t or a corollary of the Objectives. Functional specification.: The functional specification (usually functional spec or just spec for short) is the formal response to the objectives. It describes all external user and programming interfaces that the product must support. Design change requests: Throughout the development process, as the need for chan ge to the functional specification is recognized, a formal change is described i

n a design change request. Logic Specification: The structure of the programming (for example, major groups of code modules that support a similar function), individual code modules and their relationships, a nd the data parameters that they pass to each other may be described in a formal document called a logic specification. The logic specification describes intern al interfaces and is for use only by the developers, testers, and, later, to som e extent, the programmers that service the product and provide code fixes to the field. User documentation: In general, all of the preceding documents (except the logic specification) are used as source material for the technical manuals and online information (such a s help pages) that are prepared for the product's users. Test plan: Most development groups have a formal test plan that describes test c ases that will exercise the programming that is written. Testing is done at the module (or unit) level, at the component level, and at the system level in conte xt with other products. This can be thought of as alpha testing. The plan may al so allow for beta test. Some companies provide an early version of the product t o a selected group of customers for testing in a "real world" situation. The Final Product: Ideally, the final product is a complete implementation of the functional specif ication and design change requests, some of which may result from formal testing and beta testing. The cycle is then repeated for the next version of the produc t, beginning with a new Requirements statement, which ideally uses feedback from customers about the current product to determine what customers need or want ne xt. Most software makers adhere to a formal development process similar to the one d escribed above. The hardware development process is similar but includes some ad ditional considerations for the outsourcing of parts and verification of the man ufacturing process itself