A functional specification is the set of documentation that describes the requested behavior of an engineering system. The documentation typically describes what is needed by the system user as well as requested properties of inputs and outputs.
Test-driven development or TDD is a widely accepted practice used by agile software development teams of many flavors – not only Extreme Programming teams. For each small bit of functionality they code, programmers first write unit tests, then they write the code that makes those unit tests pass. TDD is seen as a design tool, since it forces the programmer to think about many aspects of each feature before coding.
The role of the interaction designer is to specify the interface’s behaviors and elements, so that engineers know what to build and how the product should operate. This documentation is commonly known as a UI specification or UI spec. There are several applications for authoring a UI spec, with wikis being a relatively new tool. However, designers should be aware of a wiki’s benefits and drawbacks for documentation, since UI specs uniquely reflect a project and its context. The documentation needs are often based on the size of the project, launch date, team dynamics, audience, technology, and the product development process. The development process usually plays a major role in how teams interact and how work is completed or delivered, thus, there is a direct relationship between the UI spec and the process the team is using.
This article describes several characteristics of high quality software requirement statements and specifications. We will examine some less-than-perfect requirements from these perspectives and take a stab at rewriting them. I’ve also included some general tips on how to write good requirements. You might want to evaluate your own project’s requirements against these quality criteria.
For technical writers who haven't had the experience of designing software requirements specifications (SRSs, also known as software functional specifications or system specifications) templates or even writing SRSs, they might assume that being given the opportunity to do so is either a reward or punishment for something they did (or failed to do) on a previous project. Actually, SRSs are ideal projects for technical writers to be involved with because they lay out the foundation for the development of a new product and for the types of user documentation and media that will be required later in the project development life cycle. It also doesn't hurt that you'd be playing a visible role in contributing to the success of the project.
Technical specifications are improved in several ways with one easy procedure - writing them in the present tense. That is, rather than trying to specify constraints on a product that does not yet exist, describe the product as though it already existed.