Role-Coll Role Based Collaboration Software

Transcription

1 Department of Computer Science University of Nevada, Reno Role-Coll Software Requirements Specification CS /03/2006 Software Team: Harold De Armas, Erik Hanchett, Raymond Lee, Zack Norcross Business Team: Mark Tyman, Max Volger Internal Advisors: Sergiu Dascalu, PhD., Gary Valiere PhD. Page 1 of 20

2 Table of Contents 1 INTRODUCTION REQUIREMENTS FUNCTIONAL Global Music Module NON-FUNCTIONAL USE CASE MODELING USE CASE DIAGRAM USE CASE DESCRIPTIONS DETAILED USE CASES SCENARIOS REQUIREMENT TRACEABILIT MATRIX INITIAL SNAPSHOTS GLOSSAR OF TERMS REFERENCES CONTRIBUTION OF TEAM MEMBERS DE ARMAS ERIK HANCHETT RAMOND LEE ZACK NORCROSS Page 2 of 20

3 1 Introduction The objective of Role-Coll is to be an interactive collaboration product. The proposed product will allow multiple interested parties to have visual input on a document or conversation. However the product will have built in intelligence as to which users input will be displayed by default and which users input to shared only if it is approved by their superior. The aptly named Role-Coll, short for Role-based collaboration software, will allow users to share collaboration freely at their own level and their superiors will be able to filter the input from all of their subordinates. Role-Coll will also incorporate modularity to allow for different modules to be plugged in as the subject of the conversations change. For instance, a music plug-in would allow collaboration from and entire band or orchestra on a single piece of music. Each section would be able to make their own notes on their music and the conductor could filter out only the notes that he saw useful. Collaborative software allows multiple users to contribute to multiple documents in a way that every user contributes to the creation of the document they are working on. This is a very powerful tool because it allows input from a variety of users and the users feel part of the creative process. Collaboration software could be improved in two key areas, by adding roles to each of the users, and by allowing for more variation in the documents that are being collaborated on. Our project will be focused on two key improvements to collaboration software. The first improvement is the addition of user roles. In current collaboration software, everyone is editing the same document, and everyone has the same privileges to do so. With the addition of roles, users are organized in a hierarchy such that there are leaders and subordinates. Another important distinction is that every user has a copy of the document that is unique to them. Everyone may make changes to their document that is not reflected in the collaborated document, much like making liner notes in a real document. The roles come in place when a leader submits a change to subordinates. The change is applied automatically and users have the ability to modify it in their own document. If a subordinate has a modification they would like to make in a document, they would need to submit it to the leader for approval. Then the leader can chose to apply the modification or discard it. The second improvement proposed to collaboration software is that of how a document is defined. Collaboration does not only happen on text documents and whiteboards. Engineers need to create and edit circuit diagrams and using a simple whiteboard would be tedious. The particular interest of this group is music notation. In rehearsals of symphony orchestras, a large collaboration effort is taking place where the document being collaborated on is a piece of sheet music. Sheet music is another unique document that is not easily described by a text editor or a whiteboard. Along with the ability to enforce roles in the collaboration process, the software should also allow for a wider variety of collaboration through the implementation of modules. Role-Coll should come with the standard modules that allow for text editing and use of a whiteboard. Role-Coll should also feature an interface by which a user can create a system the application can use to display, interpret, and modify a collaborative document. Since Role-Coll is a modular project, future developments can include a larger library of modules. Role-Coll might be enhanced to support a wider variety of Page 3 of 20

4 modules that were not thought of in initial conception. A web interface could be created so users can view and make basic changes to the document. 2 Requirements 2.1 Functional Global R Priority Description Role-Coll shall display a collaborative document in the document R01 P1 R02 P1 window. Role-Coll shall display collaborative notes on the document in the document window. R03 P1 Role-Coll shall allow users to hide notes they do not wish to see. R04 P1 Roll-Coll shall allow an administrator to assign roles. R05 P1 Role-Coll shall be able to determine the role of a user upon login. R06 P1 Role-Coll shall have a live collaboration mode to allow concurrent changes to be made to a shared document. R07 P1 Role-Coll shall distribute notes based on role. R08 P1 Role-Coll shall display the connection status of each user. R09 P2 Role-Coll shall support modules geared towards different situations or markets (i.e. Football module, Music module, etc.) R10 P2 Role-Coll shall authenticate users login at login. R11 P2 Role-Coll shall include a panel that allows users to view other users document panel. R12 P2 Role-Coll shall save edited documents and comments associated with them. R13 P3 Role-Coll shall support multiple file formats including but not limited to jpeg, gif, word, excel and text files Music Module R Priority Description R14 P2 Role-Coll shall include a performance mode that will display the musical document using the entire screen. R15 P2 Role-Coll shall associate notes with musical artifacts. R16 P2 Role-Coll shall read in music via xml. Page 4 of 20

5 2.2 Non-Functional R Priority Description T01 P1 Role-Coll shall allow different users different abilities based on role. T02 P1 Role-Coll shall be implemented in Java and C#. T03 P1 Role-Coll shall have a central repository for all documents. T04 P1 Role-Coll shall handle concurrency problems when multiple users are editing the document. T05 P1 Role-Coll shall be able to update any edited document dynamically. T06 P2 Role-Coll shall require at least two networked systems to allow collaboration. T07 P2 Role-Coll shall be available to users both online and offline. T08 P3 Role-Coll shall be cross-platform compatible. Page 5 of 20

6 3 Use Case Modeling 3.1 Use Case Diagram Page 6 of 20

7 3.2 Use Case Descriptions UC Name Description UC01 OpenDocument The user can load a preexisting document by selecting the Open option from the File menu. The user selects the document to load by selecting from a file selection dialog. UC02 SaveDocument The user can save documents they have edited by selecting the Save option from the File menu. The user will enter the name of the file when saving the document. UC03 DiffDocument The user can compare two selected documents to view the differences between the document on their local drive and the document shared between users. UC04 AssignRoles The administrator can assign a role to each user. UC05 ChangeView The user can view the document panel of any user they are superior to. UC06 AddNote The user can add a new note to the current document. This note will be able to be move to any portion of the document. UC07 HideNotes The user can hide notes on the current document. This will still be visible in the note list. UC08 DeleteNotes The user can delete any visible note via either the document panel or the note list. UC09 ViewHelp The user can view instructions for program operation in the Help menu. UC10 Login The user will be prompted to login each time the program is loaded. 3.3 Detailed Use Cases Use Case ID: Actor: Precondition: Flow of Events Postcondition: Use Case : AssignRoles UC04 User 1. A administrator is logged in 1) The administrator will see all users in left hand panel 2) By right clicking on any of the users he will get an option to assign roles 3) After clicking a menu will open up to allow assignment of role 4) User can click save to save the role assignment, or cancel to stop assignment The role is assigned to the user selected Page 7 of 20

8 Use Case ID: Actor: Precondition: Flow of Events Postcondition: Use Case ID: Actor: Precondition: Flow of Events Postcondition: Use Case ID: Actor: Precondition: Flow of Events Postcondition: Use Case : OpenDocument UC01 User 1. A user is logged in and valid 1) The use case starts when the user selects a document from the document list 2) Role-Coll determines the document type 3) If the document type is supported a) Role-Coll uses document information to load the document appropriately b) Role-Coll brings up the appropriate document tools The document is open and ready for editing Use Case: SaveDocument UC02 User 1. A user is logged in and valid 1) The use case starts when the user saves an open document. 2) Role-Coll determines the document type 3) Role-Coll uses document information to save the document appropriately 4) Role-Coll determines the source document and maintains the document history The document is saved and ready for retrieval Use Case: DiffDocument UC03 User 1. A user is logged in and valid 1) The use case starts when the user views a document s history 2) Role-Coll determines the documents type 3) Role-Coll uses document information to load the documents appropriately 4) Role-Coll uses document information to generate a diff 5) Role-Coll displays the diff of multiple documents The documents are open and available for selection. Page 8 of 20

9 Use Case ID: Actor: Precondition: Flow of Events Postcondition: 4 Scenarios Scenario ID: Actor: Precondition: Primary Scenario: Postcondition: Scenario ID: Actor: Precondition: Primary Scenario: Postcondition: Use Case: ChangeView UC05 User 1. A user is logged in and valid 1) A user can see in the left hand panel other users. 2) Double clicking on the user will change the view to the users view panel 3) User can switch back to their view by click their name in the list New view is displayed Scenario: Load S01 User 1. Role-Coll is installed 1) The user launches the program 2) Prompt the user to login 3) The user is authenticated 4) The user s default view loads user view panels 5) The user opens a document The program is open and ready to use Scenario: Exit S02 User 1. A user is logged in and the program is running 1) The user chooses to close the program a) By clicking the x in the top right corner b) By choosing Exit from the File menu 2) The user is prompted to save any unsaved documents 3) The documents are saved if the user chooses to save them 4) The program exits without any errors 5) The user is returned to the operating system Role-Coll is no longer running Page 9 of 20

10 Scenario ID: Actor: Precondition: Primary Scenario: Postcondition: Scenario ID: Actor: Precondition: Primary Scenario: Postcondition: Scenario: Create User S03 Administrator 1. A administrator is logged into the sys-admin portion of Role- Coll 1) The administrator chooses New from the File menu 2) The administrator is prompted to enter a new user ID and password 3) The user is registered and displayed in the users panel 4) The administrator assigns the user to a group 5) The user is registered to the associated group The new user is registered and ready for use Scenario: Create Note S04 User 1. A user is logged in and editing a document 1) The user chooses New from the File menu 2) The user is prompted for the type of new object 3) Note is chosen 4) The user decides where to set the note 5) The user types comments into the note New note has been created for the current document 5 Requirement Traceability Matrix USE CASES REQUIREMENTS UC01 UC02 UC03 UC04 UC05 UC06 UC07 UC08 UC09 UC10 R01 X X X X X X R02 X X X X R03 X X X X R04 X R05 X X R06 X X R07 X X X X X R08 X X R09 X X R10 X X X X R11 X X X R12 X R13 X X X Page 10 of 20

11 6 Initial Snapshots Fig. 1 This screen shot shows an initial look at all of the different view panels. Page 11 of 20

12 Role-Coll Manage Roles - O X File Edit View Etc.. President Vice President Project #1 Leader Project # 2 Leader Project # 3 leader Project # 4 Leader Cronie # 1 Helper # 1 Bashful Cronie # 2 Helper # 2 Doc Cronie # 3 Helper # 3 Dopey Cronie # 4 Grumpy Happy Sleepy Sneezy Fig. 2 This screenshot shows the initial design of admin screen. Page 12 of 20

13 Fig. 3 This screenshot shows a more refined view of the main document screen. Page 13 of 20

14 Fig. 4 This screenshot shows two documents being compared. 7 Glossary of Terms Collaboration Concurrency Database Difference Document GUI To work jointly with others or together especially in an intellectual endeavor The property of systems which consist of computations that execute overlapped in time, and permit the sharing of common resources between those overlapped computations A usually large collection of data organized especially for rapid search and retrieval The element or factor that separates or distinguishes contrasting situations A computer file containing information input by a computer user and usually created with an application Graphical User Interface; the front end of the program where users interact with to use the features in the program Page 14 of 20

15 Key Signature Menu Measure Module Musical Note Musical Staff Repository Role Tool bar Time Signature Use Case Whiteboard XML Real Time The sharps or flats placed after a clef in music to indicate the key A list shown on the display of a computer from which a user can select the operation the computer is to perform A grouping of a specified number of musical beats located between two consecutive vertical lines on a staff Different set of rules, tools, and pictures for a different situation. A written symbol used to indicate duration and pitch of a tone by its shape and position on the staff The horizontal lines with their spaces on which music is written A place, room, or container where something is deposited or stored A function or part performed especially in a particular operation or process. The predefined relative relation to other individuals in a system List of tools available to user to use in the program A sign used in music to indicate meter and usually written as a fraction with the bottom number indicating the kind of note used as a unit of time and the top number indicating the number of units in each measure A use case is a methodology used in system analysis to identify, clarify, and organize system requirements A hard smooth white surface used for writing or drawing on with markers A markup language with use and design similar to HTML but employing tags that indicate the logical structure in addition to the display specifications of the coded data The actual time during which something takes place Page 15 of 20

16 8 References Estand is a music performance assistant tool. It s a tablet pc with built in software that makes it easy to edit or view music. It also includes a foot pedal attachment to allow for easy page turning. It can be used in live performances and has some collaboration tools. It s Role-Coll biggest competitor Imaginationcubed.com is a test site for GE s latest web collaboration tool. It allows for multiple parties to share ideas in a real time whiteboard with others. Users can be invited to join via AOL instant messenger or by . It also has the functionality of replaying or deleting what was drawn Sibelius is a software tool for writing, playing, printing and publishing musical notation. It can be used by anyone, student and teacher alike, to make their music writing easier. It also includes several collections of sounds Finale is a line of products that cater towards the music creator. It allows for complete control over music notation and playback. It also supports both the Mac and PC line of computers The link above is a resource that can be used to develop the editing portion of a document in the application. The white board program allows drawings, for example with a pencil tool, and displays it to both people engaged in the session in real time. The code will help us with how to implement that part of the program. The code only handles a session of two users. Role-Coll will modify it and allow multiple users Open-Xchange is preexisting open source software that already does online collaboration. It has a lot of code for setting up servers to handle different collaboration tasks. Some other features available include: calendars, ing, and more advanced Page 16 of 20

17 functions like forums and bulletin boards. This is a power tool to get Role-Coll up to par with current available software The Babylon chat program is a java chat applet that allows conversations between people like other chat programs. The creator of Babylon released some of the code on this site to help developers. It also has a white board program that can help in the implementation of Role-Coll for our real time collaboration. The program also has some client-server code which will help the networking aspect of Role-Cole. It is written in java so it will not be directly ported over. It can be used as a model for the coding process. 9 Contribution of Team Members 9.1 De Armas Introduction Requirements specification Use case modeling Initial Snapshots Glossary of terms 9.2 Erik Hanchett Requirements specification Use case diagram Glossary of terms List of References 9.3 Raymond Lee List of References Requirements specification Use case modeling Initial Snapshots Use Case Diagram 9.4 Zack Norcross Introduction Overall presentation Requirements specification Use case modeling Requirements traceability matrix Initial Snapshots Scenarios Page 17 of 20

18 Defect Checklist Template for Technical Artifacts Team: 4 Course: CS 425 Project Part: II Note: The notation <X/>, for example <18/24>, indicates that X applies to a team of 3 students, while applies to a team of 4 students. For each check, answer ES or NO Requirements Specification The SRS document has a cover page. the cover page has appropriate information on university, department, course, project title, project part, team name, team members, instructor, and date. has all pages numbered. has a table of contents. the table of contents shows page numbers for all sections and subsections. has an Introduction..the Introduction has at least 400 words and at most 800. Requirements Version no. Review date: Internal Review no. System requirements include at least <18/24> functional requirements. N 16 include <7/9>non-functional requirements. N 8 requirements are organized on 3 levels of priority. functional requirements are related to use cases in a traceability matrix. The use case model contains use cases to initialize and shutdown the application. is not overly complicated. contains at least 7 use cases. contains at least 1 actor. is drawn using the UML notation. Each use case in the use case model consists of a graphical representation in UML notation. a name Page 18 of 20

19 that consists of a verb phrase and conveys the purpose of the use case to reviewers. a meaningful textual description of 2 to 4 lines. actors, each of which is briefly described represents an entity external to the system and has a meaningful name. Each detailed use case is described using a template as in [Arlow and Neustadt 2002]. is initiated by one or more actors. has at least 6 steps. has a unique ID. has pre-condition(s). has post-condition(s). has a normal flow of events. [optional] has alternate flows of events. Overall (regarding detailed use cases) at least <3/4> detailed use cases (with templates) are included in the SRS. Scenarios each scenario relates to a use case. each scenario has a unique ID that relates to a use case is initiated by at least an actor... has at least 5 steps... has pre-condition(s) has post-condition(s) doesn't include if-then-else or loop constructs. Overall (regarding scenarios) at least <3/4> detailed scenarios are included in the SRS. at least one detailed scenario is a primary scenario. Requirements traceability matrix all functional requirements are listed in the matrix. each functional requirement on level 1 of priority is related (traced) to at least 1 use case. each use case is related to at least 1 functional requirement. in the matrix, not all relationships between requirements and use cases are 1 to 1 (that is, relationships N to 1 or/and 1 to N also exist). Snapshots of the user interface at least <3/4> are included in th SRS. each snapshot has a caption Page 19 of 20

20 and a brief description. Glossary of terms at least <15/20> terms are included in the glossary. each term is related to the project's application domain. each term is useful to a non-expert to get a better understanding of the application domain. each term has a description. [optional] some terms have synonyms indicated. [optional] some terms are homonyms (with alternative meanings indicated). List of references at least <4/6> are included in the SRS. each reference has a brief description of between 30 and 60 words. each reference is properly listed such as the reader could get access to it via a web or library search. Checklist (this one!) each check that is not optional has been evaluated and received either a ES or NO answer. at least 1 internal review has been completed. the checklist table (this one) has been included in the SRS or attached to it as an appendix. Contributions of team members each team member is listed. for each team member, the specific sections/subsections (or, if needed, items) of this part of the Project on which he or she has worked are indicated. Other [optional] add checks here Page 20 of 20