Conclusion to the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.”
- Short-change Time Spent on Software Requirements or Don’t do Them at All
- Don’t Listen to Your Customer’s Needs
- Don’t use Models
- Use Weasel Words
- Don’t Prioritize Requirements
- Don’t Baseline and Change Control Requirements
- Don’t do Requirements Traceability
There are many ways to do serious damage to your project with poor software requirements. I have explored 7 of the most common ways over the last several blogs. It is time now time for a quiz!
1. A landmark study in the 1970s showed that an error created early in the project, for example during requirements specification, costs 50 to 1,000 times as much to correct late in the project as it does to correct (or avoid) close to the point where it was originally created. The author of this study was:
a. Fred Brooks
b. Ed Yourdon
c. Tom DeMarco
d. Barry Boehm
e. Harlan Mills
2. What are 2 reasons that errors are so much more costly to correct downstream?
3. To prepare for a requirements elicitation session with your customer, you should:
a. Prepare an agenda and distribute in advance of the meeting
b. Distribute any review materials in advance of the meeting
c. Know your audience well
d. Show up early before the meeting to set up the environment
e. All of the above
4. To show respect to your Customers and their time in a requirements elicitation session, which of the following should you not do?
a. Manage time to the agenda
b. Practice reactive listening
c. Use models to abstract from lower level requirements complexity
d. Elicit participation from all members
e. Maintain eye contact and be aware of body language
5. To show respect to your Customers and their time after a requirements elicitation session, which of the following should you not do?
a. Send out meeting minutes with decisions, action items and issues
b. Send out meeting minutes the same day if possible
c. Action items listed in meeting minutes should leave the due date blank so that the assigned owner can choose when to complete the task
d. Plan to send out reminders to people with assigned action items
6. Which of the following is often cited as one of the classic positive examples of a company really listening to their customers and understanding their needs?
a. Ford and Firestone reaction to tire blowouts
b. Toyota reaction to accelerator problems
c. BP oil spill
d. Johnson and Johnson reaction to cyanide-laced Tylenol
e. Airline customer service in general
7. Which of the following are good reasons to use models for software requirements analysis?
a. Organize large amounts of information
b. Figure out what’s missing
c. Give context to a collection of details
d. Focus on a particular subset of requirements
e. Make it easier to find and fix requirements errors early
f. All of the above
8. Which of the following are good best practices in the use of models?
a. Don’t use them at all – it is better to go straight to the requirements
b. Use only process flows
c. Combine data flows and decisions trees with process flows all in one model
d. Wait until after the requirements have been derived from the models before getting feedback on the models from the customer
e. None of the above
9. Name some common types of requirements models to model the people aspects of the system.
10. Name some common types of requirements to model the system.
11. Name some common types of requirements to model data.
12. Using weasel words increases ambiguity in software requirements. True or false?
13. Which of the following requirements does not use weasel words?
a. The system shall provide a best-in-class customer search capability.
b. The system shall provide a robust data management compaction utility.
c. The system shall provide flexible order entry.
d. The system shall be fast.
e. The system shall return the first 500 records that match the search criteria in no more than 2 seconds.
f. The new GUI shall be user friendly.
14. One attribute of excellent requirements is that they are explicitly prioritized. True or False?
15. Prioritization of requirements helps project management to balance which of the following project demands?
a. Schedule
b. Budget
c. Staff
d. Resources
e. Feature content
f. Quality goals
g. All of the above
16. Which of the following are not requirements prioritization techniques?
a. MoSCow
b. Prioritization Poker
c. Prioritization Charades
d. $100 Dollar or 100 Point method
e. Cost Value
f. AHP
17. Which of the following are symptoms of insufficient requirements change control?
a. Unplanned features become evident during testing
b. New features requested after baseline requirements sign-off are not included in the final release
c. Features that were rejected by the project team are implemented by developers
d. All of the above
18. Which of the following do not support software requirements change control?
a. Define a practical change control process for your project
b. Use a CCB
c. Establish and enforce realistic change control policies
d. Delegate addition of last minute cool stuff to the discretion of marketing and development staff
e. Use a tool to collect, track and communicate changes
19. Software requirements traceability is required in the medical device and aerospace industries. Is it still valuable for other software systems even if their failure does not lead to loss of life? Yes or No.
20. Which of the following questions are answered by requirements traceability?
a. Is every business requirement covered by at least one functional requirement?
b. Are there any functional requirements that do not support a business requirement?
c. Are the highest priority requirements being implemented first?
d. Which requirements are not yet tested?
e. Have all requirements been successfully tested?
f. All of the above
Scoring:
1-d, 2- project artifacts to be corrected increase over time and more people need to get involved in defect correction as the life cycle progresses, 3-e, 4-b, 5-c, 6-d, 7-f, 8-e, 9-org chart, use case, user stories, decision trees; 10-context diagram, cross functional process flow, UI display-action-response table, wireframe; 11-business data diagram, data flow diagram, state diagram and state table, data dictionary; 12-True, 13-e, 14-True, 15-g, 16-c, 17-d, 18-d, 19-Yes, 20-f
How did you do?
Conclusion:
Don’t shoot yourself in the foot on your next project! Resolve today to use good software requirements skills to help put your project on the road to build the right product and build it right. The choice is yours.
