log in:

Desire

Requirements

There are 197 requirements.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9
Requirement
The system shall present aggregated backlogs
The system shall provide revision version control
The system shall support recording scan volunteers
The system shall support recording requirements (user stories) in the form of the Volere requirement shell (uid, type, story, description, rationale, source, fit criterion, satisfaction, dissatisfaction, dependencies, conflicts, supporting materials, history)
The system shall require volunteers to be recorded with a mandatory realname; all other attributes optional
The system shall support creating, reading, updating, and deleting records of objects of the domain
The system shall support recording events of civil society
The system shall use the __color__ field as a substitute for cost/value ratio if they are not present
The system shall support opening and closing iterations
The system shall record items marked as completed as achievements of active iteration
The system shall present iteration history
The system shall authenticate users only when necessary
The system shall prompt when being installed for database user details, domain name, a secret key
The system shall automatically identify the position of attributes in Trac reports based on the heading row in the first line
The system shall confirm successful authentication
The system shall be generally informative
The system shall attempt to read cost from ticket description if cost is not present in the TSV report
The system shall allow domain objects to be bookmarked similarly to AboutUs.org
The system shall present the location a ticket opened in support of story
The system shall support recording working processes
The system shall record and present the location of ticket opened to implement support for requirement on a product
The system shall expand camel case with spaces when reflecting domain model names in the presentation
The system shall return users to a requested resource after an authentication interruption
The system shall be approachable
The system shall support recording stories of civil society
The system shall support recording goals
The system shall boil water
The system shall support assembling product requirement specification documents
The system shall allow an end date to be set independently of closing the iteration
The system shall provide tickets for tracking issues
The system shall optionally enforce the expiry date of ethics approvals
The system shall support collections of processes
The system shall respond with a profile page after user initiates authentication successfully
The system shall support marking items in aggregated backlog as completed and acceptable
The system shall support soliciting bug reports and requests for improvements and new features
The system shall support submitting bug reports and requests for improvements and new features
The system shall support on object read pages appending with autocompletion many-many associations
The system shall present in pages of fixed length the lists of records of the objects of the domain
The system shall present in pages of fixed length the lists of open knowledge project and packages
The system shall return error documents that look and feel like normal pages
The system shall return error documents that look and feel like normal CKAN pages
The system shall be immune to SQL injection attacks
The system shall by immune to SQL injection attacks
The system shall present cost and value estimates with no more than two decimal places
The system shall present lists of tickets in descending priority order
The system shall return OpenID login pages that look and feel like normal pages
The system shall support returning HTTP status code 503 (and display a 'Down for Maintenance' message) for purposes that are designated to be temporarily unavailable
The system shall support deployment of DomainModel applications
The system shall support deployment of Pylons applications
The system shall support extending one product requirements specification with another
The system shall support temporal domain objects
The system shall support copying records of objects of the domain
The system shall suport recording temporal domain object attributes
The system shall support recording bi-temporal records of objects of the domain
The system shall support developing an object model of a domain
The system shall support delcaration of many-many associations
The system shall support declaration of one-many associations
The system shall support declaration of value object attributes such as integer, string, boolean, floating point
The system shall provide a RESTful machine client interface
The system shall generate email address confirmation request, by creating a pending email confirmation action with any referenced pending action, and sending an email message to the unconfirmed address, passing a reference to the pending email confirmation action with the message
The system shall support resetting account password at secret URL sent to confirmed registered email address
The system shall send a nice welcome message, providing both 'more information' and an adequate introduction to the friends list
The system shall release all outstanding tickets from association with the closed iteration
The system shall support reading a factlet within the context of many threads
The system shall support adding existing factlets to existing threads
The system shall support searching for existing factlets by text query
The system shall present the factlet's threads next to the factlet
The system shall support viewing the thread's factlets by date on a timeline
The system shall support autocompletion when editing package tags
The system shall support inline editing of the attributes of threads
The system shall present dates with format DD-MM-YYYY
The system shall support hiding weeks when updating schedule
The system shall present the list of hidden weeks
The system shall have grid lines on the schedule view
The system shall style the schedule grid for printing
The system shall present ethics code on schedule week session summary
The system shall present cost code on schedule week session summary
The system shall support recording cost codes against medical imaging projects
The system shall support setting verbosity of any inline help messages which explain application functionality
The system shall support reading a full listing of all registered researchers
The system shall support recording the status (active/left/temporarily away) of a researcher
The system shall support earmarking scanning schedule time for methods development work
The system shall support earmarking scanning schedule time for actual scanning sessions
The system shall support setting a registered organisation as the default
The system shall not prompt for user confirmation when deleting schedule time earmarkings
The system shall enforce unique medical imaging research approval codes
The system shall enforce unique medical imaging project titles
The system shall style the schedule grid for screen reading
The system shall direct the user to the register index after updating records of the medical imaging facility
The system shall support recording expected preparation minutes against medical imaging projects
The system shall support scheduling sessions from 1st January 2005
The system shall present earmarked organisation on schedule week earmark summary
The system shall present the total number of scanning sessions for medical imaging research projects
The system shall present with great emphasis the date of the displayed week
The system shall support recording the role (imager/non-imager) of a researcher
The system shall support importing a spreadsheet of volunteer details, enforcing unique name and scan ID
The product shall prevent incorrect data from being introduced
The product shall protect itself from intentional abuse
The product shall make its users aware of its information practices before collection of data from them
The product shall reveal private information only in compliance with the unit's information policy
The product shall protect private information in accordance with relevant privacy laws and the unit's information policy
The product shall retain records to permit required audit checks
The product shall be as secure as possible from malicious interference
The product shall protect itself from unintentional data loss
The system shall present lists work items in descending priority order
The system shall support making notes about scanning schedule week
The system shall support reading notes about scanning schedule week
The system shall present a chronological list of upcoming sessions that allows a selected volunteer to be booked in
The system shall render week notes for display with 'markdown' convertor
The system shall present lists of records sorted in whatever order is requested by the user
The system shall support recording that a volunteer is very keen
The system shall support recording that a volunteer is very reliable
The system shall present list containing only active volunteers
The system shall support selecting an active volunteer for booking into upcoming scanning sessions
The system shall present a link from a volunteer's 'last scan' to the corresponding week in the schedule
The system shall display 'inactive' objects with faded colour
The system shall present starts and ends date-time attributes as date with starts and ends time
The system shall present options for training session type as: Oxgen, AED, MRI Practical, MRI Video, MRI Responsible, AED Refresher, First Aid
The system shall show earmark comments when viewing sessions
The system shall support recording an earmark with: starts date-time, ends date-time, comment, earmark type
The system shall support recording a training session with: starts date-time, ends date-time, comment, notes
The system shall support registering cost codes, and associating them with projects
The system shall support optionally recording a scanning 'session leader', to be one of the project researchers
The sytem shall present 'session contact' as 'session leader' or 'project leader'
The system shall support recording a project with: title, nickname, leader, researchers, approval, funding, status, preparation minutes, booking method, committee approval, committee presentation, number subjects, number pilots, slot minutes, volunteer type, start date, completion date, cost code, notes, project outcome
The system shall confirm successful creating, updating, and deleting
The system shall support scheduling scanner time for methods work
The system shall support cancelling volunteer scanning appointment
The system shall support restricted registering of scanning session outcomes
The system shall update, test and commit source, and build, upload, and test distribution
The system shall register distribution information with release index
The system shall increase the version of a system under development
The system shall support recording sales opportunities
The system shall support setting whether or not scanning sessions require trained project leader
The system shall support setting whether or not scanning sessions require selected ethics approval expires after session ends
The system shall support setting whether or not scanning sessions require selected ethics approval balance in credit
The system shall update cost account when scanning session is created
The system shall update cost account when scanning session is updated
The system shall update cost account when scanning session is deleted
The system shall update cost accounts when project changes cost account
The system shall display cost account as list of all changes in given month
The system shall display cost account as list of all currently effective charges
The system shall display cost account as a current balance
The system shall make available all entries for an account as comma and tab separated values sorted by entry date
The system shall visually indicate when a Web browser client isn't supported
The system shall support the Firefox Web browser client
The system shall speak to DICOM servers
The system shall speak to PACS servers
The system shall speak to scan image viewers
The system shall notify suitable researchers when ethics approval limits are being reached
The system shall support domain data persistence with the SQLObject ORM
The system shall support domain data persistence with the Sqlalchemy ORM
The system shall support domain data persistence with the Google AppEngine ORM
The system shall support restarting the application service provision's HTTP server
The system shall protect against dictionary attacks by monitoring login attempts
The system shall present to all users a form for starting data openness enquiries
The system shall accept submissions from authenticated owners of activated accounts using the data openness enquiry form by presenting the enquiry summary and prompting for confirmation
The system shall accept submissions from unauthenticated users of the data openness enquiry form by creating an anonymous pending enquiry action, and by redirecting the user to login form, passing a reference to the pending action
The system shall regularly send pending data openness enquiry messages through a secure email account
The system shall present near any login form options both to register new user account details and to recover old user account details, passing on any reference to a pending action
The system shall present to unauthenticated users a registration form, for registering new user accounts
The system shall accept submissions from unauthenticated users of the registration form by signing in the user to an unactivated account, by generating an email address confirmation request, and by indicating to the user that this has happened
The system shall set on any login form hidden form values for any passed reference to a pending action
The system shall set on the registration form a hidden value for any passed reference to a pending action
The system shall accept login form submission from an unauthenticated user offering good credentials by signing in the user and resuming any referenced pending action
The system shall accept (and action pending account activation) submissions from authenticated owners of unactivated accounts using the form for starting data openness enquiries by directing the user to activate their account
The system shall accept email confirmation submissions from authenticated users by executing the submitted reference to a pending email confirmation action
The system shall present to unauthenticated users a login form for submitting account credentials
The system shall accept email confirmation submissions from unauthenticated users by redirecting to the login page, passing on the submitted reference to a pending email confirmation action
The system shall resume an enquiry regarding data openness by redirecting the user to the enquiry confirmation page (as if the enquiry had just been made)
The system shall accept from authenticated owners of activated accounts confirmation of the summary of enquiry regarding data openness by creating a pending message to a data handler with the enquiry and indicating to the user that this has happened
The system shall execute a pending email confirmation action by activating an unactivated account and resuming any pending data openness enquiries
The system shall notify enquiry owner when pending enquiry messages are sent
The system shall present to data openness enquiry owner options to close the enquiry with resolution of open, not open, or not known
The system shall present to enquiry owners an option for following up data openness enquiries when the enquiry is viewed
The system shall present to owners of a data openness enquiry a form for following up the enquiry
The system shall accept submissions from data openness enquiry owners using the form for following up enquiries by presenting the follow up summary and prompting for confirmation
The system shall accept from data openness enquiry owners confirmation of the enquiry follow up by creating a pending message to a data handler and indicating to the user that this has happened
The system shall regularly receive new data openness enquiry messages from a secure email account
The system shall read received messages and decide an appropriate action
The system shall action received data openness enquiry response messages by adding the message as a response to the enquiry and notifying the enquiry owner that this has happened
The system shall action received bounced data openness enquiry response messages by notifying enquiry owner that this has happened
The system shall action received unsolicited messages by taking no further action
The system shall present to all users a list of existing data openness enquiries
The system shall apply an external CKAN changeset, guarded by testing for conflicts, and shall notify site administrators of any conflict, failed merge, or successful update.
The system shall request a CKAN changeset from another CKAN instance
The system shall request a list of CKAN changesets from another CKAN instance
The system shall present a referenced CKAN changeset
The system shall present a list of CKAN changeset references, optionally restricted by date or changeset reference
The system shall allow other CKAN instances to register for notifications of new changesets
The system shall register a changeset notification handler with another CKAN instance
The system shall recieve notification of new changeset from another CKAN instance
The system shall send notification of new changesets to CKAN instances that have registered a changeset notifcation handler
The system shall receive authorised notifications of new CKAN changesets, by requesting and applying the changesets
The system shall determine whether a given CKAN changeset can be merged without conflict
The system shall notify site administrators of CKAN changeset merge conflicts
The system shall allow site administrators to resolve changesets which cause conflicts or which failed to merge automatically