General Info: The main guideline for your Functional Specification is that it should address all of the functional requirements mentioned in your Requirements document, whether you plan to implement a solution or not. If there is some requirement for which you do not intend to implement a solution, your FS should explicitly state that fact, and give an explanation for why not. Although you are not required to explicitly mention all of the non-functional requirements in your FS, if they impact your proposed solution in some way, you should also make reference to them as part of your explanation.
Introduction Section: Some of the information in the FS will be repetitive, when compared with the Requirements document. The reason for this is that each document should stand alone, and therefore needs some of the same background information. For example, you should include an Introduction, in which you state the purpose, scope and objectives of your system in general terms before diving into the details. You may simply "cut and paste" this information from the Requirements document if appropriate. Additionally, you should include a Glossary for any abbreviations or special terminology used in the FS, and you should also make reference to your Requirements document in a References section. This reference should include the title, date and authors of the Requirements document.
Detailed Functionality Section: Each feature you intend to implement should have its own (sub)section in the FS. For example, if Section 2 of your FS is titled "Detailed Functionality", then Section 2.1 will give the details of Feature #1, Section 2.2 will give the details of Feature #2, etc. (You may choose to further organize the features into functional groups if appropriate.) Each of these sub-sections should explain the feature with enough information to link it to a specific requirement, and then give the proposed solution for the feature. Note that some functional requirements may give rise to more than one feature, and conversely, a single feature may cover more than one functional requirement. Again, be sure to cover all of the functional requirements mentioned in your Requirements document.
For example, say a functional requirement in a Word Processor project is to give the user the ability to copy text into a paste buffer. ("Paste Buffer" is an example of terminology which should be explained in a Glossary.) A (sub)section in the FS devoted to this feature would first state what the feature is: "The ability to copy text into a paste buffer," and then would give the proposed solution for this feature, looking something like the following:
Highlight the desired text and press "CTRL-C" to copy that text into the paste buffer. Text may be highlighted with either of the following 2 methods:Perhaps the ability to highlight text is another functional requirement, with its own section somewhere else in the document describing the feature. In that case, the above could be reduced to something like this:
- Click the mouse somewhere in the document, and drag while holding down the left mouse button. Release the mouse button when the desired text has been highlighted.
- Use the arrow keys to position the cursor at the desired position. Then hold down the SHIFT key while using the arrow keys to highlight the desired text. Release the SHIFT key when the desired text has been highlighted.
In order to copy a section of text into the paste buffer, the text must first be highlighted. Refer to Section 3.2 for details on highlighting text. Once the desired text has been highlighted, press "CTRL-C" to copy the text into the paste buffer.Notice that the descriptions above do not assume that the user is a programmer, or knows anything about how you will implement this feature. You are simply describing what the solution is; that is, how the user will access the feature and what the feature does.
Prototype or Mock-up Section: For any system that includes a graphical user interface (GUI), a prototype or mock-up is a great thing to include in your FS. There is no better way to get useful feedback from the user/client than by demonstrating how the system will actually work before you've implemented the functionality. Ideally, you would build a prototype in some rapid development language like Visual Basic. This allows the user to see what the layout will look like, including things like menu items, dialog boxes, which buttons to press when, etc., even if the actual system will eventually look somewhat different (because it's implemented in a different language, like Java, etc.) For this FS assignment, you will get extra credit for turning in a working prototype system that actually runs1. In the absence of a working prototype, a Mock-up can be used instead, consisting of images showing what the GUI will look like. This may be done using a drawing package (like Paint), or may be done by hand. Regardless of the method chosen, this section in the FS should detail all of the GUI elements which will appear in your final implementation. In addition to either a prototype or mock-up, you should also provide written descriptions of the GUI elements, including their purpose (what each element does) and how to access them.
Cross-references: As shown in the 2nd example above for the paste buffer feature, use cross-references liberally in your FS. The first time you use special terminology which is defined in the glossary, point out to the reader where to find the definition. If a feature makes use of some other feature, make a reference to the 2nd in the description of the first, and vice-versa if appropriate. If a feature is illustrated in your Prototype or Mock-up section, make reference to that fact. Examples of cross-references:
Final Remarks: Under normal circumstances in a professional software development environment, the FS phase is an iterative cycle, in which the client and/or end user gets to review your FS (possibly including prototype demonstrations), make comments and give feedback, and the FS is modified as many times as necessary until the client "signs off", agreeing that the FS covers all required features for the project. At this point, the FS may be considered to be like a contract, meaning if the FS states that you intend to implement a particular feature, you will be expected to design and implement2 that feature. Due to time constraints in the classroom setting, the instructor will review your FS and provide feedback, and you will not be required to modify and re-submit the FS unless there are gross errors or omissions.
1 If you intend to implement a working prototype for extra
credit, you must either provide written instructions for running it,
or make an appointment with the instructor to give a demonstration.
2 As stated during the Requirements Phase, you may not
actually implement the tool(s) you have chosen to specify in the
Requirements and FS. By the time we get to the design phase, you
will need to commit to a piece of the project to implement.