Component Correspondence

The five components in Precise Requirements (C) framework have relationships, which represent a deriving sequence that can guide our modelling steps. As shown in the figure, the modelling starts by identifying user stories and actors; a user story is executed by one or more actors, and an actor can be responsible for conducting one or more user stories. Next, identify business rules and screens; both of which have to correspond to one or more user stories. Then, identify function models, which directly correspond to one or more user stories and indirectly correspond to one or more business rules (through user stories). Lastly, identify and specify data models. Notice, specifying data models is a bottom-up development - from the problem scope and domain instead of from use cases and business processes. Plus, comparing to other components, data model development is object oriented. Function models and data models bridge the gap between the business world and the solution world.



Specifying Interrelationship

Precise Requirements (C) framework has following meta-data/markups to support on creating linkage among components when annotated in component descriptions:
  • User stories are tagged with an activity @(v n)
  • Business rules correspond to user stories through @(v n)
  • Screens correspond to user stories through @(v n)
  • Functional models correspond to user stories through @(v n)
  • Data models correspond to Functional Models through #n

Team Work

Requirement modelling is a collaborative effort. Usually, user stories, business rules, and screens are done by for BAs and SMEs, whereas function models and data models are more works for solution designers and developers. In a team environment, JAD sessions can be an effective approach for requirements modelling.