RE: Things to do - Use Case

[Krishna Sankar <ksankar@cisco.com>]

Michael,

	Again good thoughts. Thanks for raising the point.

	The use cases should not be imaginary at all ! That is why they should come
from all of us plus (as per your excellent suggestion), from vendors, across
the globe.

	I think we have, folks from govt agencies, legislative folks, security
folks, people who are running elections and people who know elections in UK,
Europe, in the TC. And they are the ones defining the use cases &
requirements. Then we can seek the help of technology, XML, other standards
et al to translate this vision into a set of specifications and
implementations.

	Like it was pointed out during our last con call, we would have very crisp
but non-technical requirements and use case documents.

	Again, as a call to all of us, please send to the list the scenarios and
actors from your experience and also from your vision. In addition, please
send the requirements as well. Plain English would do, bullet points would
do, or references to other documents would be fine as well. If we have
product specs from vendors in this domain, let us collect them. We can then
turn them into UML (use case) notations and explanations easily.

cheers

|-----Original Message-----
|From: Michael Zolotarev [mailto:michael.zolotarev@baltimore.com]
|Sent: Wednesday, June 13, 2001 7:04 PM
|To: Michael Zolotarev; 'Krishna Sankar';
|'election-services@lists.oasis-open.org'
|Subject: RE: Things to do - Use Case
|
|
|<<Sorry, folks, please ignore the previous message. Wrong button pressed
|when switching between emails :(. Here is goes again.>>
|
|Krishna,
|
|To make everything simpler and easier for us, and to simplify adoption of
|the results by the vendors:
|why don't we, instead of generating imaginary use cases, ask the vendors to
|provide us with their existing use cases?
|
|I think it's gonna work. The vendors know better the problem area,
|in theory
|and in practice. And it is in their own interests to see us (the OASIS TC)
|making progress. So I do expect some feedback here.
|
|Now, when we have a number of use cases from different vendors, we can
|identify a subset which deserves standartisation, to ensure
|interoperability
|between the vendors. And concentrate on what we are good at - structured
|tokens :)
|
|Opinions? Any vendors out there listening?
|
|Regards
|Michael
|
|
|
|>
|> > -----Original Message-----
|> > From: Krishna Sankar [mailto:ksankar@cisco.com]
|> > Sent: Thursday, 14 June 2001 3:31
|> > To: Michael Zolotarev; election-services@lists.oasis-open.org
|> > Subject: RE: Things to do - Use Case
|> >
|> >
|> > Thanks. Good thoughts. I will add the actors and make changes
|> > in the related
|> > processes.
|> >
|> > On a related note, would like to get your ideas for security in the
|> > requirements document.
|> >
|> > cheers
|> >
|> > -----Original Message-----
|> > From: Michael Zolotarev [mailto:michael.zolotarev@baltimore.com]
|> > Sent: Tuesday, June 12, 2001 10:34 PM
|> > To: Krishna Sankar; election-services@lists.oasis-open.org
|> > Subject: RE: Things to do - Use Case
|> >
|> >
|> > A few comments:
|> >
|> > Voter registration: a voter should be able to de-register and change
|> > registration details
|> >
|> > One more thing to keep in mind when producing use cases: I
|> > anticipate a case
|> > where a voting system itself may not be responsible for actual
|> > counting/processing the votes. It'll be responsible for the voters
|> > management, ballots presentation, and votes
|> > collecting/storing/exporting.
|> > The actual counting will be performed by a central government
|> > agency, for
|> > instance. This way we may have a number of different (local)
|> > voting systems,
|> > by different vendors, all running a single election,
|> collecting local
|> > results, processing regional voter's force, and passing
|> > collective results
|> > to the election HQ.
|> >
|> > And another one: statistics. A voting system must be able to
|> > export the
|> > collected votes, and optionally voter details (but not the
|> > identity!), so
|> > that statistics can be generated from the election results.
|> >
|> > Michael
|> >
|> >
|> > > -----Original Message-----
|> > > From: Krishna Sankar [mailto:ksankar@cisco.com]
|> > > Sent: Wednesday, 13 June 2001 6:14
|> > > To: election-services@lists.oasis-open.org
|> > > Subject: RE: Things to do - Use Case
|> > >
|> > >
|> > > Hi all,
|> > >
|> > > 	We need the actors and the actions/scenarios for
|> > > building the use case. The
|> > > use cases should capture *all* the interactions/processes we
|> > > plan to support
|> > > plus any out-of-band but relevant processes.
|> > >
|> > > 	As a start, here is what I have (I will start the use
|> > > case diagram and add
|> > > it to a word document):
|> > >
|> > > 	Voter	- Votes
|> > > 		- registers
|> > >
|> > > 	Voting system - Authenticates voter
|> > > 			  - Authorizes Voter
|> > > 			  - accepts and stores vote
|> > >                     - counts votes
|> > >                     - communicates results
|> > >                     - registers voters
|> > >
|> > >       News organization - accepts results
|> > >
|> > >       Govt Agencies - provide voter authentication
|> > >                     - provides voter authorization
|> > >
|> > > 	Please add your thoughts, ideas and experience. The XML
|> > > structures we
|> > > develop would be to support these scenarios for example a
|> voter reg
|> > > structure, a vote structure, authentication structure (from SAML),
|> > > authorization structure (from SAML), ...
|> > >
|> > > cheers
|> > >
|> > >
|> > >
|> > > This footnote confirms that this email message has been swept by
|> > > MIMEsweeper for the presence of computer viruses.
|> > >
|> >
|> >
|> > --------------------------------------------------------------
|> > --------------
|> > -------------------------------------
|> > "How can I make sure the right people get access to the right
|> > resources
|> > and business applications, with a user base that's constantly
|> > growing and
|> > changing?"
|> > The answer...
|> > Baltimore SelectAccess
|> > Next Generation Authorisation Management
|> > http://www.baltimore.com/selectaccess/index.html
|> > --------------------------------------------------------------
|> > --------------
|> > -------------------------------------
|> > The information contained in this message is confidential and
|> > is intended
|> > for the addressee(s) only.  If you have received this message
|> > in error or
|> > there are any problems please notify the originator
|> immediately.  The
|> > unauthorized use, disclosure, copying or alteration of this
|> message is
|> > strictly forbidden. Baltimore Technologies plc will not be
|> liable for
|> > direct,
|> > special, indirect or consequential damages arising from
|> > alteration of the
|> > contents of this message by a third party or as a result of
|> > any virus being
|> > passed on.
|> >
|> > In addition, certain Marketing collateral may be added from
|> > time to time to
|> > promote Baltimore Technologies products, services, Global
|> > e-Security or
|> > appearance at trade shows and conferences.
|> >
|> > This footnote confirms that this email message has been swept by
|> > Baltimore MIMEsweeper for Content Security threats, including
|> > computer viruses.
|> >
|>
|