A Use-Case is not a Requirement

A small conversation from a past interview has popped back in my mind. The interviewer told me how important use-cases are when going from high-level requirements to the actual software that you write. I completely agree with this, and to this day I am kicking myself for not saying this first. I have a feeling the person interviewing me was seeing whether or not he could lead me to discuss the importance of use-cases and my experience developing them, but for some reason it didn't quite come to me.

Anyhow, amongst discussing use-cases, I asked him whether or not a use-case is a requirement. I recall (although my memory is a bit fuzzy) that he said it wasn't a high-level requirement, but a derived, lower-level requirement, or specification that gets into implementation. I nodded, but realized that I didn't necessarily agree with this (again I am kicking myself for not stating this out-right).

Requirements
A requirement is a nugget of information that describes a characteristic that a system must fullfill. A derived requirement, or specification, breaks down these morsels of information further, and typically has a "consists of" or "satisfies" parent-child relationship[1].

Requirements can be indexed, reused, and (importantly) associated with other requirements. The end result, a database of associated requirements, can be divided up and used to generate all sorts of things, including the end-deliverable, project plans, and work break down structures. That is why good requirements and specifications, along with whatever tool presents and manages them, are so powerful. They drive not just the deliverable, but the entire project.

Use-Cases
A use-case is not a requirement. A use-case is a sequence that involves an actor, start conditions, and an end condition. Like requirements, they describe a system. But although they most likely they will help determine requirements, they are not requirements themselves. They are more than just a nugget of technical information.

Depending on the actor, a use-case can help describe any level of the system. If the actor is the end-user, the use-case will help clarify and create the highest-level requirements. If the actor is a class, code module, or process, it will help clarify and create how lower-level derived requirements. So a use-case can describe and develop both how a system must behave, and how it will work.

Here is an example; a use case linked to higher level requirements.

A Use-Case
1. The end user opens the door to the aircraft.
2. The end user sits in the seat of the aircraft.
3. The end user press the on button button on the dash of the aircraft.
4. The aircraft engine starts.

Start Condition: Aircraft is off and unoccupied
End Condition: Aircraft is on and occupied.

A Requirement
1 The aircraft shall allow the pilot to turn on and off the aircraft.

But more Useful, a set of Associated Requirements:

1 The aircraft dash shall allow the pilot to turn on and off the aircraft.
1.1 The aircraft engine shall turn on when the on and off button on the dash in the down position.
1.2 The aircraft engine shall turn off when the on and off button on the dash is in the down position.
2 The aircraft shall have room for one pilot.
2.1 The pilot of the aircraft shall weigh less than 300 pounds.
2.2 The aircraft shall have a cushy leather seat.
2.2.1 The cushy leather seat shall cost less than $1000

We can see that

• A use case is different that a requirement.
• A use case helps create requirements.
• A use case can help create any level of requirements.
  

[1]As a side note I have seen cases where folks will refer to a requirement as a "specification" if it has a "satisfies" parent-child relationship, and as a "derived requirement" if it has a "consists of" parent-child relationship. In general I think all systems can be broken down into a requirements hierarchy, and where you draw the line between "what is needed" and "what fulfills" is arbitrary and depends on context.