• Whatever specs exist
• Software change memos that come with each new internal version of the program
• User manual draft (and previous version’s manual)
• Product literature
• Published style guide and UI standards
• Published standards (such as Clanguage)
• 3rd party product compatibility test suites
• Published regulations
• Internal memos (e.g. project mgr. to engineers, describing the feature definitions)
• Marketing presentations, selling the concept of the product to management
• Bug reports (responses to them)
• Reverse engineer the program.
• Interview people, such as
•development lead
•tech writer
•customer service
•subject matter experts
•project manager
• Look at header files, source code, database table definitions
• Specs and bug lists for all 3rd party tools that you use
• Prototypes, and lab notes on the prototypes
• Interview development staff from the last version.
• Look at customer call records from the previous version. What bugs were found in the field?
• Usability test results
• Beta test results
• Ziff-Davis SOS CD and other tech support CD’s, for bugs in your product and common bugs in your niche or on your platform
• BugNet magazine / web site for common bugs
• News Groups, CompuServe Fora, etc., looking for reports of bugs in your product and other products, and for discussions of how some features are supposed (by some) to work.
• Localization guide (probably one that is published, for localizing products on your platform.)
• Get lists of compatible equipment and environments from Marketing (in theory, at least.)
• Look at compatible products, to find their failures (then look for these in your product), how they designed features that you don’t understand, and how they explain
their design. See listserv’s, NEWS, BugNet, etc.
• Exact comparisons with products you emulate
• Content reference materials (e.g. an atlas to check your on-line geography program)
No comments:
Post a Comment