Rebecca MacKenzie Advanced Writing in the Technical Professions CONTEXT MEMO Guidelines

Due: August 1, 2013 Professor Rachel Lewis

For my professional document I am creating a reverse functional specification. This type of document is usually created after the design phase of a website but before the implementation of the site. The document is created both to record assumptions and understandings about the site and to allow the programmers and engineers to easily implement the site as intended. The audience, therefore, is both computer scientists working on the functionality of the site, and the management team for the site who are in charge of recording client expectations. Because I am not in the process of designing a site, I will attempt to create this document using a site that has already been implemented. Because this type of document is not often circulated outside of the company it is created in, it is difficult to find samples or guidelines for such a document. Companies often address the issues raised in a functional specification in varying ways, and the formatting and rules about such a document can change depending on who is creating it. However, there are some traits that are true of any precise and accurate functional specification. These documents should provide a consistent, and clearly defined format which allows the user to easily navigate the document and to find any relevant sections that he/she may be looking for. This document is not intended to be read from start to finish. It is generally utilized a section at a time. Each section should describe a particular portion of the site or program that is being outlined and should describe any and all functionality desired for that portion. The writing in the document should be concise and vague language should be avoided so that it is clear what work is expected from the programmers and engineers. Examples should be provided of the design elements desired for each portion of the site. For instance, pictures of each of the controls on the site, along with dimensions can allow an easier implementation of the site. Terminology should be consistent throughout the document so that a user can easily understand what is expected for the site or program.

Intended Purpose and Audience

Rebecca MacKenzie Advanced Writing in the Technical Professions

Due: August 1, 2013 Professor Rachel Lewis

This document is intended for use inside a web development company. It is to be used as a record of the expectations of the client and the goals of the company in implementing the clients site. It is mainly viewed by programmers and computer engineers who are responsible for implementing the functionality of the site. The document is created between the design and development phases of the site. The document is intended to be changed as more information is collected about expectations and understandings regarding the site.

Limits of the Genre The main disadvantage of creating such a document is the wide variety of functional specification documents. This makes it difficult to determine whether or not the document I have created follows the guidelines and templates set down by companies who create such documents. There is also a limit to how much writing I can display in such a document, since the goal of the document is to be concise, and a functional specification is made up of mainly bulleted points aimed at allowing the programming team to implement the site in the manner dictated by the client. However, I believe the section that summarizes the project will show some analysis of the audience, as will the section on future steps for the project. This Recommendations section is not usually included in a functional specification, since the document generally only tells the programmers what they are implementing for the current phase of the project. However, I believe it could be useful to show what the company creating this site is not responsible for in the current phase and to examine ways in which the programmers might need to make their code easily changeable.

Choices One of the choices I made while creating this document was to focus on only a couple of pages of the site and document those more thoroughly, rather than creating a more vague document which displays all aspects of the site. I believe this choice makes sense in the context of the document because it would allow a more precise vision of the pages that the programmers are responsible for, and because it is often

Rebecca MacKenzie Advanced Writing in the Technical Professions

Due: August 1, 2013 Professor Rachel Lewis

the case that during the first phases of a project only part of the site is created. This allows the programmers to focus on one aspect of the site at a time. I addressed the omission of additional pages in the section detailing the goals of this phase of the project, as well as in the assumptions about the project. Another choice I made was to avoid describing where certain information would be stored in the content management system. In the document I was using as a sample of a functional specification, each attribute of the site was linked to an item in the content management system (CMS), where data about that attribute would be stored. However, because this site has already been created and I do not have access to the CMS used, I am unable to determine where items might be stored. Therefore I have removed this information. In certain cases, such as the copyright text, I provided this information with the understanding that all sites have a similar basic structure. For instance, in my work at Verndale, all sites had a Site Settings item in the CMS and therefore I felt it was reasonable to make assumptions about the kinds of information that would be stored there. I also chose to use a Word document to create, edit, and distribute this document. This is the format in which I most often received this type of document in my work. It was generally passed around the company electronically so that such elements as the interactive table of contents and embedded links would be most effective. I debated creating a PDF form of the document, but determined that such a form would not allow for the changeability that is such a big factor in functional specifications. These documents are constantly changing as the client and company come to a better understanding of the direction of the site and the requirements for its implementation.