Problem Analysis and Project Scope

Key ideas#

Five steps of problem analysis#

1. Agree on the problem definition. Write the problem in a fixed form and check that everyone accepts it (template below). The Vision document in the Rational Unified Process (RUP) uses a very similar problem statement.
2. Find the root causes, the problems behind the problem, with a fishbone diagram or by asking the people doing the work. Then rank causes with a Pareto chart and fix only those where fixing costs less than the damage they cause.
3. Identify stakeholders and users. A stakeholder is anyone materially affected by the new system. Treat users and other stakeholders separately; both need attention.
4. Define the solution boundary. Split the world into the system and what interacts with it. An actor is anything outside the system that interacts with it. Finding the actors is a key analytical step.
5. Identify constraints on the solution. List each with its source and rationale. Some will become requirements.

Three syndromes#

• “Yes, but…” Users react to what they see with “yes, but…”. You cannot avoid it, so trigger it early with storyboards and prototypes rather than late with finished software.
• “Undiscovered ruins”. The more requirements you find, the clearer it is that more remain. Completeness is a horizon, not a finish line.
• “User and developer”. The two sides differ in language, background and motivation. The authors’ remedies: treat users as the domain experts and use storyboards or prototypes when they cannot say what they want; show storyboards, role playing or prototypes as early as possible; let analysts who think they know better play the user’s role for an hour or a day; and accept that suspecting others of politics is simply human nature.

Context-free questions#

Ask about the user’s problem without implying a solution: Who is the user? Who is the customer? Are their needs different? Bring in solution-related questions later, for feedback. At the end of each interview, write down the three most important needs you heard; the authors suggest about ten interviews yield around fifteen key needs. Questionnaires do not replace interviews, but they can test assumptions and measure preferences.

Davis’s five elements#

The authors cite Davis: a system definition is complete when it covers inputs, outputs, functions (how inputs map to outputs), system attributes (such as reliability and maintainability), and environment attributes (operating limits, compatibility). To test whether something is a software requirement, check that it fits one of the five.

Scope: the 200% problem#

Brooks’ law says that adding people to a late software project makes it later. Leffingwell and Widrig treat scope as features against resources and time, and observe that projects commonly start with about twice the work the team can deliver. The job is to cut scope, often by half, not to add people.

To set a baseline: list and prioritize features, estimate each roughly, and rate each one’s risk. A typical baseline holds all critical features, one or two important ones, and useful ones only as capacity allows; the rest move to future releases. Underpromise and overdeliver.

Negotiating scope#

Do not cut scope without the customer. A customer who takes part in the decision owns the result; one who hears about it afterwards blames the team. The authors draw on Fisher, Ury and Patton’s Getting to Yes: aim high but not unreasonably, separate people from the problem, focus on interests rather than positions, know your walk-away point, look for options that benefit both sides, and use objective criteria. A formal request for a new feature is the easier case, because you can show its impact (what must drop to make room). Features that slip in informally are more dangerous.

Process models and scope#

Applied to a 200% project, the waterfall model ends with nothing working at the deadline; Boehm’s spiral model at least leaves a few working prototypes and customer feedback; the iterative approach of Kruchten, later the basis of RUP, offers the most points to correct scope as feedback arrives. The authors’ conclusion: scope management, more than the choice of model, decides success.