Recently I have been doing requirements in a few separate places. I got the notion into my head that there was no good notation for describing requirements, particularly non-functional requirements. UML has a diagram for use cases, but no diagram for requirements per se.
So this is the legend of the notation I drew up:
In the Critical Factors Analysis method, your identify three classes of requirements: the goals that you want to achieve, the critical factors and conditions that must be satisfied to achieve the goals and the measurable requirements on the solution that will meet the goal. This methodology is powerful primarily because it can act as a forcing function to ensure completeness of requirements.
I have had difficulty in getting people to understand the difference between goals, CFAs and requirements. I have also had difficulty getting people to distinguish requirements from solutions! (Everyone has their favorite piece of technology that absolutely must be part of the final product.
My take is that requirements are problems to be solved, not solutions. Preferably, these problems are problems that customers have; not problems developers have!
Diagrams like this
can act as very effective indexes into a textual description of the factors that go into a successful project.
So this is the legend of the notation I drew up:
In the Critical Factors Analysis method, your identify three classes of requirements: the goals that you want to achieve, the critical factors and conditions that must be satisfied to achieve the goals and the measurable requirements on the solution that will meet the goal. This methodology is powerful primarily because it can act as a forcing function to ensure completeness of requirements.
I have had difficulty in getting people to understand the difference between goals, CFAs and requirements. I have also had difficulty getting people to distinguish requirements from solutions! (Everyone has their favorite piece of technology that absolutely must be part of the final product.
My take is that requirements are problems to be solved, not solutions. Preferably, these problems are problems that customers have; not problems developers have!
Diagrams like this
can act as very effective indexes into a textual description of the factors that go into a successful project.