A potential client of mine sells a Distribution Management System. When they sell and implement it for a company they take the base product and customise it as required. They are tasking me with writing a document that covers all the base functionality of the product. It will contain details such as navigation, screenshots, field length, field type, field options, validation, use cases etc. This document will be used as the base doc which their analysts wil then use when writing up the actual functional spec for acustomised implementation. The modified doc will be one that the customer needs to sign off on, prior to actual development and implementation, and will also be used by developers to do the build.
Would you call this base document a functional specification or is there another name?
I definitely sounds like a functional specification document as it doesn not include the requirements (why) but the functionality of the system (what & how).
You can call it the "Base Functional Specification" document.
It sounds like your company's process is to take the new customer requirements and analyze them in the contex of the "Base Functional Specification" the end result will be a modified system which will be based on the new Functional Specification which was created from the base specs.
Adrian
Thanks Adrian.
A agree with Adrian. You can also call it something like "Base Document - [insert system name]"
-htbaBA
Thanks!
The document my customer currently uses is a specification that is structured completely around the user interface (modules, tabs, button functions, field display, field validation etc). My customer really likes this structure cause it gives their customers a nice understanding of the interface and makes testing or checking of the interface easy. BUT, it really lacks any view of the processes of the application. This lack of process in the document makes it very difficult for the customer to see where the gaps exist between their own processes and the processes supported by the application.
My gut feel is that the doc should be structured around process and should reference the user interface where this is useful.... Is this correct?
Does anyone have a good example of a specification that is structured around the user interface, but still neatly, concisely references process too (or vice versa)?
Thanks
brought to you by enabling practitioners & organizations to achieve their goals using: