Functional specifications (functional specs), in the end, are the blueprint for how you want a particular web project or application to look and work. It details what the finished product will do, how a user will interact with it, and what it will look like. By creating a blueprint of the product first, time and productivity are saved during the development stage because the programmers can program instead of also working out the logic of the user-experience. It will also enable you to manage the expectations of your clients or management, as they will know exactly what to expect.
Much has been said and written about Object-Oriented Programming in the past few years, some of it even worthwhile. While not the panacea on which we've all waited, OOP is, however, changing not only our concept of software design and development, but is subtly re-shaping the way in which we see and know the world. For technical communicators, this epistemological change will radically affect not only the way we craft software specifications, but will permanently re-shape our worldview.
When it comes to modern theater, stage directions—the descriptive text that appears within brackets in a script—are an important piece of the puzzle. They speak for the playwright when he is not there. They provide details about how the playwright has imagined the environment and atmosphere. They describe critical physical aspects of the characters and settings. Stage directions can also be critical in dictating the intended tempo and rhythm of the piece. Whether they establish a production’s overall tone or elucidate particular actions of characters, stage directions help tell the complete story that is in the playwright’s mind. Stage directions accomplish all of this, using a simple convention that structurally separates them from the actual story.
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.