Attendees

Agenda

1. Introductions/Roll Call
2. Action Items Review from last meetings

Follow-up from previous week's action items

• Bob will fold in the header from Ben's document into his page from a format perspective.
• Add affiliate requirement to the enrollment / registration section - Steven.
• Review and make notes in the document with regard to changes / additions / questions - All
• Need a "general bag of requirements" (notifications, reporting etc.). Change notifications to General Enterprise Requirements - (I think Renee did this) - Steven will add some stuff here.
• Consolidate requirements in one page by next Friday then start reviewing gaps. - All
• Need to add information into requirements for registry regarding HR data, at least the core set
• Should add some simple definition of terms at the top of the document, especially for terms that might be ambiguous
• Need to add "calendar-driven" lifeycycle to the requirements list
• Add mention in requirements of non-person entities and that there needs to be a flat namespace across person and non-person entities
• Add a requirement to be able to store "test" users in the registry
  • needs to be some way to distinguish them from the rest of the population
  • need to not be considered in the reconciliation process
• Add explicit requirements about the ability to create entries in the registry for these people who "self-register" (i.e. via federated or other processes)
• Do we need to add any mention to the document about tools that might be needed as part of the whole package? workflow and rules engines?

Notes

• Steve will continue to work on adding affiliate requirements to the enrollment/registration section
• The rest of the group continues to review and make notes in the requirements document regarding questions, additions, suggested changes.
• Steve will add some addition items based on notes he has related to the recently renamed General Enterprise Requirements section
• Benn pulled some items out to put in the main requirements section that are more functional than technical, wondered if we should have 2 separate lists?
  • Consensus was that they are fine where they are and Bob noted that these types of requirements will be needed when we present our list so that we can generate interest in the project beyond the technical requirements.
• Bob/Renee - Based on the list of requirements we already have we can/should start documentatting where KIM, PSU, and Open Registry match up and where there are gaps
• Steve notes that Benn is looking at the differences between then list and Open Registry
  • Benn - Not only looking at what's already in the code, but what's on the future road maps.  Will need Jeremy's input on this as well
• Bob - some analysis on commercial products and their gaps to our current list of requirements would be nice
  • Steve - there a risk in doing this not only from it being a huge time undertaking, but if we are selective about what offerings we look at, there a good chance other vendors would be put off that we didn't look at them as well.  Probably best not to invest the time in commercial products at this time.
• Renee - PSU is looking at using "hibernate" as a starting point for their work
• Bob - based on the remaining work that's needed to be completed and the upcoming holiday, it's unlikely that we'll have a solid document to provide by the Sept. 16 deadline.  Will bring this up in the overall planning group's meeting this afternoon.

{highlight:red}Action Items{highlight}

1. Requirements fit/gaps

   1. {highlight:red}Renee{highlight}

      will do look at PSU's initiative against our list of requirements and note them in the new column on the requirements page

   2. {highlight:red}Benn w/Jeremy{highlight}

      will look at Open Registry against our list of requirements and note them in the new column on the requirements page

   3. {highlight:red}Aaron and Eric{highlight}

      will need to look at KIM against our list of requirements and note them in the new column on the requirements page

   4. {highlight:red}All of the above{highlight}

      will likely need to provide some narrative to go along with the checks that are noted on the requirements page

2. {highlight:red}Bob{highlight}

   will look at what others are building around the Oracle Product and will contact Rob (?) to investigate this.