Welcome to the website of Davis Fiore

Documentation helps to think and design better solutions, makes implementations simpler and reduce bugs. It allows us to think wrong and change our tack, without actually writing any code.

It should start with at high level, going deeper to more details.

The documentation process varies, here's the course roughly followed by large projects:

• Specification
  • Project Definition (PD): scope, costs and definition of the problem
  • User Requirements Specification (URS)
  • Business Requirements Document (BRD): high level list of requirements by the business analyst
  • Software Requirements Specification (SRS), aka functional documentation or spec: details of the requirement by the business analyst
  • User Interface Specification (UI): when more UI details than the spec are required
  • Functional Requirements Specification (FRS): derived from SRS, but only functional and with more details
• Architecture
  • Architecture documentation: implementation details for component interaction
• Design
  • Technical documentation: implementation details for single component
• Implementation: no documentation
• Testing
  • Test strategy: defines the approach to testing
  • Test plan: all the details on how the strategy is achieved
  • System Test Cases (STC): the actual tests
  • Defect Tracking Log (DTL): the bugs detected
  • Test summary Report: report of the test results
  • Requirement Traceability Matrix (RTM): table that correlates tests and requirements
• Release
  • Release notes: information to be released to the end user
  • User guide