Defining Use Cases for Federating Library Services

[LLG5 <>]

Comments below.
On Aug 5, 2009, at 3:44 PM, T. Howell wrote:

> Hello everyone,
>
> Initially I'd like us to address and edit this template so that we  
> can move
> beyond the draft stage. Once we are done editing this via e-mail I  
> will
> update the wiki myself. Please make changes directly to e-mail for  
> group to
> avoid issues with word processors, and please feel free to delete  
> this part
> of the message so that we can simply focus on the text below the  
> dotted
> line.
>
> We will determine on Friday whether or not this is sufficient in  
> explaining
> each field and if it is we will then count this as completed and  
> move on to
> also finalize the other existing cases. The next e-mail will only  
> contain
> the EZProxy - Shibboleth case. I'd like for us all to feel comfortable
> enough to move on to other models and cases after this Fridays  
> meeting.
>
> Sincerely;
> Thomas Howell.
> Lead Web Developer and Systems Analyst
> Northwestern University Library Technology Division
>
>
> -------------------------------------------------------
> Model Name :
> Short name to identify common model used by a collection of use  
> cases with
> at least one condition in common.
>
> Description of the Model:
> Long description of the common model used by a collection of use  
> cases, is
> an extended explanation of the Model Name.
>
> Model Use Cases (Basic) :
> 1.
>   Use Case Name :
> Short name to identify a specific use case.
>   Use Case Description :
> Long description of the specific use case.
>   Primary actor(s) :
> What parties have an interest in the process. [ie. patron, community  
> member,
> etc]
>   User Type :
> What types of users are involved? [ie. admin, editor, content  
> maintainer,
> user]
>   Technology Type :
> [Do we want to retain this attribute?]

        I would vote to remove the Technology Type.
>   Vendor Type :
> [Do we want to retain this attribute?]
	I think basic model should be the most generic case and not specify a  
vendor.  More advance case may have to include a vendor attribute.   
For example, the LMS case may have to advance cases for each vendor.

>   Precondition :
> What set of conditions are necessary to support the described model.
>   Trigger :
> What event causes the workflow to begin.
>   Basic flow :
> What events or tasks comprise the workflow after it begins.
>
> Model Use Cases (Advanced) :
> [Do we maintain this differentiation from basic and if so do we have  
> any
> different or additional attribute for the use case?]
> 1. Use Case Name :
>   Use Case Description :
>   Primary actor(s) :
>   User Type :
>   Technology Type :
>   Vendor Type :
>   Precondition :
>   Trigger :
>   Basic flow :