[Building Sakai] Terminology clarification [was: Groups Call]

John Norman john at caret.cam.ac.uk
Fri Jun 19 04:45:31 PDT 2009 

This makes sense to me. Although I find it interesting that the actor  
is omitted in the short 'use case' examples. Is it really the same  
thing for an institutional admin to find a TA as it is for (say) a  
student to find a TA?

I might venture an alternative suggestion:

A use case consists of a succinct action and (optionally) a number of  
scenarios.

This allows a focus on Paul's 'verbs K2 must support' (succinct  
actions) and the scenarios as described, while producing something  
more complete for the thing I expect to find when I look up a use case.

I''m not really invested in the semantics, so long as we create the  
information we need to get the job done :-)

John

On 18 Jun 2009, at 23:39, Daphne Ogle wrote:

> Hi all,
>
> Reading this message I realize there are many different definitions of
> use cases.   As we talk through requirements for this project, I think
> we should all have a shared language so I'll propose one that I've
> been using as we prep for this project and see what others think.
> These definitions loosely come from the Unified Modeling Language
> (UML) perspective along with UCD.
>
> 1)  Use cases are high level functional requirements:  http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
> They are an abstraction of the stories we have been currently
> capturing in all the places mentioned below.  I call those stories
> scenarios.  I've been thinking of use cases as abstract patterns we
> find across all these scenarios (and our institutions).  They are an
> action and a noun (at minimum) that describe what the user needs to
> get done in the system.  It's tempting to get more granular and
> context specific with use cases but I think those details can be
> captured in other ways.  In a team meeting this morning we put loose
> parameters on ourselves that the use cases could not be longer that 5
> words to help keep us at an abstract level.  Paul at CSU described the
> verbs as those things that the kernel has to support and I think that
> makes a lot of sense.  The details in scenarios (below) are how it
> needs to get done.
>
> 2)  Scenarios (some of what is in the Kernel and Group spaces) are
> stories about users getting work done in context.  They help us
> understand *how* the functional requirements need to implemented.
> Scenarios may be a concrete example of one use case but more likely
> are a string of use cases the user needs to complete an activity.
> These rich stories are what will drive the UX design since those
> contexts and workflows are so important to the system enabling users
> to get their  work done in ways that make sense to them.
>
> To share a concrete example:
> Scenario:  Catalina is prepping for the upcoming year and the new
> Teaching Assistants for Spanish 1 she'll be managing.  She needs to
> identify who all the TAs are and add them to her "TA knowledge sharing
> group" which she started 2 years ago.   Once she's added them to the
> group, they'll have access to the collaborative space the group has
> been using to share information, discuss class details and work on
> course materials together.
>
> Use Cases we can pull from the scenario: 1)  find TAs,  2) Add TAs to
> group, 3) Invite TAs to collaborative space, 4) Send message about
> group and space use 5) Find group space
>
> How do these definitions sit with you all?
>
> -Daphne
>
>
> On Jun 18, 2009, at 7:54 AM, Oliver Heyer wrote:
>
>> The below off list conversation evolved from working out the  
>> logistics
>> of a synchronous meeting across disparate time zones to topics of
>> general interest, including questions of project planning and the
>> current state of groups-related work on the K2 demo server at
>> http://131.111.21.17:9090/dev/index.html. If you start at the bottom,
>> everything should flow pretty well from Matt's initial question, even
>> though the indentation hierarchy is off.
>>
>> The call we are having Thursday PM/Friday AM will allow CSU in
>> Australia
>> to explore their interest in participating in the nascent groups
>> project
>> at a somewhat less ungodly hour than last Monday's would have
>> required.
>> For others wishing to join in today, here are the details:
>>
>> (2pm Thurs US West Coast / 5 pm US East Coast/ 10pm Thurs Cambridge /
>> Fri
>> 7.00 am Sydney).
>>
>> Telephone: +1-812-856-7060
>> Internet:156.56.240.9
>> Conference Code: 348#
>> PIN: 72524#
>>
>> Oliver
>>
>> -------- Original Message --------
>> Subject: 	Re: Groups call
>> Date: 	Wed, 17 Jun 2009 23:18:07 +0100
>> From: 	Ian Boston <ieb at tfd.co.uk>
>> To: 	Oliver Heyer <oliver at media.berkeley.edu>
>> CC: 	Morton-Allen, Matt <MMorton-Allen at csu.edu.au>, Michael Korcuska
>> <mkorcuska at sakaifoundation.org>, Bristow, Paul <PBristow at csu.edu.au>
>> References: 	<C65F96A4.12CF4%mmortonallen at csu.edu.au>
>> <4A396817.1040304 at media.berkeley.edu>
>>
>>
>>
>> Looking at [1] "Manage Site Members" and "Add Site Members" have  
>> roles
>> which in K2 terms are groups associated with the site. There is  
>> detail
>> missing here since there is no information on how the roles are
>> configured or the permissions managed. I suspect that there has been
>> an assumption in these screens that that happens by some other
>> mechanism.
>>
>> If another group was associated it would appear in the list with
>> Student, Teacher, Instructor.
>>
>> but, I think the set at [1] is not complete or upto date, I will  
>> still
>> need to check with Nico.
>> Ian
>>
>> [1] http://confluence.sakaiproject.org/confluence/x/noVDAw
>>
>> On 17 Jun 2009, at 23:03, Oliver Heyer wrote:
>>
>>> Pedantic is good in my book, Matt. There's some more detail between
>>> 1 and 2, but I'll leave that discussion for the call.
>>>
>>> BTW, I do not see any existing non course group management screens
>>> on http://131.111.21.17:9090/dev/ or at http://confluence.sakaiproject.org/confluence/x/noVDAw
>>> . I do see the Connections list for the dashboard, and the Site
>>> membership list. Should I be looking elsewhere, Ian?
>>>
>>> Oliver
>>>
>>> Morton-Allen, Matt wrote:
>>>> Sorry to be pedantic, but just to check that I'm on the same page a
>>>> summary of what's being proposed is that we:
>>>>
>>>>
>>>> 1.  Capture as many relevant use cases as we can over the next X
>>>> time period (X being < "circa end of Sep")
>>>> 2.  Translate those use cases into requirements
>>>> 3.  Select (presumably) a sub-set of those requirements we'd like
>>>> to have included by "circa end of Sep"
>>>> 4.  Identify those of #3 that are already part of K2 and modify if
>>>> needed
>>>> 5.  Identify those of #3 not already part of K2 and implement
>>>> 6.  Work with the UX folks to implement a "front end" for #4 and #5
>>>>
>>>> (note that steps 4,5,6 would all run with some degree of
>>>> parallelism)
>>>>
>>>> Is this right? If it is (or even reasonably close to right) then it
>>>> makes a lot of sense to me.
>>>>
>>>> Cheers
>>>> Matt
>>>>
>>>> On 18/06/09 5:52 AM, "Ian Boston" <ieb at tfd.co.uk> wrote:
>>>>
>>>> Oh sorry,
>>>> IIRC
>>>> If I remember correctly.
>>>> Ian
>>>> On 17 Jun 2009, at 20:07, Oliver Heyer wrote:
>>>>
>>>>
>>>>> IIRC?
>>>>>
>>>>> You have described *the* fundamental design challenge we face
>>>>> below.  :-)
>>>>> Oliver
>>>>>
>>>>> Ian Boston wrote:
>>>>>
>>>>>> That sounds good.
>>>>>> My drift.
>>>>>> IIRC there are already some non course group editing screens.
>>>>>> Groups that integrate as dynamic groups with an SIS will require
>>>>>> one or 2 extra properties from a technical perspective.
>>>>>> Having 2 places where you edit group associations with sites,
>>>>>> would
>>>>>> IMHO be a bad thing, but making the project site group UX complex
>>>>>> would be bad.
>>>>>>
>>>>>> As you can see I  don't know a great deal about the UX, so as  
>>>>>> long
>>>>>> as you are in close collaboration thats great.
>>>>>>
>>>>>> Ian
>>>>>>
>>>>>> On 17 Jun 2009, at 19:00, Oliver Heyer wrote:
>>>>>>
>>>>>>
>>>>>>> Not sure if I'm catching your drift, Ian, but, yes, I think
>>>>>>> integrated in the right way will require close collaboration and
>>>>>>> frequent, open communication. Quite apart from any formal
>>>>>>> structures, we'll either band together as necessary or fail. It
>>>>>>> will also require a willingness and capacity to iterate over
>>>>>>> designs and code for a good long stretch.
>>>>>>>
>>>>>>> Oliver
>>>>>>>
>>>>>>> Ian Boston wrote:
>>>>>>>
>>>>>>>> That sound great, I agree getting the UX right is really hard,
>>>>>>>> and I know I am not the right person to be in that space, 4
>>>>>>>> years
>>>>>>>> of training in Mechanical Design Engineering and a year at Fine
>>>>>>>> Art school sadly didn't equip me for 2D UX.
>>>>>>>>
>>>>>>>> Are the Sakai3 UX/UI team getting involved with this  
>>>>>>>> initiative,
>>>>>>>> it would seem critical to its success to have something this
>>>>>>>> core
>>>>>>>> to the UX integrated in the right way?
>>>>>>>>
>>>>>>>> Ian
>>>>>>>>
>>>>>>>> On 17 Jun 2009, at 18:02, Oliver Heyer wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Right, my response was largely framed in terms of the UI.
>>>>>>>>> That's
>>>>>>>>> intentional, because I know that there is a strong desire to
>>>>>>>>> have user facing capabilities driven by UX, even those that
>>>>>>>>> rely
>>>>>>>>> on fundamental enterprise services. Plus, I already know how
>>>>>>>>> hard it will be to get the UI right. :-)
>>>>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>> Oliver,
>> Some of the services you mention already exist in K2, although they
>> have not been exposed in the UI.
>> There is also a complete (almost complete) suite of administration
>> utilities written in perl to perform back end push based integration,
>> as you can see from the performance testing that has been done [1]
>> The pull based integration for groups has been in for a while and I  
>> am
>> in the process of hooking up to a SOAP end point at the moment.
>> As I say, I have a feeling that the functionality is there, it just
>> hasn't been addressed in the UI, partially because the setup for many
>> of these types of sites is a provisioning operation rather than a Web
>> UI operation.... but it still needs a UI for some schools.
>>
>> Ian
>>
>>
>> [1] work in progress: http://confluence.sakaiproject.org/confluence/display/KERNDOC/225+-+Scalability
>>
>> On 17 Jun 2009, at 17:20, Oliver Heyer wrote:
>>
>>> To Michael's reply I would add that we and the community need the
>>> system to do many very familiar things that ultimately involve
>>> groups of users. The team working on groups will not be able to
>>> build out all of these capabilities by itself over the next 6 months
>>> or year. Our next order of business is to circumscribe the scope for
>>> what group management functionality we can design, build and
>>> integrate with the prototype at http://131.111.21.17:9090/dev/index.html
>>> between now and circa the end of September. The available contexts
>>> to build on top of in the K2 prototype are limited, which is
>>> probably a good thing, at least in terms of establishing a place to
>>> get started. For example, we have no assessment workflow yet, nor is
>>> there a system administration area. Some logical first step options
>>> we do have include a basic group member picking UI within the site
>>> membership page (which may prove highly reusable as a UI design
>>> pattern) and a way to represent those groups vis a vis the
>>> comprehensive site membership list; the service and UI for attaching
>>> SIS provided groups to a site etc. That work will more than likely
>>> affect and require changes to some of the existing designs you now
>>> see on the above demo server. Similarly, as other contexts emerge
>>> and our attention turns to them, anything that's previously been
>>> designed and built by the groups team will be subject to further
>>> change.
>>>
>>> Looking forward to chatting.
>>>
>>> Oliver
>>>
>>> Michael Korcuska wrote:
>>>> No, you're not missing anything Matt. Use cases aren't
>>>> requirements, as you say, although they are a crucial test to make
>>>> sure the requirements actually meet the need (as well as providing
>>>> a way for less technical users to participate in the process).
>>>>
>>>> I'd say the project probably should add the creation of a
>>>> requirements document to the list. There is good thinking to start
>>>> that work here:
>>>>
>>>> http://groups.google.com/group/sakai-kernel/browse_frm/thread/ce886f6325c7b492/fe5ba882f4c3c0c9?lnk=gst&q=sites
>>>> +and+groups#fe5ba882f4c3c0c9
>>>>
>>>> and here:
>>>>
>>>> http://groups.google.com/group/sakai-kernel/browse_frm/thread/e9d6d13abbbd96dc?hl=en&tvc=1&q=Authorization+and+Relational+Indexes
>>>>
>>>> (man, Sakai 2 URLs don't look so bad....)
>>>>
>>>> Other sources for requirements:
>>>>
>>>> * Oxford's hierarchy work
>>>> * IMS LIS
>>>> * Existing Sakai 2.x CM implementation (although we should be
>>>> careful about what we take forward)
>>>>
>>>> Getting this thinking consolidated into a single requirements
>>>> document that people could read would be a great contribution from
>>>> someone :-).
>>>>
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>>
>>>> On Jun 16, 2009, at 23:47, Morton-Allen, Matt wrote:
>>>>
>>>>> Thanks Oliver.
>>>>>
>>>>> I think my issue here is trying to see the forest for the trees.
>>>>> There's a lot of use case / user story like material here, which
>>>>> is good, but which isn't quite the same thing as the requirements
>>>>> that ultimately come from these kinds of documents. Consequently
>>>>> I'm having some difficulty in identifying what it is you need the
>>>>> system to actually do which in turn makes it difficult for me to
>>>>> match between the GA Tech / CSU requirements (and Cambridge  
>>>>> model).
>>>>>
>>>>> From this I suppose what I don't have straight in my mind at the
>>>>> moment is the following:
>>>>>
>>>>> a) how/when/where these use cases will be consolidated into
>>>>> implementable requirements?
>>>>> b) how those requirements will be mapped against those the K2
>>>>> design currently facilitates?
>>>>> c) how/where/when the outcomes from B are integrated into the code
>>>>> that's currently referred to as "K2"?
>>>>>
>>>>> I've copied Michael in as it's likely that much of my uncertainty
>>>>> relates to community process and how the move from K2 + 3akai to
>>>>> foundation S3 is going to work.
>>>>>
>>>>> Cheers
>>>>> Matt
>>>>>
>>>>> P.S. Yes, sorry about the "subject" trick, it hurts our brains to
>>>>> think of "course" sites as this is something entirely different
>>>>> for us. :)
>>>>>
>>>>>
>>>>> On 16/06/09 10:14 AM, "Oliver Heyer" <oliver at media.berkeley.edu>
>>>>> wrote:
>>>>>
>>>>> Matt,
>>>>>
>>>>> Yes, I have seen that google page. From our end, I would point you
>>>>> again to
>>>>>
>>>>> http://confluence.sakaiproject.org/confluence/x/FIJDAw
>>>>>
>>>>> particularly the Federated AuthZ link at the bottom. We have not
>>>>> attempted a comprehensive high level description of our current
>>>>> site
>>>>> hierarchy, SIS/ID management integration, course life cycle etc
>>>>> requirements at UCB. I *think* the CSU reqs on the K2 page are
>>>>> familiar,
>>>>> even with that neat trick of calling course sites "subject
>>>>> sites."  :-)
>>>>> I'm not sure if the CSU requirements have been adequately
>>>>> represented or
>>>>> accounted for in the use cases we've compiled thus far. If the
>>>>> above
>>>>> link leaves you with more questions than answers, when we chat I
>>>>> hope to
>>>>> clear them up or figure out which ones we still need to provide an
>>>>> answer for.
>>>>>
>>>>> Oliver
>>>>>
>>>>> Morton-Allen, Matt wrote:
>>>>>> Oliver,
>>>>>>
>>>>>> BTW I'm not sure if you have seen these or not but Ian's put up a
>>>>>> page on the basics of the CSU group requirements here:
>>>>>>
>>>>>> http://groups.google.com.au/group/sakai-kernel/web/csu-site-user-and-groups-requirements?hl=en
>>>>>>
>>>>>> Is there an equivalent for the Berkley ones we can look at?
>>>>>>
>>>>>> Cheers
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>>
>>
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe at collab.sakaiproject.org
>> with a subject of "unsubscribe"
>
> Daphne Ogle
> Senior Interaction Designer
> University of California, Berkeley
> Educational Technology Services
> daphne at media.berkeley.edu
> cell (925)348-4372
>
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

More information about the sakai-dev mailing list