Draft Requirements 1/3/2001 (based on requirements 6/24/2000)

Basic Information

  1. Stellar is intended to be a courseware system for use throughout MIT.

Architecture

  1. The architecture of Stellar is a basic three-tiered architecture, with webserver, Java servlets, and database.
  2. We plan to use Oracle.  We also expect to be able to use other JDBC relational databases (e.g. mysql, hypersonic SQL, etc.)
  3.  We plan to use Apache with SSL.  It should be possible to use other webservers, although there is no current plan to do so.
  4. We expect to use Java for implementation.
  5. Design documentation is available on the web at <http://web.mit.edu/stellar/docs>, <http://web.mit.edu/stellar/ui/demo>, and <http://web.mit.edu/stellar/design1>.

Integration

  1. There are several ways to make an addition, enhancement, or integrating another system with stellar.  First, for legacy systems such as MITSIS, is possible to develop "translation" programs to accept external data feeds or to provide data from stellar to legacy system.  Second, there is the "loose" integration provided by a web reference (link).  Stellar will define a number of such linkable entities.  Third, it is possible to read the Stellar code and make additions or enhancements by writing them.  Note that the central MIT stellar service will not necessarily accept all external code for operation.  See also <http://web.mit.edu/stellar/design1/interfaces.doc>
  2. What APIs, libraries, interfaces, public classes, etc. are available to use in integrating stellar with MIT infrastructure and systems?  This will be determined later (TBD).
  3. What programmer documentation, tools, and training are available?  We will need to make such available (TBD)

Operation and Maintenance

  1. What is the support and maintenance model?  TBD
  2. Where do you expect us to host the system?  Currently we expect to host Stellar on EMCC systems.  With further development and use of the system, we may want to set up independent "server farm."
  3. Who will do maintenance and service of the system?  At present, this will be done through the EMCC.  Again, with further growth of system use, we may hand off this work to another group at MIT.
  4. What operational support is needed? Describe both the content creation and maintenance and the technical support needed.

Content creation within stellar can be done by faculty, TAs, or other individuals designated as content developers.  It can be done using standard tools such as Microsoft Word, Dreamweaver, text editors, etc. with files uploaded into stellar.

TBD on maintenance and technical support needed.

Intellectual Property

  1. Content ownership -- if we are using your system, where does ownership of the content reside?

While Stellar does not impose a policy concerning ownership of content, it does provide ways to protect content and track access.  We expect that Stellar will be used at MIT for content which has very limited access and for content with unlimited access.

  1. What protection and services for intellectual property rights does your system offer?

First, Stellar provides relatively fine-grain content management, with the possibility of limiting access using groups, individual user profiles, and ACLs.  The same security features that offer positive identification of individuals (authentication through Kerberos, X.509, and user name/password) help to protect the information from unauthorized access.

While Stellar does not currently expect to build services for IP rights management, we believe the arc approach would make such services comparatively easy to construct and integrate.

Features

What features or functions do you provide in the following categories: (some examples are included for illustration only)

  1. Registration: class membership list, authentication, authorization
  2. Administration: gradebook, student records
  3. Navigation: calendar, syllabus, table of contents, index, portal, search
  4. Content Management: formats (HTML, video, audio, PowerPoint, etc.), Metatags, efficient storage and retrieval
  5. Collaboration: threaded discussion, chat, instant messaging, shared whiteboard, etc.
  6. Query and Evaluation: quiz, test, examination, survey, assessment, problem sets, etc.
  7. Set up: file and directory, database, access control lists, etc. initialization
  8. Content Creation: tools for content creation, upload, transformation, metatagging, crosslinking, editing, etc.
  9. Renewal: archiving, semester rollover, etc.
  10. Other (Please describe the areas):

Please see the specs and <http://web.mit.edu/stellar/design1/> for further details.  However, this is the basic architecture and components of Stellar. 

We do not currently plan to implement a portal, although we are expecting to work with the Jasig portal and with other portals in the near term.

Costs

Please explain the pricing of your system. For this estimate, assume that we are setting up a single server, with 1,000 students, for three years operation. Include the initial system cost, any per-user fees you may charge, yearly charges if any, etc.

Initial cost:

Per-User charges:

Yearly charges:

Other fees or charges?
Description:

Estimated three-year total cost:

Provide any other terms, conditions, or descriptions of pricing which may be relevant to evaluation of your system:

TBD

Schedule

What is a typical "rollout" plan? Describe the process. (If you have an actual rollout plan available for review, this is preferable.)

TBD

User Support

  1. What user support is available in your system, help desk, etc.? Describe both online, oncall, and any other methods you may provide.
  2. What user documentation is available for your system? Please indicate how a copy can be made available for EMCC review.
  3. What training is available for your system? Please include faculty, teaching staff, student, technical staff, help desk, and any other training that may be available.

TBD

Pedagogical Models

Describe the main pedagogical models supported by your system.

TBD (see Phil Long for current status)

Risks

What are the main risks in using your system? What steps or measures do you take to help us avoid or lessen these risks?

TBD

Description and Key Points

What are the key points of your system? How would you describe it?

See the Stellar One-Pager.

Requirements

Stellar is designed with the following requirements in mind:

  1. Scalable: designed and tested for large growth (1,000 courses, 10,000 students, 1,000 faculty)
  2. Scalable: able to be used with small classes (10 persons) without unnecessary overhead
  3. Sustainable: designed for service and maintenance largely by non-technical course administrators
  4. Sustainable: production and development systems clearly separated
  5. Security: strong authentication (certificate-based, kerberos, etc.)
  6. Security: single login
  7. Security: Strong authorization (control over access to resources, functions, and privileges)
  8. Security: copyright and intellectual property protection (future version)
  9. Security: digital signatures or other methods of identifying who produced specific information (future version)
  10. Privacy: individual notification and control of personal information
  11. Privacy: individual identification removed as soon as feasible
  12. Privacy: methods for anonymity, aliasing, or nicknames
  13. Privacy: methods for encryption of personal information where desirable (future version)
  14. Privacy: methods for verifying who has access to information
  15. Stability: continuous operation (24x7)
  16. Stability: minimal downtime (i.e., designed for hot standby, backups, etc.? Can the system be used with multiple servers?)
  17. Usability: designed to help the user accomplish what he or she wants to accomplish, quickly and easily, with a miinimum of frustration
  18. Usability: limited use of technical terminology
  19. Open interfaces: provides ways to create and manage interfaces to external systems
  20. Accessibility: provides support for multiple alternate formats, e.g. video, slideshow, transcript
  21. Accessibility: designed for use with screen readers and plain text browsers
  22. Accessibility: provides tools for easy preparation and integration of text transcripts, alt text tags, etc.
  23. Accessibility: provides large font options
  24. Accessibility: provides closed captioning where feasible
  25. Logging: provides built-in methods for logging in various levels of detail
  26. Customizable "look and feel"
  27. Sharable content: ability to reuse and share content both within and outside the system
  28. Portal integration: ability to provide headlines, summaries, and other information "up" to portal systems using standardized open interfaces
  29. Flexible graphics: ability to use and modify graphics, including inherited styles and other combinations
  30. Navigational design: provides user with intuitive, clear navigational tools to identify where they are and where they want to go next
  31. Continuing Improvement: ability to incorporate additional content, structure, and linkages as needed
  32. Continuing Improvement: ability to incorporate new media