Specification Steps
Logically, requirement modeling starts from identifying user stories, then find the business rules that apply to each of the user story. This makes sense since a business rule is always implicitly or explicitly corresponding to an activity or activities, and the activities should come first. Besides, due to “trigger-type” business rules introduce new activities out of user story activities, a business rule could have one or more related business rules as well.Following are some points:
- Split a business rule or an activity only when needed (lazy splitting, a metaphor of cell division in genetics).
- An activity is described in steps, similar to describing a use case where it lists steps from the user interaction perspective even though describing activities is from a perspective of how the task is done.
Naming Guidelines
- Keep consistency in singular or plural while defining meta-data
- Stick to capitalization style, camel or pascal
Model Refinement
Like code refactoring, requirement model needs refinement as well. Following is some commnads that Precise Requirements (c) has for consolidating and refinement:- Change a Feature Name
- Change an Actor Name
- Change an Action Name