| Requirement |
|
The product shall be as secure as possible from malicious interference
|
|
The product shall make its users aware of its information practices before collection of data from them
|
|
The product shall prevent incorrect data from being introduced
|
|
The product shall protect itself from intentional abuse
|
|
The product shall protect itself from unintentional data loss
|
|
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 reveal private information only in compliance with the unit's information policy
|
|
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 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 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 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 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 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 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 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 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 action received bounced data openness enquiry response messages by notifying enquiry owner that this has happened
|
|
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 unsolicited messages by taking no further action
|
|
The system shall allow an end date to be set independently of closing the iteration
|
|
The system shall allow domain objects to be bookmarked similarly to AboutUs.org
|
|
The system shall allow other CKAN instances to register for notifications of new changesets
|
|
The system shall allow site administrators to resolve changesets which cause conflicts or which failed to merge automatically
|
|
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 attempt to read cost from ticket description if cost is not present in the TSV report
|
|
The system shall authenticate users only when necessary
|
|
The system shall automatically identify the position of attributes in Trac reports based on the heading row in the first line
|
|
The system shall be approachable
|
|
The system shall be generally informative
|
|
The system shall be immune to SQL injection attacks
|
|
The system shall boil water
|
|
The system shall by immune to SQL injection attacks
|
|
The system shall confirm successful authentication
|
|
The system shall confirm successful creating, updating, and deleting
|
|
The system shall determine whether a given CKAN changeset can be merged without conflict
|
|
The system shall direct the user to the register index after updating records of the medical imaging facility
|
|
The system shall display 'inactive' objects with faded colour
|
|
The system shall display cost account as a current balance
|
|
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 enforce unique medical imaging project titles
|
|
The system shall enforce unique medical imaging research approval codes
|
|
The system shall execute a pending email confirmation action by activating an unactivated account and resuming any pending data openness enquiries
|
|
The system shall expand camel case with spaces when reflecting domain model names in the presentation
|
|
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 have grid lines on the schedule view
|
|
The system shall increase the version of a system under development
|
|
The system shall make available all entries for an account as comma and tab separated values sorted by entry date
|
|
The system shall not prompt for user confirmation when deleting schedule time earmarkings
|
|
The system shall notify enquiry owner when pending enquiry messages are sent
|
|
The system shall notify site administrators of CKAN changeset merge conflicts
|
|
The system shall notify suitable researchers when ethics approval limits are being reached
|
|
The system shall optionally enforce the expiry date of ethics approvals
|
|
The system shall present a chronological list of upcoming sessions that allows a selected volunteer to be booked in
|
|
The system shall present a link from a volunteer's 'last scan' to the corresponding week in the schedule
|
|
The system shall present a list of CKAN changeset references, optionally restricted by date or changeset reference
|
|
The system shall present a referenced CKAN changeset
|
|
The system shall present aggregated backlogs
|
|
The system shall present cost and value estimates with no more than two decimal places
|
|
The system shall present cost code on schedule week session summary
|
|
The system shall present dates with format DD-MM-YYYY
|
|
The system shall present earmarked organisation on schedule week earmark summary
|
|
The system shall present ethics code on schedule week session summary
|
|
The system shall present in pages of fixed length the lists of open knowledge project and packages
|
|
The system shall present in pages of fixed length the lists of records of the objects of the domain
|
|
The system shall present iteration history
|
|
The system shall present list containing only active volunteers
|
|
The system shall present lists of records sorted in whatever order is requested by the user
|
|
The system shall present lists of tickets in descending priority order
|
|
The system shall present lists work items in descending priority order
|
|
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 options for training session type as: Oxgen, AED, MRI Practical, MRI Video, MRI Responsible, AED Refresher, First Aid
|
|
The system shall present starts and ends date-time attributes as date with starts and ends time
|
|
The system shall present the factlet's threads next to the factlet
|
|
The system shall present the list of hidden weeks
|
|
The system shall present the location a ticket opened in support of story
|
|
The system shall present the total number of scanning sessions for medical imaging research projects
|
|
The system shall present to all users a form for starting data openness enquiries
|
|
The system shall present to all users a list of existing data openness enquiries
|
|
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 present to unauthenticated users a login form for submitting account credentials
|
|
The system shall present to unauthenticated users a registration form, for registering new user accounts
|
|
The system shall present with great emphasis the date of the displayed week
|
|
The system shall prompt when being installed for database user details, domain name, a secret key
|
|
The system shall protect against dictionary attacks by monitoring login attempts
|
|
The system shall provide a RESTful machine client interface
|
|
The system shall provide revision version control
|
|
The system shall provide tickets for tracking issues
|
|
The system shall read received messages and decide an appropriate action
|
|
The system shall receive authorised notifications of new CKAN changesets, by requesting and applying the changesets
|
|
The system shall recieve notification of new changeset from another CKAN instance
|
|
The system shall record and present the location of ticket opened to implement support for requirement on a product
|
|
The system shall record items marked as completed as achievements of active iteration
|
|
The system shall register a changeset notification handler with another CKAN instance
|
|
The system shall register distribution information with release index
|
|
The system shall regularly receive new data openness enquiry messages from a secure email account
|
|
The system shall regularly send pending data openness enquiry messages through a secure email account
|
|
The system shall release all outstanding tickets from association with the closed iteration
|
|
The system shall render week notes for display with 'markdown' convertor
|
|
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 require volunteers to be recorded with a mandatory realname; all other attributes optional
|
|
The system shall respond with a profile page after user initiates authentication successfully
|
|
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 return error documents that look and feel like normal CKAN pages
|
|
The system shall return error documents that look and feel like normal pages
|
|
The system shall return OpenID login pages that look and feel like normal pages
|
|
The system shall return users to a requested resource after an authentication interruption
|
|
The system shall send a nice welcome message, providing both 'more information' and an adequate introduction to the friends list
|
|
The system shall send notification of new changesets to CKAN instances that have registered a changeset notifcation handler
|
|
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 show earmark comments when viewing sessions
|
|
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 style the schedule grid for printing
|
|
The system shall style the schedule grid for screen reading
|
|
The system shall suport recording temporal domain object attributes
|
|
The system shall support adding existing factlets to existing threads
|
|
The system shall support assembling product requirement specification documents
|
|
The system shall support autocompletion when editing package tags
|
|
The system shall support cancelling volunteer scanning appointment
|
|
The system shall support collections of processes
|
|
The system shall support copying records of objects of the domain
|
|
The system shall support creating, reading, updating, and deleting records of objects of the domain
|
|
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 support delcaration of many-many associations
|
|
The system shall support deployment of DomainModel applications
|
|
The system shall support deployment of Pylons applications
|
|
The system shall support developing an object model of a domain
|
|
The system shall support domain data persistence with the Google AppEngine ORM
|
|
The system shall support domain data persistence with the Sqlalchemy ORM
|
|
The system shall support domain data persistence with the SQLObject ORM
|
|
The system shall support earmarking scanning schedule time for actual scanning sessions
|
|
The system shall support earmarking scanning schedule time for methods development work
|
|
The system shall support extending one product requirements specification with another
|
|
The system shall support hiding weeks when updating schedule
|
|
The system shall support importing a spreadsheet of volunteer details, enforcing unique name and scan ID
|
|
The system shall support inline editing of the attributes of threads
|
|
The system shall support making notes about scanning schedule week
|
|
The system shall support marking items in aggregated backlog as completed and acceptable
|
|
The system shall support on object read pages appending with autocompletion many-many associations
|
|
The system shall support opening and closing iterations
|
|
The system shall support optionally recording a scanning 'session leader', to be one of the project researchers
|
|
The system shall support reading a factlet within the context of many threads
|
|
The system shall support reading a full listing of all registered researchers
|
|
The system shall support reading notes about scanning schedule week
|
|
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 support recording a training session with: starts date-time, ends date-time, comment, notes
|
|
The system shall support recording an earmark with: starts date-time, ends date-time, comment, earmark type
|
|
The system shall support recording bi-temporal records of objects of the domain
|
|
The system shall support recording cost codes against medical imaging projects
|
|
The system shall support recording events of civil society
|
|
The system shall support recording expected preparation minutes against medical imaging projects
|
|
The system shall support recording goals
|
|
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 support recording sales opportunities
|
|
The system shall support recording scan volunteers
|
|
The system shall support recording stories of civil society
|
|
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 support recording the role (imager/non-imager) of a researcher
|
|
The system shall support recording the status (active/left/temporarily away) of a researcher
|
|
The system shall support recording working processes
|
|
The system shall support registering cost codes, and associating them with projects
|
|
The system shall support resetting account password at secret URL sent to confirmed registered email address
|
|
The system shall support restarting the application service provision's HTTP server
|
|
The system shall support restricted registering of scanning session outcomes
|
|
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 scheduling scanner time for methods work
|
|
The system shall support scheduling sessions from 1st January 2005
|
|
The system shall support searching for existing factlets by text query
|
|
The system shall support selecting an active volunteer for booking into upcoming scanning sessions
|
|
The system shall support setting a registered organisation as the default
|
|
The system shall support setting verbosity of any inline help messages which explain application functionality
|
|
The system shall support setting whether or not scanning sessions require selected ethics approval balance in credit
|
|
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 trained project leader
|
|
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 temporal domain objects
|
|
The system shall support the Firefox Web browser client
|
|
The system shall support viewing the thread's factlets by date on a timeline
|
|
The system shall update cost account when scanning session is created
|
|
The system shall update cost account when scanning session is deleted
|
|
The system shall update cost account when scanning session is updated
|
|
The system shall update cost accounts when project changes cost account
|
|
The system shall update, test and commit source, and build, upload, and test distribution
|
|
The system shall use the __color__ field as a substitute for cost/value ratio if they are not present
|
|
The system shall visually indicate when a Web browser client isn't supported
|
|
The sytem shall present 'session contact' as 'session leader' or 'project leader'
|