Features and Themes [20150921]
Feature and Theme are two terms often seen used interchangeably for grouping user stories, but there is a slight difference. According to Dicitonary.com, a feature is a prominent function or characteristic; whereas a theme is a subject or topic composition. As such, in Precise Requirements it uses feature for grouping user stories and theme for grouping data. I.e., themes are acronyms of Data Models.This conceptual separation is important, since often functional cohesion is not equal to data cohesion. In EDEN application (the Driver Education), for example, Administration is a feature that includes maintenance functionality on instructors, students, courses, schedules and more, but these constituent entities belong to multiple themes. In Precise Requirements Function Models are identified in corresponding to features/sub-features, whereas Data Models are by themes/sub-themes. Following figures demonstrate themes, features and function models in EDEN application.
Fig. An adoption from Data Model Catalog, demonstrating Instructor and Location themes
Fig. Features and the Corresponding Function Models
Organizing User Stories According to Business Process Decomposition
A user story doesn't live along, it belongs to a feature or theme, yet a strategy for defining themes is largely subjective. One way is using business process decomposition as the strategy, for example, the membership management application realizes the main business processes comprised of member management, coverage management, billing, payment, and GL integration. Majority of user stories can be grouped with this process-area-partition strategy.
Associating Components of the Main Business Process
Yet, some user stories are not belong to a process area included in the main business process. For example, Loyalty and Donation are two business process areas that are not part of the main membership management process, they are just leveraged from the main process as associated components. The user stories falling into these category can still be grouped in the respective "associate" process area.Ordering Features to Build a Process
starting feature names with numbering, such as "2.1.BillingManagement", will result in a ordered feature list, which gives a clear process view of the application.Parameter-oriented business rule elicitation approach
To come up business rules for an activity, think about the parameters and the context of that activity. E.g. @(buy giftCard) activity is proceeded with parameters such as the amount, which has a rule that the amount has to be less than $1000. In another example, @(buy privilegeCard) activity has a parameter memberNo that is subjected to a constraint that only members can buy privilege cards, meaning the memberNo parameter shouldn’t be null. In addition, this activity has a context-regard rule that privilege cards are only sold through the POS, not on the Web. Ultimately, context is a special type of parameter and as such can be translated into primitive parameters, e.g., the aforementioned context constraint can be translated into a parameter constraint of location, i.e. the location parameter that comes in with the activity has to show it is from a POS, not from the web or anything else.
Since all user stories are actually activities, this parameter-oriented method for elicitation of business rules could be very powerful.
Implicit CRUD
In a data model, an object(usually represented by a database table) comes with CRUD operations even though they are not specified explicitly.