Technical Book Club: Code Complete – Measure Twice Cut Once: Problem Definition, Requirements, and Changing Requirements
The next sections are fairly straight-forward. Here’s a summary of some of the keypoints:
- Without a good problem definition, you might spend a lot of time solving the wrong problem … and never solve the right one.
- Requirements enable the user to agree/disagree before programming begins, which keeps the programmer from making decisions while programming and the cost of changes low.
- 25% of change in requirements accounts for 70-85% of the rework on a project
Cost of errors in requirements detected in
- the requirements stage: 1 unit
- the architecture stage: 3 units
- the coding stage: 5-10 units
- system test: 10 units
- post-release: 10-100 units (closer to 10 for smaller projects with low overhead)
How to best accommodate changes in requirements:
- ensure high quality requirements
- be transparent about the cost of requirement change
- have a change-control procedure
- choose a development approach that is a good fit for the project
- dump the project
- keep a business focus
Your Turn: Here’s an example project, what improvements would you suggest to improve the project?
Company WebsitesRUs creates websites and recently completed the first revision of a website. The website is ready to launch for the target deadline in 2 weeks. They meet with the customer for their first review of the website. The website creates a stream of family/friend information for recovering surgery patients to catch up on the time they missed.
The customer is excited at their work and after the meeting 8 different emails are received by the company with 24 requests for changes. Sarah receives the messages and is overwhelmed by both the response and the number of requests. She knows the work requested would require significant re-work and would take 6-8 weeks to complete.
Spend your summer with Software for Students’ Technical Book Club to give yourself a competitive edge in the job market: