i saw this tutorial on functional specifications linked around a few places [ none of which i can remember right now ]. as an overview of the traditional functional spec it's the second best overview i've seen [ incidently, the article links to the best overview i've seen, painless functional specifications , which comes from joel ]:
"When the Functional Spec is completed, anyone who reads it should have a very clear idea about what the application is going to do and what it is going to look like. It should read very much like an instruction manual or cook book, with step-by-step descriptions of what happens and how the individual elements of the application work together.unfortunately, while this goal is certainly admirable, it will usually fail from an operational perspective, in part, explaining the horrendous record of estimations of development schedules, project complexity, and programmer productivity. this, in turn, leads to the interest in "lightweight" methods for requirements gathering , which alters the relationship between the developers and the customer:
Another key benefit of writing up a Functional Spec is in streamlining the development process. The developer working from the spec has, ideally, all of their questions answered about the application and can start building it. And since this is a spec that was approved by the client, they are building nothing less than what the client is expecting. There should be nothing left to guess or interpret when the spec is completed...and this, in a nut, explains my love affair with the Functional Spec."
"The primary vehicle for requirements elicitation in XP is adding a member of the customer’s organization to the team. This customer representative works full time with the team, writing stories – similar to Universal Markup Language (UML) Use Cases – developing system acceptance tests, and prioritizing requirements [4]. The specification is not a single monolithic document; instead, it is a collection of user stories, the acceptance tests written by the customer, and the unit tests written for each module. Since the customer is present throughout the development, that customer can be considered part of the specification since he or she is available to answer questions and clear up ambiguity. "ing from the spec has, ideally, all of their questions answered about the application and can start building it. And since this is a spec that was approved by the client, they are building nothing less than what the client is expecting. There should be nothing left to guess or interpret when the spec is completed...and this, in a nut, explains my love affair with the Functional Spec."
“"it is hard to be brave," said piglet, sniffing slightly, "when you're only a Very Small Animal." rabbit, who had begun to write very busily, looked up and said: "it is because you are a very small animal that you will be Useful in the adventure before us."”
the complete tales & poems of winnie the poohthis site chronicles the continuing adventures of my son, odin, who was unexpectedly born on the fourth of july at 25 weeks gestation, weighing 1 pound 7 ounces.
he's quite a fighter and you can always send him a postcard to the most current address listed here if you're inspired by his adventures. see the postcard project/google maps mashup to see a map of the postcards.
if you're new, you can browse the archives to catch up. and don't forget to watch a few movies that i made while we were in the neonatal intensive care unit. or if you want the abridged version and you can find a copy, you can read about his adventures in the november 2005 issue of parents magazine.
daddytypes
/
blogging baby
/
rebeldad
/
thingamababy
/
The Continuing Adventures of Super-Preemie
/
dooce
/
look snazzy and support the site at the same time by buying some snowdeal schwag!
valid xhtml 1.0?
This site designed by
Eric C. Snowdeal III
.
© 2000-2005