Notes for 1/13/09

• Summary of Issues

• Metric Tracking
• For Effort can’t really start until we get something completed
• Who needs to approve schema, so we need to get it approved?
• Project Plan 1.9
• Website still has 1.8
• Estimation Process last sentence
• Get rid of functional point
• Schedule point
• Environment
• IE 6 @ PAETEC develop for 6.
• Make sure everything works fine
• Limited Subset of tools in java. 1.4 unless there was another version
• Use case satisfied may have too much for part 2. Split up, may be too ui centric.
• Consider moving requirements for Stage 3 to right before Stage 3 begins. This way we could have a better idea of what needs to be done for documentation.
• BRS
• Should we use textual requirements or just use Use Cases as the requirements?
• May have requirements that don’t need a Use Case
• If this is not the case, better to just use a Use Case. This way we don’t have to change 2 things.
• Utilize Use Case levels
• Could even use different levels to differentiate between Business requirements and software requirements
• Release 1 requirements would logically be textual requirements. No real business actions for master definition
• Business rules: make a rule and link to associated attributes. Don’t need to necessarily make real dependencies. This way when we look at an attribute, we can see all the things that affect it.
• Changes
• Split the BR12 into 2 requirements
• Adding features to features
• More generalized textual requirements and map those to the more specific Use Cases.
• Test: Product has features
• Use Cases: Adding, Editing, Deleting features
• Be consistent with naming for Products and Services (4 main entities: product, feature, attribute, connection number)
• Pricing can be considered an attribute
• Make sure products can contain products
• Does that mean we need to be able to select existing products? We could just reference the product ID
• Pricing could just be a type of attribute, may not need to make more than 3 entity types
• When we map, we need to cover the case that the product we export has a parent that doesn’t exist in our definition. May need to come up with a way to define a hierarchy in our mappings.
• Part of the custom mappings is being able to remove certain entities that we don’t need.
• Connection number entity could have many numbers (circuit numbers) listed in it
• Make it explicit that when we create a new version of the product, it links to the old version and a new product is created in the definition that is populated with the old information
• Make Use Cases a tree, View product catalog could be base case
• Actors
• Analyst
• Marketing
• Developer
• Can add comments by right clicking on steps within Use Cases

• Decisions
  • Investigate moving SVN to linus
  • Change the word “service” to products in documentation to avoid confusion
  • Every Thursday meeting revisit the risk document
  • Try getting documents done for Monday morning, rather than Tuesday morning.
  • No authentication! Design so it is easy to add.
• Action Items (w/ person responsible and dues dates)

• Move SVN over to linus
• Who: Joe
• Due: 1/20/09
• Get estimation up so we can use for comparisons
• Who: Phil
• Due: 1/13/09
• Look at links Scott sent
• Create a visualization of how the master definition works, as a prelude to showing the BRS.
• Get our schedule up on the website in a form that it does not need to be downloaded
• Who: Tom
• Due: 1/16/09
• Be at PAETEC by 4pm on Tuesday for BRS meeting

• SEND AGENDA
• Phil and Rob
• DUE 6pm 1/14 !!!!!!
• Prepare for meeting, etc
• Questions
• Show definition decisions
• Xml schema, SQL?
• Show visualization of definitions
• Show Use Cases, etc.
• All other deliverables
• Who: Team
• Due: Monday morning!!!!!