Home | Login | Recent Changes | Search | All Pages | Help

SessionFive008

Derived Requirements

Dwayne Phillips

Description: A derived requirement is something that the customer doesn't state explicitly, but to meet one of the customer's requirements we have to derive or state a requirement ourselves. For example, the customer wants new software to run on his current Dell computer. A derived requirement is that the software must run on a Microsoft operating system. Sometimes we derive too many requirements and forget that they don't come directly from the customer. We turn something that we infer into something that the customer wants. Our assumptions about derived requirements can take the project in a direction the customer didn't really want to go.

We also can derive too many things in other parts of our lives. We tend to assume or infer something for a given situation. Pretty soon, what we inferred or derived becomes a rule written in stone. Our personal derived requirements end up running our lives.

Bullets: . We derive requirements from the requirements given to us by a customer. . Derived and customer requirements are different and should be treated differently. . We often forget this point. . Derived requirements often run our personal lives as well as our projects.

People: 4-12

Constraints: chairs for everyone, flip chart stand and flip charts, markers for flip charts, 5x8 cards, tape (scotch or masking)

ProgramScheduleAndSessions2005

Several people requested the notes from this session. I have started another page containing those notes and would be happy if others would add to them as well. See DerivedRequirementsNotes.

DwaynePhillips 10 November 2005