Home arrow Practices arrow Page 9 - Writing A Functional Specification

Sealed With A Kiss - Practices

Writers hate coding, and developers hate writing. And never thetwain shall meet...except, perhaps, in a functional specification. More,inside.

TABLE OF CONTENTS:
  1. Writing A Functional Specification
  2. Getting Formal
  3. Of Time And Talent
  4. Laying The Foundations
  5. I, User
  6. The Screening Process
  7. The Color Purple
  8. Hitting The High Notes
  9. Sealed With A Kiss
By: Deepa L, (c) Melonfire
Rating: starstarstarstarstar / 73
April 25, 2003

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement
Last, but definitely not least, is the review of the functionalspecification. As I mentioned above, this is a document that is approved bythe customer as a token of acceptance of the application you offer him, andtherefore needs to be completely free of loopholes and ambiguity.

The first level of review will be performed by you, the writer. The usualchecks that any written document goes through - proof-reading, editing,formatting, spell-check and grammar-check - definitely apply. Beyond this,you might want to test the document on a designer or developer, to see if itmakes sense to them.

Next, the project mangers should review the document to see if it isimplementation-worthy. Since these are the people who will be using thefunctional specification in the next level, you can expect them to get backto you if they find that any of your design decisions violate theconstraints under which they will be working.

Incorporation of changes suggested during the review stage needs to be donevery carefully. Be sure to incorporate changes at all points in the designthat are affected by them. Noticing an incompatibility after customersign-off is extremely time- and cost-consuming.

Once you have a functional specification that has been amply thumbed throughby the internal team, you will be ready to show it off to the customer.Remember to discuss, in detail, any changes or additions that the customerasks for, and incorporate the changes for re-review only when you arecompletely clear on their impact.

Once you're all done and your team has started using the document to build amore technical design specifications, you can relax - your job is done, andyou're all ready to take on the next challenge. Happy writing!

Note: Examples are illustrative only, and are not meant for a productionenvironment. Melonfire provides no warranties or support for the source codedescribed in this article. YMMV!

 
 
>>> More Practices Articles          >>> More By Deepa L, (c) Melonfire
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

PRACTICES ARTICLES

- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: