Child pages
  • Requirements & Feature Requests
Skip to end of metadata
Go to start of metadata

Known Requirements & Feature Requests

Requirements in Jira (REQ)

type key summary reporter votes priority status resolution

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Feature Requests in Jira (SAK)

type key summary reporter priority status resolution

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  • No labels


  1. The Sakai Requirements WG has also collected a set of assessment requirements that go beyond Samigo to include a larger view of what assessment could be. Please have a look if you are interested in expanding Samigo's capabilities.

    1. How are these related to what is in Jira?

  2. Mark, many items listed in REQ WG's 'assessment requirements' are existing functions in Samigo. I'm confused why they are called requirements.

  3. Ideally, the process of building a software application consists of several steps:

    1. Gather use cases and requirements
    2. Create a (UI) design to meet user's needs
    3. Determine what software needs to be built
    4. Build it
    5. Test it

    It has been my experience that if you skip an of these steps, including the first one, trouble always ensues. Requirements are a way to describe how a software application should work. It indicates what must be there to meet user and customer needs. A good UI builds on top of these abstract requirements, as does the software design. It's very difficult to build an application that will really satisfy users if you don't truly understand what is needed. Worse, it is almost impossible to test it.

    Sadly, Sakai does not have descriptions of how it is supposed to work. No where is there an explanation of what features a tool should have. As part of my work leading the Sakai Requirements WG, I have started building a repository of such documents. These requirement documents go well beyond the feature requests that have appeared over time in Jira. They are not about identifying problems with existing code. Indeed, done properly, they don't necessarily describe an application implementation. Rather, they describe what the application SHOULD be.

    The assessment requirements page that I referred to is just that. It is a collection of requirements that any assessment tool (or tools and services) SHOULD meet. I hope, over time, that these requirements will expand beyond the currently feature set of Samigo and start to describe directions that it could go in.

    Sakai uses Jira for two main purposes: tracking bugs and tracking suggestions. It is very good at gathering information around a particular issue and supporting the development process towards resolving it. Jira is not appropriate for collecting such things together into a cohesive whole. I am using Confluence for that, in part, because Confluence is well integrated with Jira.

    The assessment requirements page is a first pass effort. Over time, I'd like to include references to Jira items where they exist. The should also reference Requirement submissions where they exist. Finally, a separate document should be written to describe the current state of Samigo (and any other assessment tools that get built) measures against the larger body of requirements.

    I welcome your contributions to that effort. I believe that it can only make Samigo stronger, and by reflection, Sakai as well.