Software Eng Requirements Eng
Software Eng Requirements Eng CS 4310
Popular in Course
Popular in ComputerScienence
This 33 page Class Notes was uploaded by Dorothy Bahringer DVM on Thursday October 29, 2015. The Class Notes belongs to CS 4310 at University of Texas at El Paso taught by Staff in Fall. Since its upload, it has received 11 views. For similar materials see /class/231294/cs-4310-university-of-texas-at-el-paso in ComputerScienence at University of Texas at El Paso.
Reviews for Software Eng Requirements Eng
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 10/29/15
Software Engineering Fall 2005 CS 4310 Fall 2005 Ontology Management System Software Requirements Specification Version lt1 4gt 2162006 an3FZ9MV78doc Ontology Management System Document Control Approval The Guidance Team and the custom er will approve this document Document Change Control Initial Release December 20 2005 Current Release February 16 2006 Indicator of Last Page in Document Q Date of Last Review TBD Date of Next Review TBD Target Date for Next Update TBD Distribution List This following list of people will receive a copy of this document every time a new version of this document becomes available Change Summary Guidance Team Members Customers Dr Ann Gates Dr Thamar Solorio Elsa Tai Dr Randy Keller Leonardo Salayandia Software Teams Engine Soft Eisen Corp Mexsys Corporation Hades Inc Solution Developers Inc CompuGlobalHyperMegaNet Intelligent Software Systems Gemini Software Development The following table details changes made between versions of this document Version Date Modifier Description 10 12202005 E Tai Section 1 and 2 Combining information from teams 11 12606 Ann Gates and Leo Section 2 Cleaning use case diagram Section Salayandia 3 Cleaning and adding requirements Ontology Management System CS 4310 Fall 2005 Version 14 2162006 Page ii Ontology Management System Version Date Modifier Description 12 13106 Ann Gates and Leo Section 2 UC Diagram Browse and Query Salayandia merged into Retrieve 13 2706 Ann Gates and Leo Section 2 Completed salayandla Appendices A and B edited diagrams are still pending Section 3 Cleaning and adding requirements 14 21506 Ann Gates and Leo Section 3112 Completed Salayandia Subsections for actors use cases and scenarios Corrected grammar and text in Section 1 Ontology Management System CS 4310 Fall 2005 Version 14 2162006 Page iii Ontology Management System TABLE OF CONTENTS DOCUMENT CONTROI II APPRO M II DOCUMENT CHANGE CONTR m 11 DISTRIBUTION LIST II CHA G SUMMARY II 1 INTRODUCTION 1 11 PURPOSE AND INTENDED AUDIENCE 1 12 SCOPE OF PRODUCT 1 13 DEEINITIONS ACRONYMS AND ABBREVIATIONS 1 13 De nitions I 132 Acrnm m 3 133 39 39 4 14 OVERVIEW 4 15 REEERENCE 4 2 GENERAL DESCRIPTION 5 21 PRODUCT PERSPECTIVE E 22 PRODUCT FEATURES 5 221 Actor 7 222 Use Cases 7 2 2 3 Scenarios 7 23 USER CHARACTERISTIC 10 24 GENERAL CONSTRAst 10 25 ASSUMPTIONS AND DEPENDENCIES 10 3 SPECIFIC REQUIREMENTS 1 31 EXTERNAL INTEREACE REQUIREMENTS 1 1 311 User Interfaces I I 312 Hardware Interface 5 313 So ware Interface 15 314 V 39 39 Interface 5 32 BEHAVIORAL REQUIREMENTS 1 3 2 Same Class oster 15 322 D 4 D W rld Ohiorr 17 323 RelatedFeature 7 324 Vtimulu 7l 32 5 Funr nnnl 7 3 33 NONBEHAVIORAI REnmwmmTq n 3 3 1 Performance quot l 39 74 332 Qualitative quot 1 39 74 333 39 39 quotquot 74 334 Pnrmhilin 74 335 Security 74 3 3 6 Design and Implementation Constraints 74 34 OTHER REQUIREMENTS 74 APPENDIX A DIAGRAMS 7 A1 ONTOLOGY OMT DIAGRAM 7lt A2 DATA FLOW Tm CB AMS 75 i Scenario 1 Retrieve 75 ii Scenario 2 Contribute 77 iii Scenario 3 Validate 77 A3 STATE CHARTS 77 iv Scenario 3 Contribute 77 v Scenario 4 Validate 77 Ontology Management System CS 4310 Fall 2005 Version 14 2162006 Page iv Ontology Management System APPENDIX B OWL FORMAT 7 B1 OWL BASE ONTOLOGY 7 B2 CONCEPT NAME TA r 72 B3 ANNOTATION TAG FOR RESOURCE URI 70 Ontology Management System CS 4310 Fall 2005 Version 14 2162006 Page v I Software Requirements Speci cation 1 Introduction 11 Purpose and Intended Audience The purpose of the Software Requirements Specification SRS is to give the customer a clear and precise description of the functionality of the proposed Ontology Management System OMS The SRS divides the system requirements into two parts behavioral and nonbehavioral requirements The behavioral requirements describe the interaction between the system and its environment Nonbehavioral requirements relate to the definition of the attributes of the product as it performs its functions This includes the level of security efficiency reliability maintainability portability capacity and the standards of compliance of the product The intended audience of the SRS is the Geology Department at The University of Texas at El Paso UTEP and the development team This document serves as an agreement between both parties regarding the product to be developed 12 Scope of Product GEOsciences Network GEON is an NSFfunded IT research program to conduct fundamental research towards developing a cyberinfrastructure for the earth science community The goal of GEON is to provide advanced information technologies that support intelligent searching integration visualization analysis and modeling of datasets In addition GEON provides high performance computing platforms required to analyze and model such datasets thus facilitating the interdisciplinary collaboration of earth science community efforts The University of Texas at El Paso Departments of Computer Science and Geology Department are collaborating to develop a serviceoriented Ontology Management System OMS that will maintain ontologies about the resources available on the GEON Network The OMS will be integrated into the GEON cyber infrastructure as a service such that other applications or services can use the OMS functionality GEON resources are broadly classified as data methods and products and are distributed geographically and organizationally across the GEON Network partner sites 3 The purpose of the ontologies is to maintain knowledge about the GEON resources in order to facilitate their discovery and integration The OMS will manage the ontologies and provide client applications with the following services I Retrieve that will allow users to navigate through the available ontologies in search of concepts and corresponding resources as well as search for concepts and corresponding resources based on keyword queries I Contribute that will allow contributors to create new ontologies andor propose modifications to existing ontologies I Validate that will allow domainexperts to control the contribution process of ontologies by providing functionality to accept and reject new contributions 13 De nitions Acronyms and Abbreviations 131 De nitions The definitions in this section are given in the context of the product being developed This intention is to assist the user in their understanding of the requirements for the system l TERM l DEFINITION CheckBox A graphical user interface object that can be clicked to turn an option on or off 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Page 1 Software Requirements Speci cation TERM DEFINITION Cleartext Computer Security term used to refer to text that is not encrypted Client Application A software application external to our system that a user will utilize to interact with the OMS Command Button A graphical user interface object that can be clicked on to confirm or cancel the option Concept It is represented as a class a concept facilitates the description of a domain of knowledge 9 Contribution It refers to either a newly created ontology or a modified existing ontology Datagrid field A graphical user interface object that allows data to be presented in a spreadsheet style ie the user is able to navigate through cells by rows and columns Dictionary Dictionary that maintains relationship name synonym description of the relationship and inverse relationship name Domain Concept For a relation Rxy the domain concept is signified by x Implied relationship A relationship that is inherited from a parent concept39 also referred to as a child relationship List Box A graphical user interface object that can be used to display data vertically in an ordered form at Metadata Information that describes another set of data For ontology the metadata is the information stored in the Metadata Table MySQL Open source relational database management system 13 Networkaddressable re sourc e A resource that can be referenced through a URI OMS repository It refers to the repository that the OMS currently accessed at the moment of user request Ontology It refers to the explicit description of concepts in a domain closure and relations among them 9 Plugin A component that provides a certain type of functionality within the context of a host application The component is configured into the system at deployment time which implies that the plugin component can be installed and uninstalled onfrom the host application Portal It is a web site that provides a starting point or gateway to other resources on the Internet or an intranet Portlet A reusable web component that displays relevant information to Portal users Protege An open source ontology editor and knowledgebase framework developed at Stanford university Radio Button A series of related and mutually exclusive circular buttons of which only one can be clicked to select a specific option Range Allowed classes for slots of type instance are the range of a slot 9 Software Requirements Specification Version 14 21 Soitw are Requirements Speci cation TERM D EFINITION Range Concept For a relation Rxy the range concept is signified by y Relational database Data that is stored in a relational model and manipulated by relational algebra operators that are typically in the form of SQL Repository A storage place where an ontology and dictionary are stored Resources Classification of concepts into data methods and products Taxonomical hierarchy Hierarchy of classes concepts represented as superclasses and subclasses 9 Text Box A graphical user interface object that allows text to be inputted through a keyboard User The superset of the following types of user general validator and contributor Web Service Also called application services they are services usually including some combination of programming and data but possibly including human resources as well that are made available from a business39s Web server for Web users or other Webconnected programs 132 Acronyms Acronym Description DAML DARPA Agent Markup Language DBMS Database Management System DFD Data Flow Diagram GEON Geosciences Network HTML Hyper Text MarkUp Language HTTP Hyper Text Transfer Protocol OIL Ontology Interchange Language OMS Ontology Management System OMT Object Modeling Technique OWL Ontology Web Language OWLS OWLbased Web service ontology RDF Resource Description Framework SNOBASE Semantic Network Ontology Base 1 4 SOA ServiceOriented Architecture SOAP Simple Object Access Protocol SQL Structured Query Language SRS Software Requirements Specification Software Requirements Specification CS 4310 Fall 2005 Version 14 216 2006 Page 5 i 3 Software Requirements Speci cation Acronym Description TBD To Be Determined URI Universal Resource Identifier UTEP The University of Texas at El Paso XML Extensible Markup Language WSDL Web Services Description Language 133 Abbreviations ABBREVIATION MEANING cf Confer or Compare eg For example ie Such as info Information 14 Overview The SRS is divided into three major sections Introduction Section 1 General Description Section 2 and Specific Requirements Section 3 Section 1 includes five subsections Section 11 provides the purpose and intended audience of the document Section 12 describes the scope of the product Section 13 provides the definitions acronyms and abbreviations Section 14 provides the organization of the document Section 15 lists the references used in this document Section 2 includes five subsections Section 21 contains a description of the product its overall structure and its functionality Section 22 summarizes the main features of the OMS Section 23 identifies each type of users of the system This is accomplished through a summary of actors usecases and scenarios Section 24 states existing general constraints Section 25 gives the assumptions and dependencies of the OMS Section 3 includes four major subsections Section 31 contains requirements that are related to the external interface Section 32 contains the functional requirements that are organized in the following categories same class of user related realworld objects stimulus related features and limits and default settings Section 33 contains nonbehavioral requirements consisting performance and qualitative requirements as well as design and implementation constraints Section 34 outlines database operations and site adaptation requirements 15 References 1 CompuGlobalHyperMegaNet Software Requirements Specification University of Texas at El Paso December 2005 Eisen Corp Software Requirements Specification University of Texas at El Paso December 2005 l 3 EngineSoft Ontology Management System Interview Report version 21 Fall 2005 EngineSoft Software Requirements Specification University of Texas at El Paso December 2005 Gemini Software Development Software Requirements Specification University of Texas at El Paso December 2005 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Page a Software Requirements Speci cation Guidance Team Requirements Definition Document El Paso University of Texas at El Paso August 26 2005 Hades Software Requirements Specification University of Texas at El Paso December 2005 SE Mexsys Corporation Software Requirements Specification University of Texas at El Paso December 2005 N Noy and D McGuiness Ontology Development 101 A Guide bttp39 protege tanfnrd quot 39 E to Creating Your First Ontology E 1 r 10S Bechhofer F Harmelen J Hendler 1 Horrocks D McGuinness P PatelSchneider L Stein OWL Web Ontology Language Reference January 16 2006 httpwwww3orgTlVowlref 11 Solution Developers Software Requirements Specification University of Texas at El Paso December 2005 12 WSl Organization s Website January 16 2006 httpwwwwsiorg 13 MySQL Website January 18 2006 httpwwwmysqlcom 14 SNOBASE Website January 19 2006 httpwww ibm 5 Software Requirements Specification I CS 4310 Fall 2005 5 Version 14 2162006 Page Software Requirements Speci cation 2 General Description 21 Product Perspective The system described in this document is called the Ontology Management System OMS and it is designed to maintain ontologies about geoscience resources The system will provide functionality to allow geoscientists to manage concepts and related geoscience resources and to allow other users and applications to browse and query the ontologies to enhance resource discovery and integration IBM has developed a system called Semantic Network Ontology Base SNOBASE 14 that shares similarities to the OMS Like OMS SNOBASE is a framework for creating modifying querying and storing ontologies In contrast the OMS provides additional functionality that supports concurrent ontology creation and modification by including an ontology browsing mechanism and a validation process for edits The OMS also allows networkaddressable resources to be linked to ontology concepts in order to facilitate resource discovery and integration in cyberinfrastructure efforts like GEON Finally client interaction with the OMS does not depend on platformspecific API s or connectors but rather utilizes standardized serviceoriented technologies that allow client applications to use its functionality across different platforms 22 Product Features Figure 1 presents a use case diagram that provides the representation of the OMS from a user s perspective The figure sticks represent the external actors that interact with the OMS and the ovals represent the use cases supported by the OMS39 these components are described next Gmeml User Contributor Data more Validator Figure 1 Use Case diagram CS 4310 Fall 2005 5 Version 14 2162006 Page 6 5 Software Requirements Specification Software Requirements Speci cation 221 Actors The OMS classi es actors into the following groups 222 General User This actor represents a client application that performs nonadministrative tasks The General User actor provides the ability to its human user to search for concepts or resources of interest by browsing the ontology structure or by performing queries based on keywords and search types Contributor This actor represents a client application that provides its human user with the ability to propose new ontologies or modifications to existing ontologies Through the Contributor actor the human user has the ability to propose modifications to ontology structure by adding new concepts relations and setting links between concepts and networkaddressable resources Validator This actor represents a client application that provides its human user with the ability to accept or reject proposed contributions Through the Validator actor the human user typically a domain expert has the ability to review new contributions provide feedback to the contributor and accept or reject the contributions proposed Data Store This actor represents the permanent storage of the OMS The Data Store includes a DBMS and a file system The DBMS maintains metadata dictionary and user access levels The file system hosts ontology files represented in OWL Use Cases The OMS supports the following use cases 223 Retrieve The OMS provides General User actors with the ability to request ontologies by browsing or by performing queries The General User actors are responsible for providing a buffer space for the retrieved ontology and provide an adequate representation for its hum an user e g graphical Contribute The OMS provides Contributor actors with the ability to enter new ontologies to be verified by an expert and propose modifications to existing ontologies With respect to existing ontologies this use case assumes that a Retrieve use case is used in order to identify the ontology portion of interest New and modified ontologies are verified for appropriate OWL format are flagged as pending validation and are queued for validation The OMS acknowledges the Contributor actor once the new or changed ontology has been processed Validate The OMS provides Validator actors with the ability to validate proposed and modified ontologies The OMS provides a list of ontologies that are flagged as pending validation the Validator actor submits a selection from the list39 the OMS provides the original ontology along with the proposed changes the Validator actor presents both versions to the human user in appropriate format eg a visual representation of the original ontology with the proposed changes highlighted the Validator actor submits the results of the validation process the ontology is flagged accordingly and the contributing author is notified of the outcome Scenarios Each user interacts with the OMS through some specialized client application that supports the operations that are of interest to the class of user The following scenarios describe the interaction between users their client applications and the OMS Scenario for Retrieve Use Case Description The user retrieves an ontology from the OMS Actors General User Data Store Precondition A connection between the OMS and the client application has been established Trigger Condition The user initializes the retrieve functionality of the client application 1 2 The client application supports the Browse retrieval option and the user selects it The client application sends an initial request for Browse to the OMS 5 Software Requirements Specification cs 4310 Fall 2005 Version 14 2162006 Page a Software Requirements Speci cation 3 The OMS receives the initial request for Browse and responds by sending the list of available ontologies ie ontology unique ID ontology name and ontology description 4 The client application displays the ontology list in appropriate format for user presentation eg HTML 5 The user selects a particular ontology from the list 6 The client application requests the selected ontology from the OMS by sending the ontology s unique ID 7 The OMS retrieves the selected ontology from the data store in OWL format and sends it to the client application 8 The client application transforms the OWL ontology into an appropriate format for presentation to the user eg graphical 9 The user selects a particular concept from the ontology that is linked to a resource s URI The user selects the resource s URI link and is redirected to it End of use case HO Alt 1 Stepl The client application supports the Query retrieval option and the user selects it Stepll The user selects a search type ie Data Method Product or All Stepl2 The user enters concept names to query on and initiates the query action Stepl3 The client application sends the query request to the OMS Stepl4 The OMS receives the request for Query and responds by sending the list of ontologies that matched the search type and concept names specified Stepl5 The use case continues at Step 4 Alt 2 Step9 The user does not find knowledge or resources of interest within this ontology The user wants to select another ontology Step9l The use case continues at step 1 Scenario for Contribute Use Case Description The user submits a contribution ie a new ontology a change to an existing ontology a new relationship a change to an existing relationship a new synonym or a change to an existing synonym to the Actors Contributor Validator Data Store Precondition 1 The client application has access to the new contributions to be submitted or supports the functionality for the user to input the contributions to be submitted Precondition 2 The client application is able to send contributions to the OMS in OWL format ie the client application is responsible for converting user input to OWL format if necessary Precondition 3 A connection between the OMS and the client application has been established Trigger Condition The user initializes the functionality to submit a contribution in the client application The client application displays a change request form to the user The user fills the change request form specifying that the contribution corresponds to a new ontology The user references the contribution on the client application and initiates the submission The client application sends the change request form and the contribution in OWL format to the OMS The OMS receives the change request and inspects the new contribution for errors The OMS acknowledges the successful process of the change request to the client application locks the contribution to prevent any further changes and stores the new contribution on the Data Store 7 The OMS notifies a validator user through em ail of the submission of a new contribution 8 End of use case QEJ HeP N Alt 1 Stepl The user fills the change request form specifying another type of contribution Stepll The use case continues at Step 3 Alt 2 Step6 The OMS finds that the contribution is not in valid OWL format Step6 l The OMS sends a notification message to the client application about the incompatible format Step62 End of use case 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Page 8 Software Requirements Speci cation Alt 3 Step6 The OMS finds that the contribution received references relationship names that are not registered in the Relationship Table Step6l The OMS sends a notification message to the client application containing a list of relationships that are not present in the Relationship Table and suggests that the user should either update the Relationships Table or the Synonyms Table accordingly before attempting the submission again Step62 End of use case Scenario for Validate Use Case Description The user analyzes the submitted ontology contribution and decides whether to accept reject or request additional information from the contributor Actors Contributor Validator Data Store Precondition A connection between the OMS and the client application has been established Trigger Condition The user initiates the functionality to validate contributions in the client application 1 The client application sends an initial request to the OMS for the list of change requests 2 The OMS retrieves the list of change requests from the data store and sends it to the client application 3 The client application displays the list of change requests in appropriate format for the user 4 The user selects an item to validate from the list and initializes the validation process 5 The client application sends the user selection to the OMS 6 The selected change request corresponds to a new contribution ie a new ontology a new relationship or a new synonym entry the OMS retrieves the change request and the corresponding contribution from the data store and sends it to the client application 7 The client application displays the change request form and the contribution in appropriate form at for the user 8 The user inspects the contribution against the Change Request description and decides that the contribution is valid 9 The user updates the change request form to re ect the validation outcome and initiates the submission 10 The client application sends the updated submission form to the OMS ll The OMS receives the submission form notifies the contributor about the outcome updates the metadata information of the contribution to indicate a validated entry and unlocks the contribution 12 End of use case Altl Step6 The selected change request corresponds to the modification of an existing item ie an ontology change a relationship change or a synonym change Step6l The OMS retrieves the change request the corresponding contribution and the existing data that is being targeted by the change request Step62 The client application displays the change request form the contribution and the targeted data in appropriate format for the user Step62 The use case continues at Step 8 Alt2 Step8 The user inspects the contribution against the Change Request description and decides that the contribution is not vali Step8l The user updates the change request form to re ect the validation outcome providing feedback to the contributor and initiates the submission Step82 The client application sends the updated submission form to the OMS Step83 The OMS receives the submission form notifies the contributor about the outcome and sends himher the feedback from the validator and discards the contribution from the data store Step83 End of use case Alt3 Step8 The user inspects the contribution against the Change Request description and decides that more information is needed in order to make a decision Step8l The user updates the change request form to re ect the validation outcome providing feedback to the contributor and initiates the submission Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Page 9 Software Requirements Speci cation Step82 The client application sends the updated submission form to the OMS Step83 The OMS receives the submission form notifies the contributor about the outcome and sends himher the feedback from the validator Step83 End of use case 23 User Characteristics There are three types of users that will interact with OMS via client applications A description of the users follows 1 The General User class represents users interested in browsing or querying ontologies The typical user of this class has basic computer usage skills and is knowledgeable in the Geosciences not necessarily an expert The Contributor class represents users interested in contributing to the knowledge represented in the ontology repository The typical user of this class has basic computer usage skills and is knowledgeable in the Geosciences most probably having a niche of expertise 2 The Validator class represents users that perform administrator tasks on the system and that serve as gatekeepers of the contribution process of the system The typical user in this class is a computer power user ie has computer usage skills beyond the basic level without necessarily being an expert user Furthermore this class of user is an expert geoscientist or has commanding knowledge to evaluate contributions from others 3 24 General Constraints The general constraints on the development of the system are as follows 0 The system will be completed by the end of May 2006 The Ontology Management System will be implemented in C The DBMS will be implemented in MySQL 50 25 Assumptions and Dependencies The assumptions are as follows The Access Table has been created for a relational database For every entry in the Access Table there is a corresponding entry based on UserlD in a table that maintains information about the contributor eg name contact information and associated organization The maintenance of the Access Table is outside the scope of the project All users have at least basic computer skills The username and password for users will be encrypted Management of synonyms for concept names will be added in a future version of the system The Change Request mechanism will have extended functionality in a future version of the system The development team will use this SRS to implement the system 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Page Software Requirements Speci cation 3 Speci c Requirements 31 External Interface Requirements This section contains the specification of requirements for interfaces among different components and their external capabilities including all its users both human and other systems Interdependencies or constraints associated with interfaces are identified 311 User Interfaces This section describes a generic user client interface that utilizes the OMS Given that the OMS is based on an SOA there can be numerous client interface implementations Each implementation would only provide the specific interactions that it requires to accomplish the goals of its context 3111 General Interface SRSreq 01 The client interface shall allow the user to provide a user name and a password to the OMS either directly or through some centralized singlesign on mechanism SRSreq 02 The client interface shall not show the user password in cleartext format at any time SRSreq 03 The client interface shall provide a notification mechanism that displays the following message when he or she has an incorrect user name or password Invalid user name or passwor SRSreq 04 The client interface shall provide a notification mechanism that displays the user s access privilege evel when the user is signed on SRSreq 05 The client interface shall be implemented using standard GUT components I textbox fields to allow entering editing or displaying textual data39 command buttons to allow the user to confirm the initialization of interaction with the OMS39 checkbox fields to allow the user to set or unset a given Boolean option on the OMS39 radiobutton fields to allow the user to choose a Boolean option among a group of options on the OMS39 and listbox or combobox fields to allow the user to choose a textual input from a list of options on the OMS SRSreq 06 The client interface shall use datagrid fields when entering editing or displaying tablelike data SRSreq 07 The client interface shall use XML editor components when entering editing or displaying XML data SRSreq 08 The client interface shall provide HTML searchresult components to display retrieval results from the OMS as described in Section 32 and to allow the user to follow links contained in the displayed results Page 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Software Requirements Speci cation 3112 Visualization Interface SRSreq 09 The client interface shall provide Ontology Visualization components to transform ontologies provided by the OMS in OWL format and display them in graphical representations or to allow the user to input or modify ontologies in graphical representations and transform them into OWL form at for input into the OMS SRSreq 10 The client interface shall provide two ways for begin visualizing an ontology query or navigation I A query shall return all concepts in which the keyword given in the query appears when the user clicks on a concept the concept shall be displayed I The user shall be able to navigate an ontology by selecting a one of the following concepts eg data product or method SRSreq 11 Each of the concepts associated with the categories of Data Method and Product shall have its own unique color purple blue and green respectively SRSreq 12 The system shall display a Note shape next to each concept that has relationships associated with it as shown in Fig 2 1 List of relationships for one concept Relationships ix 1 Bouguer Anomaly derived 39om Bouguer Correction M 2 Bouguer Anomaly derived 39om Drilt Correction about 3 Bougu er Anomaly derived 39om Tidal Correction about 4 Bougu er Anomaly derived 39om Free Air Correction about 5 Bouguer Anomaly derived 39om Latitude Correction about 6 Bouguer Anomaly used for Anomaly Map about Child relationships Ba Bung r Anomaly used for EuuguErANDmalV Map about 7 Bouguer Anomaly part of Complete Bouguer Anomaly about 8 Bouguer Anomaly input into Interpretation about cnnd relationships Ea BuuguErAnumaly mm m Forward Modeling abuut an EluuguerAnumaiy input into inverse Modeling abuut 39 EndF iRef hllp Figure 2 Relationships list 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Page 12 Software Requirements Speci cation SRSreq 13 When the user clicks on the Note shape of a concept the system shall display all tuples ltDomainConceptName relationshipName RangeConceptNamegt that represent all direct and implied relationships ie child relationships in which the concept associated with the Note shape is the domain concept as shown in Fig 2 SRSreq 14 1f the Range Concept is a parent concept then the tuple in the list of relationship tuples shall be distinguished with a tag or marking to inform the user that the children of the Range Concept are also related to the Domain Concept as depicted in Fig 2 SRSreq 15 When the user selects a relationship the visualization component shall show the relationship to the concept as shown in Fig 3 mm derivedFrom 3 Gravity Gravity Data 77777777777777777777777777777777777777777777777777 Correction Figure 3 Example of a general relationship SRSreq 16 A user shall be able to navigate an ontology using indicator arrows as shown in Fig 4 that allow e user to expand the concept to view the parents up arrow view the left sibling left arrow view the right sibling right arrow or view two children down arrow Figure 4 Indicator arrows for a concept SRSreq 17 The following method shall be used to view a concept in an ontology where the display is centered on the primary node n see Fig 5 Node 1 n Node 2 parent of n Node 3 left sibling of n Node 4 right sibling of n Node 5 child 1 ofn Node 6 child 2 of n SRSreq 18 If a primary node has more than one parent then the display shall show only one parent and an indicator arrow shall remain with the primary node as depicted in Fig 5 5 Software Requirements Specification CS 4310 Fall 2005 5 Version 14 2162006 Page w Software Requirements Speci cation SRSreq 19 If a prim ary node has more than two children then the display shall show only two children and a left right indicator arrow shall appear on the first second child node that is displayed if the display can be expanded to show another child node CnnEEpILS Figure 5 Multiple Parents and selecting up indicator arrow SRSreq 20 When the user selects the about text in a concept the visualization component shall display a textbox with the metadata associated with the concept as depicted in Fig 6 SRSreq 21 When the user selects the about text associated with a relationship the visualization component shall display the metadata ie the description associated with the relationship as depicted in Fig 6 SRSreq 22 When the user selects the URI of the concept the resource pointed to by the URI shall be redirected to that resource 1 Metadata for a relationship Relationships l l i uses Emu uerCurrectlun about 2 nuuguerAnrmall Dane t b t BuuguerAnumalyialuesaregnddedandthenusedlucreates WWW WWW 555 quotEE D a D BuuguerAnumalyMapsand displayedmmermmurasuri aee a auueuer Annmalv uses Tldal Correctlun about 4 EuuuuerAnnmaly uses Free Air Correctlun about 5 Euuuue Annmaly uses Latltude Correctlun about 6 BungllErAanalv useu rur Anomaly Map about 7 EuuguelAnumalv quot useurur Complete Beugiieranumaly about a BouquerAnnrnaly useurur lrlterpretatlurl about cniu reieimnsnps Ea eeuuuerananen sew Favvmm Madellng sham Eb Enugllev Anomaly useu my lrlvevse Made lrlg complete m eouguerAnoiiialy Figure 6 Metadata associated with a concept and a relationship 5 Software Requirements Specification I CS 4310 Fall 2005 5 Version 14 2162006 Page as Software Requirements Speci cation 312 Hardware Interfaces There are no requirements for hardware interfaces 313 Software Interfaces This section describes the interfaces and formats of interaction between the different components of the OMS SRSreq 23 The OMS shall use the OWL format to handle all ontology data interactions between the service and client applications and between the service and the data store SRSreq 24 The OMS shall use XML to handle all metadata interactions between the service and client applications SRSreq 25 The data store component of the system shall provide two interfaces a DBMS implemented as MySQL 50 and a file system implemented as NTFS 314 Communications Interfaces This section contains requirements that pertain to the communication interfaces between the OMS and the client applications and between the OMS and the data store SRSreq 26 The OMS shall use the HTTPSOAP messaging protocol between the service and the client applications as prescribed by the Basic Profile 11 and the Attachments Profile 10 proposed by the Web Services Interoperability Organization 12 SRSreq 27 The interaction between the OMS and the DBMS component of the data store shall be carried out through the MySQL Net Connector 107 SRSreq 28 The interaction between the OMS and the file system component of the data store shall be carried out by a dedicated secured connection 32 BehavioralRequirements This section contains behavioral requirements related to Same Class of User Related RealWorld Objects Related Features Stimulus and Functional 321 Same Class of User This section presents the requirements associated with a particular class of user For complete requirements associated with the functionality given in Table 1 refer to Section 323 SRSreq 29 The OMS shall provide the following access levels with user privileges summarized in Table l I General User Contributor Validator 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Page Software Requirements Speci cation Table 1 Privileges by Access Level PRIVILEGEs GENERAL USER CONTRIBUTOR VALIDATOR Retrieve validated ontologies V V V Navigate ontologies V Post an ontology 444 Edit an ontology Retrieve ontologies pending validation 44444 Validate an ontology SRSreq 30 Users shall not be subject to authentication by the OMS to access privileges at the General User access level SRSreq 31 The OMS shall provide authentication mechanisms to allow users to log in to secure Contributor or Validator access levels SRSreq 32 All operations of the OMS shall be subject to authorization mechanisms that verify that an operation is supported for the user initiating the operation as per Table l SRSreq 33 The 39 39 and authoii atiou 39 of the OMS shall be based on the Access Table Schema illustrated in Table 2 SRSreq 34 The authorization Access Table cf Table 2 shall be hosted on the DBMS component of the data store Table 2 Access Table Schema Attribute Type Constraint CommentsDescription acceSSLevel VARCHARO 0 Must be Contributor or Validator Access level used to authorize Default Contributor user Operations Password must be at least 8 characters long and must contain at least one Password used to authenticate password VARCHAR16 digit The password cannot be the a user s ID when logging into same as the userID and is case the system sensitive UserID must be 816 characters andor 1153112 VARCHAR16 numbers must be unique within the Identi er for a person logging system and is case sensitive mto SyStem Page 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 m Software Requirements Speci cation 322 Realworld objects are entities with either physical or conceptual counterparts in the real world The object modeling diagram is given in the appendix The syntax and semantics of OWL can be found in the OWL Web Related Real world Objects Ontology Language Reference document 10 3221 Ontology SRSreq 35 An ontology shall be maintained in OWL format and stored as XML files on the file system component of the data store SRSreq 36 All ontology concepts in the OMS shall be descendants of one of the following root concepts Data Method or Product SRSreq 37 GEON resources represented in the ontology shall be attached as URI references to leaf concepts on the ontology through annotation OWL tags cf Appendix B SRSreq 38 Ontologies shall support the addition of concept metadata through associated text in the OWL declaration of the ontology SRSreq 39 The valid domain associated with an ontology shall be one of the following Gravity Seismology Satellite lm agery Magnetic Physical Properties 3222 Ontology Metadata SRSreq 40 The OMS shall maintain the metadata provided in Table 3 for all registered ontologies and this metadata shall be stored in the DBMS component of the data store Table 3 Ontology Metadata Table Schema Attribute Type Constraint CommentsDescription OntolD PK VARCHAR9 Unique identifier for the ontology Ontology Name VARCHARQO Ontology Name Valid entries gravity The geoscience knowledge area Domain VARCHARQO seism ology magnetic satellite from which the ontology imagery physical properties knowledge is captured Identification of validator FK to Validator lD VARCHARO 6 UserID in Access Table Validated BOOLEAN Default False Tm 1f GritOIOgy has b en validated false otherw1se Description of ontology and Descnpnon VARCHARO 00 community that contributes to it 5 Software Requirements Specification CS 4310 Fall 2005 Page Version 14 2162006 17 Software Requirements Speci cation Ref to the OWL file on the file OntoRef VARCHAR30 system component of the data store 3223 Relationship Table SRSreq 41 The OMS shall maintain a dictionary as described in Table 4 for all relationships of all registered ontologies and this dictionary shall be stored in the DBMS component of the data store Table 4 Relationships Table Schema Attribute Type Constraint CommentsDescription Identifies ontology to which the dictionary is associated ontOID VARCHAR9 FKOntolD in Ontology Metadata Table Naming Convention lower case letter for the first character of the name no Primary Key name of the RelanonShleame VARCHARQO spaces between words and relationship eg islnputTo the subsequent words begin with a capital letter lnverseRelationshipName VARCHAR20 girti gi lira111 Type of the relationships domain where D Data P Product Vahd entr1es include D P DomainType CHAR3 M Method M DP DM PM DPM DP Data or Product DM Data or Method PM Product or Method DPM Data Product or Method Valid entries include D P Type of the relationships RangeType CHARG M DP DM PM DPM range see above Description VARCHAR75 0f the 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Page Software Requirements Speci cation SRSreq 42 The OMS shall maintain a table of records as described in Table 5 for all synonyms associated with a relationship name Table 5 Relationship Synonyms Table Attribute Type Constraint CommentsDescription RelationshipNamel VARCHAR20 Foreign key Relationship table RelationshipNameZ VARCHAR20 Relatlonshlpmme the synonym Primary key SRSreq 43A relationship shall be displayed as a tuple ltDomainConceptName RelationshipName RangeConceptNamegt SRSreq 44 A subclass of a concept shall inherit the relationships and properties of the parent concept 3224 Change Requests SRSreq 45 The Change Request Table shall be used to manage changes to an ontology SRSreq 46 The Change Request Table shall contain an entry for each type of change ie ontology concept relation and metadata SRSreq 47 The Change Request Table shall contain the following fields I OntolD identification number of the ontology if not a new ontology I Change one of the following o Ontology lt Add gt ltnewOntologyNamegt ltOWLrepresentationgt ltdictionary Tablegt ltOntologyMetadatagt 0 Concept lt Add Modify gt ltconceptNamegt lttextgt ltmetadatagt 0 Relation lt Add Modify gt ltrelationNamegt ltlnverseRelationNamegt ltDomainTypegt ltRangeTypegt ltDescriptiongt 0 Concept Delete ltconceptNamegt 0 Relation Delete ltrelationNamegt 0 Relation Delete ltrelationNamegt ltDom ainConceptNamegt ltRangeConc eptN am egt I Description the description of the added ontology or changes I Status PendingAcceptReject SRSreq 48 Entries by the contributor to the Change Request Table shall automatically be entered as Pending for Status Page Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 w Software Requirements Speci cation 323 Related Features This section describes requirements of related features and is divided into Browse Query Contribute and Validate SRSreq 49 All service requests from client applications to the OMS shall include appropriate user credentials to carry out the authentication and authorization mechanisms as described in the Same Class of User requirements of Section 32 1 3231 Retrieval SRSreq 50 The OMS shall be able to process a request to view a list of all available ontologies in the data SRSreq 51 The OMS shall be able to process a request to retrieve an ontology based on the ontology ID OntolD SRSreq 52 The OMS shall be able to process a request that retrieves a list of ontologies based on the concept name 3232 Contribute SRSreq 53 Submissions of a new ontology shall include the following information ontology name39 domain39 description the OWL representation of the ontology39 and the metadata associated with the ontolo SRSreq 54 An ontology that has changes submitted by a contributor shall be locked for further edits SRSreq 55 If an ontology is locked for edits then the dictionary associated with the ontology shall be locked SRSreq 56 If an ontology is unlocked then the dictionary associated with the ontology shall be unlocked SRSreq 57 The OMS shall assign a unique OntolD number to a new ontology that is submitted as follows NNYYMMDDL where NN are the first two characters of the corresponding domain name39 YYMMDD is the year month and day of the submission39 and L signifies a letter that is used to distinguish ontologies that may be submitted on the same date in the same domain where the first submission is A and subsequent submissions follow the order of the alphabet SRSreq 58 The OMS shall store the OWL file of a new ontology into the file system component of the data store by assigning it a file name that reflects the OntolD 3233 Validate SRSreq 59 The OMS shall support a request that returns a list of ontology IDs and ontology names that are pending validation ie that have their Validated field set to false in the Ontology Metadata Table cf Table 3 and an indication of whether it is a new ontology or a changed ontology SRSreq 60 The OMS shall support a request that includes an ontology ID of a changed ontology that is pending validation and that returns the list of changes as described in Section 3224 SRSreq 61 The OMS shall support a request from a Validator user to change the Status field of the Change Request Table to Accept or Reject 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Page Software Requirements Speci cation SRSreq 62 The OMS shall support a request from a Validator user to replace an existing ontology with the ontology that contains the approved changes 324 Stilnulus The following section describes the stimuli of the system depending on different operations offered by the OMS 3241 Retrieval SRSreq 63 When the OMS receives a retrieval request based on browsing the OMS shall return OntolD OntoName and Description cf Table 3 for each ontology in the data store SRSreq 64 When the OMS receives a request for retrieving a list of ontologies based on the substring provided for a concept name the OMS shall examine each OWL class tag cf Appendix B2 in each ontology in the data store and for any ontology for which the substring matches a string given in the concept name field the OMS shall include that ontology ID in the list of returned ontologies SRSreq 65 When the OMS receives a request from a client application to retrieve an ontology the OMS shall check the status of the ontology create a copy of the requested ontology and send an OWL representation of the ontology along with its corresponding dictionary to the client application that made the request SRSreq 66 When the OMS receives a request from a client application to retrieve an ontology and the ontology is locked the OMS shall display the following warning message The selected ontology is locked for editing and pending validation39 it does not re ect pending updates SRSreq 67 When the client application requests an ontology the OMS shall check the ontology s status and acknowledge the client application accordingly 3242 Contribute SRSreq 68 When a new ontology is submitted for validation the ontology shall be added as a file to the data store SRSreq 69 When an ontology is submitted for validation an entry in the Ontology Metadata table cf Table 3 shall be created that stores the information from the Change Request into the table that sets the Validated field to false and that enters a reference to the file stored in the data store SRSreq 70 When a new or changed ontology is submitted for validation the OMS shall check that all relationships in the ontology are entered in the Relationships Table cf Table 4 before accepting the submission SRSreq 71 When a new ontology has been accepted for submission OMS shall return the generated OntolD to the client application SRSreq 72 If one or more relationships in a submitted ontology are missing from the Relationship Table the OMS shall return the following error message The following relationships ltltlist of relationship namesgtgt could not be found in the relationship table Please add an entry add a synonym or check the spelling before resubmitting your ontology 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Page Software Requirements Speci cation SRSreq 73 When a change request is made to delete or modify a concept and the concept name does not exist in the ontology the OMS shall return the following error message Change request on invalid concept name SRSreq 74 When a change request is made to delete or modify a relation and the relation name does not exist in the ontology the OMS shall return the following error message Change request on invalid relation name SRSreq 75 When a change request is made to delete a concept the OMS shall return the following warning message Your change will impact the following relations ltltlist of relationship namesgtgt SRSreq 76 When a change request is made to delete a relation the OMS shall return the following warning message Your change will impact the following concepts ltltlist of concept namesgtgt SRSreq 77 When a contribution has been successfully submitted for validation the OMS shall send the following acknowledgement message via email to the registered validator The following ontology has been submitted for validation ltontolDgt SRSreq 78 When the OMS responds to a submission with a warning message the OMS shall wait for confirmation from the user before accepting the contribution SRSreq 79 When the OMS accepts a contribution the OMS shall return the following message Thank you or your submission You will be notified when your submission has been validated SRSreq 80 When the OMS responds to a submission with an error message the OMS shall cancel the submission request 3243 Validate SRSreq 81 When a client application requests the validation service the OMS shall return the ontolD ontology name and ontology description for all new and modified ontologies that have been submitted for validation SRSreq 82 When the OMS receives a request for validation of a modified ontology the OMS shall return the ontology its corresponding dictionary and send a list of the modified ontologies along with its corresponding dictionary to the client application SRSreq 83 When a validator viewrequest is made to view a submission the OMS shall return the original ontology and the changed ontology SRSreq 84 Any part of the ontology that is not changed shall remain unchanged when the ontology is updated SRSreq 85 When the OMS receives a request from the client application using the validation service to extract an ontology with status pending for validation the OMS shall extract and return the requested ontology its corresponding dictionary and a list of each modification to the ontology along with its justification SRSreq 86 When the OMS receives a request from the validator application to accept a contribution the OMS shall change the status of an ontology to unlocked SRSreq 87 After the ontology status has been changed to unlocked the OMS shall send an acknowledgement to the contributor stating that the contribution was accepted SRSreq 88 When the validator rejects a contribution to an existing ontology the client application sends a request to the OMS to reject the ontology and the reject request includes the ontolD and text to provide feedback to the contributor Page 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Software Requirements Speci cation SRSreq 89 When the OMS receives a request to reject ontology ltontolDgt the OMS shall unlock the ontology associated with ltontoldgt the OMS shall send a message to the contributor stating that The contribution to ontology ltontolDgt was rejected and the OMS shall send the feedback provided by the validator SRSreq 90 When the OMS receives a Delete request from the validator client application to delete ontology ltontolDgt the OMS shall remove the OWL file associated with ltontolDgt and all the entries associated with ltontolDgt from the following tables Metadata Relationship and Synonym SRSreq 91 When the OMS receives a Delete request from the validator client application to delete a concept the OMS shall remove the concept and all relations associated with the concept SRSreq 92 When the OMS receives a Delete request from the validator client application to delete a relation that does not include ltDom ainConceptNamegt and ltRangeConceptNamegt the OMS shall remove all relations SRSreq 93 When the OMS receives a Delete request from the validator client application to delete a relation that includes ltDomainConceptNam egt and ltRangeConceptNamegt the OMS shall only remove the relation between ltDomain and ltR angeF and nothing else 1 SRSreq 94 When the OMS receives an Add request from the validator client application to add a new concept then the lttextgt and ltm etadatagt parameters shall not be empty SRSreq 95 When the OMS receives an Modify request from the validator client application to modify concept denoted by ltconceptNamegt the OMS shall modify on those parameters ie lttextgt and ltmetadatagt that are not empty SRSreq 96 When the OMS receives an Add request from the validator client application to add a new relation then the ltrelationNamegt ltlnverseRelationNamegt ltDomainTypegt ltRangeTypegt and ltDescriptiongt parameters shall not be empty SRSreq 97 When the OMS receives an Modify request from the validator client application to modify the existing relation denoted by ltrelationNamegt the OMS shall modify only those parameters ie ltlnverseRelationNamegt ltDomainTypegt ltRangeTypegt and ltDescriptiongt that are not empty 3244 Authentication and Authorization SRSreq 98 When the OMS cannot authenticate the user the OMS shall return an error message stating invalid user SRSreq 99 When the OMS cannot authorize an operation for a given user the OMS shall return an error message starting invalid operation for current access level privileges 325 Functional Functional requirements are specified in other sections 33 Nonbehavioral Requirements This section includes requirements relating to performance qualitative requirements maintainability portability security and design implementation and contraints 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Software Requirements Speci cation 331 Performance Requirements There are no performance requirements specified at this time 332 Qualitative Requirements There are no qualitative requirements specified at this time 333 Maintainability There are no maintainability requirements specified at this time 334 Portability SRSreq 100 There shall be no platform dependencies on the client applications of the OMS other than the platform requirements specified in the Communication Interfaces described in Section 314 and the Security requirements listed in Section 333 335 Security SRSreq 101 All usercredential data exchange between the OMS and client applications shall be encrypted and carried out over a secure connection SRSreq 102 All data exchange between the OMS and client applications that result in the modification of the data store shall be carried out over a secure connection 336 Design and Implementation Constraints There are no design and implementation requirements specified at this time 34 Other Requirements This section includes requirements relating to database structures and operations any special operations required by the user and any installation or software portability issues There are no other requirements specified at this time 5 Software Requirements Specification CS 4310 Fall 2005 5 Version 14 2162006 Page Software Requirements Speci cation Appendix A Diagrams A1 Ontology OMT Diagram The ontology OMT diagram is given as reference to illustrate the different components of an ontology A 5 translated by EXISKIng A insial lldtes gt5 mganlled as 5 a sneualizauun a Figure Al Ontology OMT Diagram Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006 Page Software Requirements Speci cation A2 Data Flow Diagrams i Scenario 1 Retrieve Requested Ontulugy 1 Retrieve Ontology ommu Que w W OntulugyLlst Elmvvse Seleetlun Requested Ontulugy Ontulugy Lls t OM S Repository Requested Ontulugy Display Geusmentlst Resuuree Selman 2 Retrieve Resource Figure A 2 Level 1 Retrieve DFD I CS 4310 Fall 2005 Version 14 2162006 5 Software Requirements Specification N as Software Requirements Speci cation ii Scenario 2 Contribute Scenario 3 Validate A3 State Charts iv Scenario 3 Contribute ruser ame vahd H rpasswprd vahd Error Message Locked Cheek eprnptete Vahd Reset Entry epnneettp OMS and Send Errpr Message ersptay tpgrn prprnpt Edtt Ontptpgy Cheek eprnptete r Post StVahd Reset retumVahd retatrpn Du Process username and password Ontptpgy supmrtFperstmg t true F39us name vahd e passwpru vahd Post terse seteetomptpgytomptpgy rantptpgy lucked uk0ntuugy Dretrpnary Cheek Seteet ntptpgy Cheek eprnptete Post StVahd Reset emaH Dumarn Expert Post Ontptpgy seteetomptpgytomptpgy Ontptpgy lucked Figure A 3 Editing StateChart V Scenario 4 Validate Version 14 2162006 5 Software Requirements Specification 39 CS 4310 Fall 2005 Software Requirements Speci cation Appendix B OWL format B1 OWL Base Ontology The following OWL code is given as a reference for the heading name spaces that should be referenced in all ontologies hosted in the OMS The ontology describes the Data Method and Product concepts that should be imported into all ontologies ltxml versionH l 0 gt ltrdfRDF mnhisquothttputepgeon01utepeduoms2006Olomsowl xmlnsoms httputepgeon01 utepeduoms2006Olomsowlquot xmlbasequothttputepgeon01utepeduoms2006Olomsowlquot xmlnsowlquothttpWWWW3org200207owl xmlns rdfquothttp WWWW3 orgl 9990222rdfsyntaxns mnhisrdfsquothttpWWWW3org2000Olrdfschem aquot xmlnsxsdquothttpwwww3org2001XlAL Schema xmlnsdam 1quothttpWWWdamlorg2001O3dam loil gt ltowlOntology rdfabout quotgt ltrdfscommentgtBase OWL ontology for the Ontology Management Systemltrdfscommentgt ltrdfs labelgtD ataMethodProduct Ontologyltrdfs labelgt ltowlOntologygt ltowlClass rdflD Product gt ltowlClass rdflD Dataquotgt ltowlClass rdflD Method gt ltrdfRDFgt B2 Concept Name Tag The following tag illustrates an example declaration of a concept Within an OWL ontology I ltowlClass rdflDH ltltconcept namegtgt gt 5 Software Requirements Specification CS 4310 Fall 2005 Version 14 2162006