Notes for 1/20/09

• Summary of Issues
•   See below
• Decisions
•  See below
• Action Items (w/ person responsible and dues dates)
•  Email reminder to renew monthly license for Blue Print
• Who: Rob
• When: By the end of this week
• Updated BRS by Friday
• Who: Everyone
• When: By lunch on Friday
• Start SRS
• Who Everyone
• When: By tuesday

Intro:
Jen (systems analyst), Brion (programmer), Sarah (systems analyst)

Overview of Project (Phil):
-

Review of Textual Business Requirements (Rob):
-

Review of Definition Visualization (Tom):

Review of Sample Use Cases (Joe):

“User is only able to edit something if they have it locked. Take advantage of SVN’s functionality…”  (Erika)

“It is a likely scenario that multiple users will be editing the same product catalog but different products” (Erika)

• “when the year = 1, the cost is x, when the year = 2, the cost is y”
• this would be fairly common and thus, might be something we need to implement (so no longer will all business rules be notes…)
• Can we solve this problem by making it a specialized/conditional attribute? (Tom)
• She likes the idea of a conditional attribute (“if this attribute is set to this, then this other attribute must be set to this”)

“The other thing to worry about is contract terms, and pricing may be dependent on the contract term. ” (Erika)

“Say you have this product that has this feature that relies on something in this other
project and then you have another version of the product, how do you handle that?”

• a business rule that is referencing features in multiple products
• when you update a product, then do you want the business rule to point to the new product (or to the old product? Or to both? Or user’s choice?) (Mark)
• “there is only one active version of a product at a time” (Brion)
•  
• “should be a maximum of 2 product catalogs being worked on at one time” (Brion)

“Considering removing the requirement to version individual products, since we don’t really need that, and leave everything at the catalog level.” (Erika)

“There won’t ever be a situation where we would want to have a product that exists in multiple catalogs that is updated across catalogs if it is updated in one” (Erika)

“There isn’t really a situation where we would ever add a new product to an old catalog” (Brion)

“It’s probably fine to just have the ability to create a product only when within a catalog” (Brion)

“Still want to be able to compare products across catalog versions. Don’t want to be able to compare products between two different catalogs” (Erika/Brion)

Rob’s idea: (that’s what they do now, so good call)
Product ID – constant
Product version – changes with catalog version

“Our rules don’t cross catalogs”

Some other common business rules:

• depending on region:
• price might be different
• product might or might not be available
• these are more uses for conditional attributes
• attributes that cannot be described via an “if this, then that” sort of situation would then be captured via the notes

“maybe in an ideal world we would lock people out form editing previous versions, but we don’t have to really worry about that” (Brion)
            - functionally there is no difference between old versions and a current version

Each time we make a change to a product we will be having a commit under the hood in SVN.

“Nice to have”

• Merge ability
• Showing commits within catalog

Each entity will have its own file.

Business rules need to be versioned (along with products and product catalogs)

Questions (Mark):

• Do you feel like our definition visualization would be able to fully describe all of your products? (Phil)

• So, what should the default skeleton of an attribute include?

• “Will there be cases where there would be a certain feature or attribute that should be a default in certain situations?” (Rob)
• Yes

They ask:

“Do you think we need a type for the attribute?” (Erika)

• There might be attributes that are strings, so there would not necessarily be a min and max (Erika)

“What do the business rules do?” (Brion)

• Mostly as a commenting system (Phil)
• We should make it a priority to ensure that it is clear when a business rule is associated with any given entity in the defintion (Erika)
• It should be fine for all of them to simply be notes  (don’t want to re-write JRules) (Neil)
• We need to make it so that we can have multiple defaults that do not conflict with one another (i.e. a default price and a default quantity) (Brion)
• Might have to limit the length of the string in string-based attributes (for example some catalogs will only allow a string up to 25 characters length) (Brion)
• Also, numbers might need to have a certain degree of precision (i.e. 2 decimal places) (Brion)

“How does the concept of waivability fit in to this definition?” (Brion)

• waivability – whether or not a feature is applicable based on a certain calculation
• check PAO spreadsheet, features tab