DerivedRequirementsNotes

I didn't have a handout for the Derived Requirements session, and several people asked about one. I put this together and placed it on the wiki. I invite those who attended to put their comments and recollections into this. Those who didn't attend are also welcome to add comments and questions to this entry.

DwaynePhillips 10 November 2005

A point of the session was that often we infer requirements. Those inferred or derived requirements may become as or more important than the requirements that are stated explicitly.

One concept we discussed was the words "infer" and "imply."

From dictionary.com

Imply To express or indicate indirectly: His tone implied disapproval.

Infer transitive verb : to derive as a conclusion from facts or premises.

The people stating requirements often imply things that they want from a system. The people listening to the requirements and trying to build a system often infer new requirements.

Another concept we discussed was the difference between misunderstandings and derived requirements.

Your boss asks you to, �finish this work and bring it to my house before the end of the week,�

Possible misunderstandings are: does the week end on Friday or Saturday? Is 5PM the end of the day or midnight?

Derived requirements creeping in include, �The first time you visit someone�s house you bring a house-warming gift. The required dress for visiting changes at dusk.� What comes to mind when someone asks you to visit their house?

While discussing this example, I discovered that the vast majority of the attendees were "techies" who gave no thought to social etiquette.

One attendee, however, inferred some relationship requirements in this example. The attendee talked about what type of work relationship the boss wanted to progress to by asking me to come to the boss's house. I had not thought of that.

We moved on to the first exercise. We divided into two groups: a design team and a design review team.

The design problem for the design team was:

Design a system that saves what people write.

Three stated requirements:

Works for at least three people.
Saves the writing for at least one year.
Easy to learn � a high school graduate has � hour to learn it.

The design team drew and described a system based on a file cabinet. They would put writing into folders. The folders would be first organized by date and then by the person who wrote the piece. The files could store paper as well as disks.

The design review team then commented on the design and noted the derived requirements. The design allowed for organizing the writing. Organization was not a stated requirement. The design allowed for retrieving the writing easily. Retrieving the writing was not a stated requirement. The design allowed for easy disposal of the writing once they were past a year old. Disposal was not a stated requirement.

We discussed the design at length. While doing so, one idea for a system would be a big hole in the ground. The hole would save the writing for a year. I guess the design team's design was extravagant as it had many more features than the stated requirements required.

After the break, we moved on to a second exercise:

Design a decoration scheme for a place for a special occasion.

Three stated requirements.

The special occasion will be indoors in air-conditioned space.
Between 10 and 200 people will attend.
At least ten of the attendees are family relatives of yours.

Armed with the knowledge gained from the first exercise, the second design team created a decoration scheme that had few derived requirements.

After this exercise we discussed a few more concepts of derived requirements. I encourage people to keep the derived requirements separate from the stated requirements. That way, if a stated requirement changes, it is easier to find and change the requirement derived from it. I described the classic systems engineering approach of putting the stated requirements at the top of a requirements tree and then branching down to requirements derived from them. Keep all these requirements in a linked database so that finding and then tracing up and down the tree is easier. That approach requires a lot of work, but is worth it in some projects.

DwaynePhillips 10 November 2005

Updated: Thursday, November 10, 2005