[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Things to do - Use Case
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 > -----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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC