Do you know the Specification Review deliverables?Last updated by Tiago Araújo [SSW] about 1 year ago.See history
Usually, a specification process is done with the client before beginning work on a project, just like you would never build a house without getting an architect to create a plan.
As you might appreciate, it is not realistic to understand the complexity of your system and give you a realistic estimate after a brief meeting. Our experience tells us we will need to spend a few days to obtain and document the requirements from your project’s stakeholders. This will help you turn your ideas into a more detailed roadmap.
The deliverables for the Specification Review depend upon how large the application is and the time we have spent on the review. You should have the following:
- An architectural roadmap recommending technical solutions
- A breakdown of the required software application into its core components, likely to include the approximate number of main features (e.g. forms, reports, etc.)
- An integration plan
- A deployment strategy
- An MVP (minimum viable product) will be identified, as well as a wish list - requiring the client to set the priorities for the project through defining what is in and out of scope for the MVP
- A detailed list of 'issues' associated with the existing system which impact future development and maintenance
- Hardware and licensed software recommendations
- Mock-ups (if required)
- A list of Product Backlog Items (PBIs) broken down based on the Requirements Analysis and the Architectural Design
- These PBIs will then be estimated
- The estimated number of Sprints
- Estimated cost of the project
With the Specification Review, the client can see whether the consultant understands their business and the requirements for their software development project.
The ballpark estimate allows them to decide whether the project is feasible for their budget and time-frame.