At 11:00 AM -0400 10/21/07, Todd Zaki Warfel wrote: On Oct 21, 2007, at 5:50 AM, Bill Fernandez wrote:
... (for example, does the system use a session or a cookie to remember a user preference? which database does the data come from?)... BF: To me, these do not belong in a a functional spec. A functional spec would say "we have to let users set [these] preferences..." and "there must be a way to store and retrieve [this] data...". *how* the preferences and data are stored and retrieved is up to the engineers to design. Perhaps this is a difference in either experience or opinion (or both), but the functional spec is the part that elaborates more on the backend technology. So, this is exactly where I would see this type of information fitting in. Todd-- Then maybe we're using the term "functional spec" to mean different things, and maybe some of this discussion is each of us explaining what *we* mean by the term. My philosophy is that it's always best for everyone to agree on the goals, constraints, assumptions, etc. of the project then let everyone do their part towards realizing those goals. In my experience this starts with something that's often called a functional spec which describes *what* but not *how*. Indeed I just received from a client, who often involves me at the beginning of each project, an early draft of a document titled "functional spec for...", that did not say anything about the UI or the technical plumbing -- it was just a description of the various things the product had to do. It is also my experience that this initial, abstract statement of goals and constraints subsequently leads to concrete documents from various departments describing *how* they propose to accomplish the agreed-upon goals. From engineering this usually takes the form of engineering specs, database schema, APIs, etc. From me this usually takes the form of one or more "UI concept" documents, which leads in time to a detailed "UI spec" (which sometimes, if the product is web-based, is in the form of the actual HTML and CSS templates that will be used to implement the product). Also, I find that the formality of each step varies from project to project. If there are many departments and many players involved, then sometimes more formality is required. On the other hand, when a client says "just design *and* build me a new website", I can get by with asking a number of basic questions, doing a few reality checks, then doing most of the work in my head -- and letting much of the project develop "on the fly". It all depends on the situation. Of course others will have different experiences and so may slice and dice the process (and the terminology) differently. --Bill -- ====================================================================== Bill Fernandez * User Interface Architect * Bill Fernandez Design (505) 346-3080 * bf_list1 AT billfernandez DOT com * http://billfernandez.com ====================================================================== ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://gamma.ixda.org/unsubscribe List Guidelines ............ http://gamma.ixda.org/guidelines List Help .................. http://gamma.ixda.org/help
