Software requirements specification

Functional Requirements

Functional requirements put simply are buttons and features that do something for the user.

• The system shall allow for data entry like all other fieldlinguistics databases.
• The system shall allow drag and drop audio to attach audio to your data.
• The system shall insert IPA and special symbols
• The system shall support Hotkeys and keyboard short-cuts for common tasks.
• The system shall import .csv
• The system shall import ELAN

Non-Functional Requirements

Non-functional requirements put simply are overarching considerations which affect the software architecture. Non-functional requirements are where most existing field linguistics/corpus linguistics database applications fall short.

• The system shall be user friendly.
• The system shall be cute so that the users feel like entering data, instead of procrastinating.
• The system shall be designed for search as this is one of the most important tasks that a fieldlinguist needs to do. The search needs go far beyond traditional string matches and database indexes. We need to see data in context, and the search must attempt to make this possible.
• The system shall be OpenData enabled. Corpora often contain sensitive information, informant stories and other information which must be kept confidential. Having confidential data in plain text in a corpus forces the entire corpus to be kept confidential. The system shall encrypt confidential data and store the data in the corpus encrypted. To access the plain text the user must log in and use their password to decrypt the data. This design has important ramifications for exporting data, and for editing the data outside the app.
• The system shall work offine. Running a webapp offline has important consequences for how data is stored, and how data is retrieved, and how much data can be used while offline. Most browsers have limits on the amount of data a webapp can store offline. By delivering a version of the app in a Chrome Extension (which has permission to have unlimited storage) the user will be able to have a significant portion of their data at their finger tips, whether in the Metro, in the field, in a park or in a country where wifi is not common, which is commonly the case for where we do our field work.
• The system shall run on Mac, Linux, Windows computers. By providing the app as installable Chrome Extensions, the app will run on all platforms, Mac, Linux and Windows, as well as Chrome Books.
• The system shall be OpenSource. Being OpenSource allows departments to install and customize the database app for their needs without worry that the company behind the software will disappear or stop maintaining the software. In addition, OpenSourcing the software on GitHub allows linguists with scripting/programming experience to contribute back to the software to make it more customized to their needs and their language typologies or linguistics research areas.
• The system shall store data in Unicode. Encoding problems and loosing our data should be behind us in the days of unicode, however many existing fieldlinguistics databases were built in programming languages that didn't support unicode, so the unicode support is dangerously fragile.
• The system shall be simple. The system is not designed to replace advanced field linguistics databases, or corpus linguistics databases. It is designed to replace Word Documents or LaTeX documents, which is a very common way fieldlinguists store data because it requires no training, doesn't require a complicated set-up for data categories, and takes no time to add new categories.
• The system shall be theory free. The system will not include categories or linguistic frameworks or theoretical constructs that must be tied to the data, however the system will make it possible for the team to set their own categories and thus tie the specific theoretical constructs they are investigating to their data. This is a different approach to many corpus databases which are motivated by typologies and language counting which place a large data-entry burden on the user, rather than letting the user gradually constrain their data entry conventions over time.
• The system shall be collaborative The system shall have users and teams, and permissions for corpora which will ensure that data can be safely shared and edited by multiple users. The corpus will be versioned so that users can track changes and revert mistakes.
• The system shall run on touch devices Touch tablets are one of the easiest tools to carry to the field, they have a long battery life, they can play videos or show images for the informant to elicit complicated contexts (such as quantification and scope), they permit recording audio and video and direct publishing to YouTube or other service. Android tablets are particularly easy to program and integrate the microphone directly into the database.
• The system shall be smart The system shall try to guess what users do most often, and automate the process for them. Most importantly, predictable glossing information should be automated.