Requirements

Requirement types are: functional, technical, and business. See the corresponding tables for each. All requirements are coded for traceability. Functional and technical requirements should be written in a form that is logically testable.

Functional Requirements

Req Code	Requirement text	Implemented (Y/I/N)
FR001	The system should allow administrators to configure the application to filter query scope without changes to source code. For example, create a filter setting to change the organizational scope of all queries from University of Nevada, Las Vegas to Cornell University.	Y
FR002	The system should serialize the results of any given query initiated by the user as JSON or CSV; the system should save such results to a location accessible by the user.	Y
FR003a	The system should provide a graphed view of search results whenever possible.	Y
FR003b	The system should apply images for entities whenever possible when creating graphs of application data.	Y
FR003c	The user should be provided with a list of properties for creating graph representations of data. Candidates for People are: occupation, field of work, place of burial, parent (mother, father), place of birth. Candidates for corp bodies are: instanceOf, main subject. Candidates for Collections are: main subject. Candidates for Oral Histories are: main subject.	Y
FR003d	when the user selects a property node on the graph, the system should be able to return a new result set filtered by the property.	Y
FR003e	when the user selects an entity node on the graph, the system should provide some available details on that entity (see FR005).	Y
FR003f	the user should be able to enlarge the graph view.	Y
FR003g	When a property for an entity doesn't exist, a row for it should not be shown in the properties tooltip.	Y
FR003h	Node labels should be fully readable whenever possible (use ellipse shape); if a label exceeds 15 characters it will abbreviated.	Y
FR003i	The system should provide a way for the properties tooltip to remain open and interactive.	Y
FR004	The system should provide a search service against textual descriptions of entities loaded in the list views of People, Corporate Bodies, Collections, Oral Histories, and Subjects, including the text of label and description entities.	Y
FR005	Users should be able to access the details of a given entity provided in the in-scope list of entities for people, corporate bodies, collections, and oral histories.	Y
FR006	The system should provide distinct page views for People, Corporate Bodies, Collections, Oral Histories, and Subjects.	Y
FR007	The "main subject" property (P921), presented in "item details" or "subjects" should be used to retrieve only collection, oral history, and corporate body data.	Y
FR008a	The user should be presented with a map representation of data when geographic location information is present.	Y
FR008b	The user should should be able to enlarge the map view (duplicate of RF003f).	Y
FR009	(paused) item lists exceeding 20 rows should be paginated and accessed sequentially using a "page links" pattern.	N
FR010	The administrator should be able to configure the "agent" property of the SPARQLWrapper service object using the Django admin application. The property consists of an application identifier, e.g., "PyDiscoverApp/1.0," an application maintainer reference URL, e.g., "https://www.wikidata.org/wiki/User:Aehulet" and a contact email, e.g., "[email protected]."	Y
FR011	The query filtering configurations required by the application should be accessible and writable via the Django admin application.	Y
FR012a	In the item details view, properties pointing to known data (e.g., 'oral history at: UNLV', or an HTTP expression) should be hyperlinked and allow the system to retrieve that data into a standard view, e.g. Oral Histories or an external page. NOTE http values work like this, but query by property does not (yet).	Y
FR012b	The system should maintain a configurable table of properties that can be hyperlinked in the item details view. NOTE: implementation is now different: linkable properties are hard-coded in web_models.get_item.	Y
FR013	The Home screen should provide a brief introduction to the application and at least one graph showing statistics about the wikidata available for UNLV.	Y
FR014	The system should provide links back to the three most recent queries run by the user.	Y
FR015a	The system should provide a knowledge panel, organized by Subject(s) (other classes TBD), that shows all available resources at UNLV related to the Subject(s), based on available wikidata.	N
FR015b	The user should be able to search from the Knowledge Panel for selected Wikidata items outside of the UNLV SCAA scope but related by one or more domains, e.g. works by Subject or Person.	N
FR016	The application should provide a faceted search capability, in which all available values for a given in-scope property (facet) are shown and can be multi-selected as search criteria.	Y

Technical Requirements

Req Code	Requirement text	Implemented (Y/I/N)
TR001	The system should support (x) number of simultaneous connections. NOTE: requirement was tested with 100 simultaneous connections using Apache JMeter.	Y
TR002	All javascript libraries should be included as local files whenever possible to ensure acceptable performance, e.g., quick and complete loading of graph imagery in line with specifications for that library.	Y
TR003	All unhandled application exceptions should be logged on the server according to organization, error type, procedure in which error occurred, date/time.	Y
TR004	Users should expect sub-second response times in most cases when loading the results list.	Y
TR005	For searches that return fewer than 200 results, users should expect the graph to load in less than ten seconds	Y

Business Requirements

Req Code	Requirement text	Implemented (Y/I/N)
BR001	The application project should be organized and managed as an open-source project.	I
BR002	An organization should be able to configure the application to work within its scope.	Y
BR003	Page styling for the application should follow styling standards for UNLV applications to the degree possible.	Y