Specify User Stories
Follow the well-known pattern:- As a <user role> I want to <act> so that <the force>
- One or more actors
- A (verb, noun) pair, representing the activity of the user story
- Don’t miss “so that …”, which tells the intention/goal of the user story and defines the activity.
- Give a theme for each user story for grouping purpose
- As a cashier @csr or a support agent @agent, I can set "blocked-bill" flag @(set block-bill-flag) for a customer account so that he will not receive bills. #(billing/options)
Specify Business Rules
Generally, a business rule is a piece of logic or condition to be applied onto one or more user stories as a constraint, i.e. a business rule corresponds to one or more user stories. A user story notation @(v n) will mark the correspondence.E.g. 1: Require cash drawers to be approved
- All cash drawers in a given fiscal period have to be approved before the earned income process @(proceed earned-income) can be executed.
E.g. 2: Handle result balance
- While upgrading a member's coverage @(upgrade coverage) or adding a new member to a household @(add member), if it results in a balance owing greater than $3 the system will send an ad-hoc bill @(send ad-hoc-bill) to the household; otherwise, the system writes off the small amount @(write-off small-amount).
The "piece of logic" of a business rule can be any type. it could be specifying the "how", providing details on how the activity is conducted; it also could be specifying a "pre-condition", e.g., security rules; it could even be specifying an exceptional scenario, or a "branch" path; yet a business rule can also be just providing information, e.g. a list of available payment methods. Examining business rule patterns over the process of specification would help on defining them and promoting the quality.
In addition, a business rule can introduce activities that could be reference to other user story activities or new extending/subordinate activities. You can use the same activity notation @(v n) used in user stories to denote these extending activities. A extending activity could have applicable business rules, you should describe those rules with the containing business rule so as to avoid complexity. A compound business rule will be split when reuse is applicable (lazy split).
Specifying Screens
Typically, to specify a screen you would include:- An overall description of the screen
- The realization of each user story proceeded through the screen
- Any concerns and user requirements that help UX analyst on user story realization.
- Optionally, include the navigation to the real application page if it would be helpful when you work side by side with the application.
Household Flag Management Page
Admin>Flags >Household Flags. Management of member and household flags.
@(block bills)
1. click Add Household Flags
2. select Block Bill
3. click Update
@(opt-in reward-dollar-renewal)
1. click Add Household Flags
2. select "Reward Dollars Renew"
3. click Update
@(opt-out reward-dollar-renewal)
1. click Flags tab
2. remove "Reward Dollars Renew" flag
2.1 failed/exception
2.1.1 refresh the screen
2.1.2 go to 2
3. ...
Specify Function Models
Comparing to user stories that define the “what”, and business rules that provide the “how”, Function Models realize both the “what” and the "how" through functional decomposition of user stories into functions and reorganize them. These functions are further realized by leverage of routines in other Function Models and by the support of object-oriented routines in Data Models. Function Model is essential in mapping business activities into logical functions. Function Models are business process oriented, i.e. user stories and business functions are put in a Function Model due to their business coherency. One Function Model realizes a set of "related" user stories.Typically, you include following info in the description of a function module:
- A summary, stating the functional scope of a module
- A list of specification for selected user stories
@Administration{
// declare reference to data models and function models
; #directory of data models referenced by this function model
; @directory of function models referenced by this function model
; // directory of user stories to be implemented
; @(... ...)
}
An example of a user story implementation:
@(define price){
//create price lines based on Programs (pricing items)
// the user then can set price for each Program
; organizationPrice.init()
//update a whole set of prices or a single price
; organizationPrice.update([itemId])
//reflect Program changes such as adding new program and
retiring a program ***TBD: reflect program change
// impact on pricing***
; organizationPrice.refresh()
;
; regionPrice.init([!existRegionPrice(regionId)]);
; regionPrice.update(regionId);
; regionPrice.update(regionId, itemId);
}
As we can see, the functional specification for a user story identifies logical activities that need to be implemented by the system. Those logical activities are not listed as a strict process but rather a flexible list, and each of them can be corresponding to certain business events.
Specify Data Models
Typically, a data model consists of a main object and multiple associate objects. Following example demonstrates the Household data model. Notice the notations used in the example, but it is flexible to define one's preferred set.A data model specification starts with a summary - declaration of a list of data entities included in the data model, as shown below:
#HouseholdModel{
, #household
, #members
, #customers
}
Following the summary section is declarations for each data entity. A data entity comprises attributes, referencing-entities, and activities. Use # to demarcate a data entity, e.g., #member. These are specified with following format:
#Type{
, #referencing-entity[*|1|?|+] - to declare association. cardinality: *: 0 .. n, +: 1..n, ? : 0 .. 1, 1: 1 as the default
, attribute - to declare an attribute of a data type or object, : is used to specify a type for an attribute
; activity() to declare an activity
}
e.g.,
#household{
, #primary
, #associate[*]
, #child[*]
, #customer[*]
, paid_thru
, bill_thru:date
; createHousehold()
}
To define meta data, #Type is capital lettered; while to define enumeration or reference, which is to specify instances or values, #enum-type and #ref-type is lower lettered, as further mentioned follows.
use #= to declare an enumeration type, with name in lower case, e.g., #rateType={regular,employee}
use : to specify the type, e.g., .Rate:#rateType
CRUD activities are indigenous to any type.
To specify an activity or a sub-type use a definition block after declared, e.g.,#Household.swap(associateMbrId){
//spcification details
}
For brevity, only specify the key attributes for a data type/object in the data model - those attributes involve logic in the application; don't include the ones that are just for recording information.