A while ago I realized that, at work, I ran into the same discussion about requirements terminology over and over again. Most discussions stem from the difference between the term “Use Case” and “Requirement”. Since I didn’t like repeating myself over and over again I decided to do something about it. In this kind of situation the best thing one can do is to clearly define the terms once and for all so that’s what I did. Of course I used my favorite modeling technique: ORM. Below you’ll find the verbalizations of the facts as well as the constraints. This posting ends with a graphical model using the ORM2 notation.
Facts
- Actor has Need
Need is of Actor - Actor interacts with System
System interacts with Actor - Need may be resolved in System
System attempts to resolve Need - Need leads to Feature
Feature corresponds to Need - Feature is documented in Feature list
Feature list holds Feature - Feature is translated to Requirement
Requirement stems from Feature - Requirement is documented in UseCase
UseCase holds Requirement - Requirement is documented in Supplementary Specification
Supplementary Specification holds Requirement - Requirement is implemented in System
System is based on Requirement
Derived Facts
- Need is resolved in System iff Need leads to Feature which is translated to some Requirement which is implemented in that System
- Actor is stakeholder of System iff Actor has Need which may be resolved in that System
Constraints
- Each Need must be of some Actor
- Each Need must lead to some Feature
- Each Feature must correspond to some Need
- Each Feature must be documented in some Feature list
- Each Feature must be translated to some Requirement
- Each Requirement must stem from some Feature
- Each System must be based on some Requirement
- Each System must have some Stakeholder
- Each Requirement must be document in a UseCase or in a Supplementary Specification
- Each Need that may be resolved in a System also is resolved in that System and conversely
- Each Actor that interacts with a System also is a stakeholder of that System
Note that some of these constraints are “ideal world” constraints. For example, the constraint that says that all requirements that can be resolved shall be resolved in a system does (unfortunately) not always hold in the real world that we live in. Either way, I think the above clearly defines terminology as I’d like to use it. I’m going to use this in a presentation that I’ll give some time soon so any comments that you may have are more than welcome. Last but not least: the ORM2 schema (pretty picture!)
I forgot to mention in the above text that this model does not include non-functional requirements. The point is that NF’s can not be mapped (directly) onto features. Including NF’s in the model would thus mean that the mandatory role contstraint on the fact type “Requirement stems from Feature” should be removedl.
very nice; I like the approach. I’d like to see how you flesh out the diagram with more detail about how use cases and requirements relate, and how nonfunctional requirements fit in.