Natural Language Requirements
|
|
- Andrea Hodge
- 6 years ago
- Views:
Transcription
1 Natural Language Requirements Software Verification and Validation Laboratory Requirement Elaboration Heuristic Domain Model» Requirement Relationship Natural Language is elaborated via Requirement application of follows Syntactic Requirement Pattern OCL Constraint refers to concepts from is constrained by» refers to concepts from is constrained by º is refined by is expressed in is related to is expressed in is formalized by Use Case» is augmented by» System Sequence Diagram MARTE Profile SysML Requirement Diagram follows 2 Use Case Template (RUCM) 1
2 Basics of NL Requirements What is a Natural Language (NL) requirement? - A natural language requirement is a requirement that is documented using a natural language (for example, English, French, German) - Also known as textual requirement Example A functional requirement in NL: If a glass break detector at the window detects that the pane has been damaged the system shall inform the security service. NL requirements mingle conceptually distinct elements: - Domain concepts: glass break detector, window, pane, system, security service - Function: detects, inform the security service - Behavior: if [ ] damaged, then inform [ ] Basics of NL Requirements II Quality properties may further be added into the mix Example A functional requirement in NL: If a glass break detector at the window detects that the pane has been damaged the system shall inform the security service within 2sec at the latest. Problem: One or more parts of the specification may be overlooked! General best practice: Separate function and quality Example RF1: The glass break detector at the window shall detect if the glass pane is damaged. RF2: If the detector detects damage to the pane (see RF1), the system shall inform the security service. RQ1: The system shall inform the security service (see RF2) within 2sec after detecting damage. 2
3 Advantages and Disadvantages of NL Requirements Advantages: Universal: Natural language can be used in any problem area or domain Flexible: natural language allows arbitrary abstractions and refinements during requirements documentation. Comprehensible: Requirements documented in natural language are comprehensible to many stakeholders since no training or special tools are required Disadvantages: Under-specification: if details about a requirement are not documented, different stakeholders can assume different details and thereby interpret the requirements in different ways Ambiguity: Even careful specification cannot remove the ambiguity entirely! Ambiguity in NL Lexical Ambiguity Lexical Ambiguity Caused by synonyms (different words for the same concept) and homonyms (same word for different concepts) Example of synonyms: car / automobile, small / little Example of homonyms: trunk (different meanings in botany, zoology, normal use, American English) Synonyms and homonyms a major source of ambiguity in requirements - mainly because stakeholders use different vocabularies 3
4 Ambiguity in NL Syntactic Ambiguity Syntactic Ambiguity When the same sentence can convey multiple different meanings Example: The navigation systems shall display the last five destinations and starting points. Interpretation 1: Display the last five items entered, be those destinations or starting points Interpretation 2: Display the last five destinations and a set of starting points Interpretation 3: Display the last five destinations and the last five starting points. Ambiguity in NL Semantic Ambiguity Semantic Ambiguity subsumes syntactic and lexical ambiguity Sentences having different interpretations due to syntactic and/or lexical ambiguity Syntactic / lexical ambiguity Semantic ambiguity Sentences having different interpretations despite having no syntactic and/or lexical ambiguity Example: (1) If a window of the car is is damaged and and the interior surveillance (2) of the car detects the interior an intruder surveillance or a door of the of the car car detects is opened an intruder without a or car key, the safety a door system of the car shall is raise opened an alarm. without a car key then (3) Interpretation 1: if (1) AND [(2) OR (3)] then (4). Interpretation 2: if [(1) AND (2)] OR (3) then (4). 4
5 Ambiguity in NL Referential Ambiguity and Vagueness Referential Ambiguity If a word or phrase in a sentence refers to an object and there are different interpretations regarding what this object is. Example: The customer inserts the access card into the card reader and enters a personal identification number (PIN) at the keypad. If it is invalid, the system shall deny the access. Unclear what it refers to, the access card or the PIN. Ambiguity of terms (vagueness) Example: All medium-sized vehicles shall be equipped with a navigation system. Unclear what medium-sized means Avoiding Ambiguity Glossaries Collection of technical terms that are part of the language (terminology) in a given domain. Aimed at addressing lexical ambiguity and vagueness Common structure for a glossary: Term Definition Synonyms Related terms Examples/ Counter examples name of term definition text synonym-1; term-1; references to examples / counter examples 5
6 Glossary Example Term Definition Route The specific instance of a direction from a starting point to a destination Synonyms Related terms Examples/ Counter examples Itinerary Alternative route (specialization) [Link to a map showing an example route] Guidelines for Building Glossaries 1. Define a structure for the glossary entries to be used by all authors editing glossary entries 2. Regularly check the structure of the glossary 3. Ask stakeholders with different backgrounds to provide their own definition of a term and align the definitions obtained 4. If you question whether a term should be defined in the glossary, it is better to define the term rather than leaving it out 5. Involve stakeholders with different backgrounds to review the glossary entries, comment on existing definitions, and identify missing ones. 6. Make the glossary available online as hypertext, if possible. 7. Provide support for managing the glossary on an intranet or the Internet, for example through a wiki 6
7 Requirement Elaboration Heuristic Domain Model» Requirement Relationship Natural Language is elaborated via Requirement application of follows Syntactic Requirement Pattern OCL Constraint refers to concepts from is constrained by» refers to concepts from is constrained by º is refined by is expressed in is related to is expressed in is formalized by Use Case» is augmented by» System Sequence Diagram MARTE Profile SysML Requirement Diagram follows 13 Use Case Template (RUCM) Avoiding Ambiguity Using Requirement Patterns What is a requirement pattern? A (syntactic) requirements pattern defines a syntactic structure for documenting requirements in NL and defines the meaning of each part of the syntactic structure. Aimed at addressing syntactic ambiguity Patterns are to some extent tailorable to the application domain 7
8 Requirement Pattern (by Rupp) Requirement Pattern (by Rupp) <When> defines conditions under which the function documented in the requirement is to be performed or provided. 8
9 Requirement Pattern (by Rupp) The name of the system which provides the documented function. This systems is the grammatical subject of the sentence. Requirement Pattern (by Rupp) Shall/should/will/ : indicates the importance of the requirement. 9
10 Requirement Pattern (by Rupp) Indicates the required functionality. Three patterns are distinguished: 1. <process>:applies to requirements that document functionality that they system offers independently of interactions with users 2. PROVIDE <whom?> WITH THE ABILITY TO <process>: applies to requirements that document functionality that the system provides to specific users 3. BE ABLE TO <process>: applies to requirements that the system performs as reactions to trigger events from other systems. Requirement Pattern (by Rupp) Describes the object for which the functionality is required. The object as well as its additional details are documented after the process. 10
11 Requirement Pattern (by Rupp) Example: If the glass break detector detects the damaging of a window, the system shall inform the head office of the security service. [<when>: If the glass break detector detects the damaging of a window] THE SYSTEM SHALL [<process>: inform] [<object>: the head office of the security service.] Guidelines for Application of Requirements Pattern I Step 1: Determine legal obligations Usually, the following cases are distinguished Legally obligatory SHALL Urgently recommended SHOULD Future requirement WILL Alternatively, legal obligation can be captured as a requirement attribute. Step 2: Determine the requirement core The core is the functionality that the requirement specifies Examples: print, save, paste, or calculate Corresponds to the process slot in the requirement template Processes are activities and can only be verbs 11
12 Guidelines for Application of Requirements Pattern II Step 3: Characterize the activity of a system Functional requirements can be classified into three types: Autonomous system activity: The system performs the process autonomously The user does not interact with the activity. User interaction: The system provides the process as a service for the user, for example through an input interface, or direct interactions Interface requirement: The system performs a process depending on a third party. Whenever messages or data are received from a neighboring system, the system must react by executing specified behavior. Relation of Step 3 to requirement template: Autonomous system activity <process> User interaction provide <whom?> WITH THE ABILITY to <process> Interface requirement BE ABLE TO <process> Guidelines for Application of Requirements Pattern III Step 4: Insert Objects Some process verbs require one or more additional objects For example, the process verb print is amended by information of what is being printed and where it is printed. Step 5: Determine logical and temporal conditions Corresponds to the <when> part of the pattern Useful to differentiate between logical and temporal conditions Recommended: Use As soon as for temporal conditions and if for logical conditions. when cannot clarify this distinction 12
13 Avoiding Ambiguity Controlled Languages What is a controlled language? Two major components: A grammar that imposes precisely defined constraints on the natural language A set of terms (including the term s semantics) to be used within the grammar Can be used to address all aspects of ambiguity Advantages of controlled languages Resulting requirements are easy to understand, since they are still in natural language Less proneness to ambiguity since a simplified grammar and a precisely defined vocabulary is used Semantically verifiable (due to formal grammar and predefined terms) Difference between controlled language and requirements patterns A controlled language in addition to restricting the syntax also precisely defines the semantics of the resulting requirement. Avoiding Ambiguity Controlled Languages What is a controlled language? Two major components: A grammar that imposes precisely defined constraints on the natural language A set of terms (including the term s semantics) to be used within the grammar Can be used to address all aspects of ambiguity Advantages of controlled languages Resulting requirements are easy to understand, since they are still in natural language Less proneness to ambiguity since a simplified grammar and a precisely defined vocabulary is used Semantically verifiable (due to formal grammar and predefined terms) Potential research topic for future collaboration! Difference between controlled language and requirements patterns A controlled language in addition to restricting the syntax also precisely defines the semantics of the resulting requirement. 13
14 Structuring NL Requirements Many recommendations exist Advantages of reference structures Proven structure defined based on experience of experts Reference for completeness Focusing on the content, not the structure Same information at the same place Tool support IEEE Std a popular reference structure for Requirements Documents Part 1: Introduction Purpose, Scope, Definitions, acronyms and abbreviations, References, Overview Part 2: Overall description Product perspective, product functions, user characteristics, constraints, assumptions and dependencies Part 3: Specific requirements External interfaces, functional requirements, performance requirements, logical database requirements, design constraints, software system attributes, other requirements Organization of part 3 depends on type of system, recommendations exist Standard Structure for a Software Requirements Specification According to [IEEE Std ] 14
15 Possible Contents of Part 3 of an SRS According to [IEEE Std ] Organization of Part 3 of the SRS By mode (left- hand side) By user class (right-hand side) 15
16 References Klaus Pohl, Requirements Engineering: Fundamentals, Principles, and Techniques, 2010, Springer Klaus Pohl and Chris Rupp, Requirements Engineering Fundamentals, 2011, Rocky Nook Chris Rupp and Sophist Group, Requirements Engineering und Management, 5 th edition, Hanser, München 16
Natural Language Specification
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Dr. Jörg Dörr Natural Language Specification Most Requirements are Described in Natural Language Free Text (Prose) In Word In Excel (Tabular) In RM-Tools In Sys-ML
More informationRefinement and Formalization of Semi-Formal Use Case Descriptions
Refinement and Formalization of Semi-Formal Use Case Descriptions Matthias Riebisch, Michael Hübner Ilmenau Technical University Max-Planck-Ring 14; 98684 Ilmenau; Germany {matthias.riebisch michael.huebner}@tu-ilmenau.de
More informationRecommended Practice for Software Requirements Specifications (IEEE)
Recommended Practice for Software Requirements Specifications (IEEE) Author: John Doe Revision: 29/Dec/11 Abstract: The content and qualities of a good software requirements specification (SRS) are described
More informationSoftware design descriptions standard
Tuffley Computer Services Pty Ltd Quality Management System Software design descriptions standard Version: 2.0 Date: 09/05/11 Status: Approved Copy no.: Controlled Approved by: Approver s name: Approver
More informationInformation technology - Metadata registries (MDR) - Part 5: Naming principles
1 2 3 ISO/IEC JTC1 SC32 N Date: 2013-12-18 ISO/IEC DIS 11179-5 4 5 ISO/IEC JTC1/SC32/WG2 6 7 Secretariat: ANSI 8 9 10 11 Information technology - Metadata registries (MDR) - Part 5: Naming principles Technologies
More informationSofware Requirements Engineeing
Sofware Requirements Engineeing Three main tasks in RE: 1 Elicit find out what the customers really want. Identify stakeholders, their goals and viewpoints. 2 Document write it down (Requirements Specification).
More informationInformation Technology Metadata registries (MDR) Part 5: Naming and identification principles
ISO/IEC 2011 All rights reserved ISO/IEC JTC1 /SC 32 /WG2 N1580 Date: 2011-09-13 ISO/IEC WD 11179-5 ISO/IEC JTC1 /SC 32/WG 2 Secretariat: ANSI Information Technology Metadata registries (MDR) Part 5: Naming
More informationRestricted Use Case Modeling Approach
RUCM TAO YUE tao@simula.no Simula Research Laboratory Restricted Use Case Modeling Approach User Manual April 2010 Preface Use case modeling is commonly applied to document requirements. Restricted Use
More informationBusiness Rules in the Semantic Web, are there any or are they different?
Business Rules in the Semantic Web, are there any or are they different? Silvie Spreeuwenberg, Rik Gerrits LibRT, Silodam 364, 1013 AW Amsterdam, Netherlands {silvie@librt.com, Rik@LibRT.com} http://www.librt.com
More informationRequirements. Chapter Learning objectives of this chapter. 2.2 Definition and syntax
Chapter 2 Requirements A requirement is a textual description of system behaviour. A requirement describes in plain text, usually English, what a system is expected to do. This is a basic technique much
More informationIDEF3 Process Modeling
IDEF3 Process Modeling What is a Process Model? Simply pyp put, the Process Model is the way that work is divided in a value delivery system. James B. Swartz A representation of a process and its related
More informationLecture 8: Goals and Scenarios. Pohl K., Requirements Engineering: Fundamentals, Principles, and Techniques, Springer, 2010, 814p.
Lecture 8: Goals and Scenarios Pohl K., Requirements Engineering: Fundamentals, Principles, and Techniques, Springer, 2010, 814p. 2 Documenting Goals 3 Documenting Goals 1. Each goal must have a unique
More informationISO/IEC JTC 1/SC 32 N 0754
ISO/IEC JTC 1/SC 32 N 0754 Date: 2002-01-16 REPLACES: -- ISO/IEC JTC 1/SC 32 Data Management and Interchange Secretariat: United States of America (ANSI) Administered by Pacific Northwest National Laboratory
More informationHuman Error Taxonomy
Human Error Taxonomy The Human Error Taxonomy (HET) provides a structure for requirement errors made during the software development process. The HET can be employed during software inspection to help
More informationINFORMATION RETRIEVAL SYSTEM: CONCEPT AND SCOPE
15 : CONCEPT AND SCOPE 15.1 INTRODUCTION Information is communicated or received knowledge concerning a particular fact or circumstance. Retrieval refers to searching through stored information to find
More informationThe attached document is hereby submitted for a 3-month letter ballot to the NBs of ISO/IEC JTC 1/SC 32. The ballot starts
Committee Draft ISO/IEC CD2 11179-5 Date: 2013-01-15 Reference number: ISO/JTC 1/SC 32N2280 Supersedes document: 32N2192 THIS DOCUMENT IS STILL UNDER STUDY AND SUBJECT TO CHANGE. IT SHOULD NOT BE USED
More informationRequirement Analysis
Requirement Analysis Requirements Analysis & Specification Objective: determine what the system must do to solve the problem (without describing how) Done by Analyst (also called Requirements Analyst)
More informationRequirements Specifications & Standards
REQUIREMENTS ENGINEERING LECTURE 2014/2015 Dr. Jörg Dörr Requirements Specifications & Standards AGENDA Standards & Templates Natural Language Requirements Specification with Conceptual Models Suitable
More information2 Ambiguity in Analyses of Idiomatic Phrases
Representing and Accessing [Textual] Digital Information (COMS/INFO 630), Spring 2006 Lecture 22: TAG Adjunction Trees and Feature Based TAGs 4/20/06 Lecturer: Lillian Lee Scribes: Nicolas Hamatake (nh39),
More informationDefense Logistics Agency INSTRUCTION
Defense Logistics Agency INSTRUCTION Subject: Plain Language Program References: DLAI 5025.13 Effective September 10, 2015 Accountable Office: Headquarters Complex Strategic Plans and Policy, Policy Management
More informationRequirements engineering
engineering Chapter 4 1 Engineering in the textbook 4.1 Functional and non-functional 4.2 The software document 4.4 engineering processes 4.5 elicitation and analysis 4.3 specification 4.6 validation 4.7
More informationChris Rupp. Requirements Templates The Blueprint of your Requirement STANDARD REQUIREMENTS. Templates For A Optimal Solution
Webinhalte zu Kapitel 10 Chris Rupp Requirements Templates The Blueprint of your Requirement STANDARD REQUIREMENTS The fully automated creation of a requirements document seems to remain a dream in the
More information- What we actually mean by documents (the FRBR hierarchy) - What are the components of documents
Purpose of these slides Introduction to XML for parliamentary documents (and all other kinds of documents, actually) Prof. Fabio Vitali University of Bologna Part 1 Introduce the principal aspects of electronic
More informationInteraction Style Categories. COSC 3461 User Interfaces. What is a Command-line Interface? Command-line Interfaces
COSC User Interfaces Module 2 Interaction Styles What is a Command-line Interface? An interface where the user types commands in direct response to a prompt Examples Operating systems MS-DOS Unix Applications
More informationInterface Type and Screen Design. Interface Type Design Menu Fill-in Form Natural Language Command Language Window & Icon Screen Design
Interface Type and Screen Design Interface Type Design Menu Fill-in Form Natural Language Command Language Window & Icon Screen Design H. C. So Page 1 Semester B 2017-2018 Menu List of options from which
More informationAMENDMENTS TO THE GUIDELINES FOR DRAFTING CLASSIFICATION DEFINITIONS
ANNEX VI AMENDMENTS TO THE GUIDELINES FOR DRAFTING CLASSIFICATION DEFINITIONS GENERAL RECOMMENDATIONS Users are expecting to find in definitions additional explanation and guidance that are not available
More informationDefinition and Instantiation of a Reference Model for Problem Specifications
Definition and Instantiation of a Reference Model for Problem Specifications Martin Kronenburg Christian Peper University of Kaiserslautern, Erwin Schrödinger Straße, D-67663 Kaiserslautern, Germany E-mail:
More informationRich Hilliard 20 February 2011
Metamodels in 42010 Executive summary: The purpose of this note is to investigate the use of metamodels in IEEE 1471 ISO/IEC 42010. In the present draft, metamodels serve two roles: (1) to describe the
More informationAssessing the Quality of Natural Language Text
Assessing the Quality of Natural Language Text DC Research Ulm (RIC/AM) daniel.sonntag@dfki.de GI 2004 Agenda Introduction and Background to Text Quality Text Quality Dimensions Intrinsic Text Quality,
More informationSummary of Contents LIST OF FIGURES LIST OF TABLES
Summary of Contents LIST OF FIGURES LIST OF TABLES PREFACE xvii xix xxi PART 1 BACKGROUND Chapter 1. Introduction 3 Chapter 2. Standards-Makers 21 Chapter 3. Principles of the S2ESC Collection 45 Chapter
More informationDocumentation and Naming
Authors: Michael Seubert Thilo Krähmer Semantics 3 Definition 2 Abstraction 4 Term Building Scoping & Understanding 1 Topic enterprise SOA Object & Service Operation Design Part V of VI Documentation and
More informationDelimited. Interfaced. Readable. Modifiable. Verifiable. Prioritized* Endorsed
15 quality goals for requirements Justified Correct Complete Consistent Unambiguous Feasible Abstract Traceable Delimited Interfaced Readable Modifiable Verifiable Prioritized* Endorsed Marked attributes
More informationOn the Relation Between "Semantically Tractable" Queries and AURA s Question Formulation Facility
On the Relation Between "Semantically Tractable" Queries and AURA s Question Formulation Facility 1. Introduction Working Note 34 Peter Clark, peter.e.clark@boeing.com, Sept 2009 In 2003, Popescu, Etzioni
More informationchallenges in domain-specific modeling raphaël mannadiar august 27, 2009
challenges in domain-specific modeling raphaël mannadiar august 27, 2009 raphaël mannadiar challenges in domain-specific modeling 1/59 outline 1 introduction 2 approaches 3 debugging and simulation 4 differencing
More informationLecture 8 Requirements Engineering
Lecture 8 Requirements Engineering Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 18, 2008 Lecture Overview
More informationProblem Analysis for Referential Requirements Specifications João Guilherme de Almeida Henriques Goucha Gaspar 1 Introduction
Problem Analysis for Referential Requirements Specifications João Guilherme de Almeida Henriques Goucha Gaspar 1 Introduction As the knowledge and practices on specific views of information systems stabilize
More informationSysML Activity Diagram Some Basic Semantics
SysML Activity Diagram Some Basic Semantics theodore.kahn@engility.com 1. Does this diagram follow all SysML rules, is it semantically correct? 2. If it is correct, is it good SysML, is the modeler s intent
More informationModeling Requirements
Modeling Requirements Critical Embedded Systems Dr. Balázs Polgár Prepared by Budapest University of Technology and Economics Faculty of Electrical Engineering and Informatics Dept. of Measurement and
More informationETSI ETR 346 TECHNICAL December 1996 REPORT
ETSI ETR 346 TECHNICAL December 1996 REPORT Source: ETSI TC-RES Reference: DTR/RES-06013-1 ICS: 33.020 Key words: Testing, TTCN, abstract test suite, validation Radio Equipment and Systems (RES); Trans-European
More informationTechnical Writing Process An Overview
techitive press Technical Writing Process An Overview Tenneti C S techitive press Copyrights Author: Chakravarthy Srinivas Tenneti Book: Technical Writing Process: An Overview Techitive.com 2013 All rights
More information[Product] MTM Program Product Software Requirements Specification
[Product] Software Requirements Specification [Version Number] [Version Date] [Product] MTM Program Product Software Requirements Specification [SRS Version Number] [SRS Version Date] [Applying MTM SRS
More informationRELATIONSHIP BETWEEN THE ISO SERIES OF STANDARDS AND OTHER PRODUCTS OF ISO/TC 46/SC 11: 1. Records processes and controls 2012
RELATIONSHIP BETWEEN THE ISO 30300 SERIES OF STANDARDS AND OTHER PRODUCTS OF ISO/TC 46/SC 11: Records processes and controls White paper written by ISO TC46/SC11- Archives/records management Date: March
More informationChapter 3: Describing Syntax and Semantics. Introduction Formal methods of describing syntax (BNF)
Chapter 3: Describing Syntax and Semantics Introduction Formal methods of describing syntax (BNF) We can analyze syntax of a computer program on two levels: 1. Lexical level 2. Syntactic level Lexical
More informationOntology-based Architecture Documentation Approach
4 Ontology-based Architecture Documentation Approach In this chapter we investigate how an ontology can be used for retrieving AK from SA documentation (RQ2). We first give background information on the
More informationTEXT PREPROCESSING FOR TEXT MINING USING SIDE INFORMATION
TEXT PREPROCESSING FOR TEXT MINING USING SIDE INFORMATION Ms. Nikita P.Katariya 1, Prof. M. S. Chaudhari 2 1 Dept. of Computer Science & Engg, P.B.C.E., Nagpur, India, nikitakatariya@yahoo.com 2 Dept.
More informationLecture 9 Requirements Engineering II
Lecture 9 Requirements Engineering II Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 23, 2008 Announcements
More informationPropositional Logic. Part I
Part I Propositional Logic 1 Classical Logic and the Material Conditional 1.1 Introduction 1.1.1 The first purpose of this chapter is to review classical propositional logic, including semantic tableaux.
More informationModeling Crisis Management System With the Restricted Use Case Modeling Approach
Modeling Crisis Management System With the Restricted Use Case Modeling Approach Gong Zhang 1, Tao Yue 2, and Shaukat Ali 3 1 School of Computer Science and Engineering, Beihang University, Beijing, China
More informationAuthors: Andrei Kapustin, Vadim Chirikov, Marina Farr Cybernetic Intelligence GmbH, Zug, Switzerland Requirement analysis: Methodology
Authors: Andrei Kapustin, Vadim Chirikov, Marina Farr Cybernetic Intelligence GmbH, Zug, Switzerland Requirement analysis: Methodology P-RAM-2002-10-1-0 September 10, 2002 Contents CONTENTS...2 1 OVERVIEW...4
More informationSoftware Engineering - I
Software Engineering - I An Introduction to Software Construction Techniques for Industrial Strength Software Chapter 3 Requirement Engineering Copy Rights Virtual University of Pakistan 1 Requirement
More informationIntegrating SysML and OWL
Integrating SysML and OWL Henson Graves Lockheed Martin Aeronautics Company Fort Worth Texas, USA henson.graves@lmco.com Abstract. To use OWL2 for modeling a system design one must be able to construct
More informationSoftware Requirements Specification (SRS) Software Requirements Specification for <Name of Project>
Software Requirements Specification (SRS) Software Requirements Specification for Version Release Responsible Party Major Changes Date 0.1 Initial Document Release for
More informationGetting Started With Syntax October 15, 2015
Getting Started With Syntax October 15, 2015 Introduction The Accordance Syntax feature allows both viewing and searching of certain original language texts that have both morphological tagging along with
More informationRequirements Validation and Negotiation
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Joerg Doerr Requirements Validation and Negotiation AGENDA Fundamentals of Requirements Validation Fundamentals of Requirements Negotiation Quality Aspects of
More informationReadyGEN Grade 2, 2016
A Correlation of ReadyGEN Grade 2, 2016 To the Introduction This document demonstrates how meets the College and Career Ready. Correlation page references are to the Unit Module Teacher s Guides and are
More informationAADL Requirements Annex Review
Dominique Blouin Lab-STICC Université de Bretagne-Occidentale Université de Bretagne-Sud Bretagne, France 1 AADL Standards Meeting, April 23 th, 2013 Agenda Comments from Annex Document Review Motivations
More informationISO/IEC INTERNATIONAL STANDARD. Information technology Metadata registries (MDR) Part 1: Framework
INTERNATIONAL STANDARD ISO/IEC 11179-1 Second edition 2004-09-15 Information technology Metadata registries (MDR) Part 1: Framework Technologies de l'information Registres de métadonnées (RM) Partie 1:
More informationSOFTWARE ENGINEERING UML FUNDAMENTALS. Saulius Ragaišis.
SOFTWARE ENGINEERING UML FUNDAMENTALS Saulius Ragaišis saulius.ragaisis@mif.vu.lt Information source Slides are prepared on the basis of Bernd Oestereich, Developing Software with UML: Object- Oriented
More informationThe Dublin Core Metadata Element Set
ISSN: 1041-5635 The Dublin Core Metadata Element Set Abstract: Defines fifteen metadata elements for resource description in a crossdisciplinary information environment. A proposed American National Standard
More informationDLV02.01 Business processes. Study on functional, technical and semantic interoperability requirements for the Single Digital Gateway implementation
Study on functional, technical and semantic interoperability requirements for the Single Digital Gateway implementation 18/06/2018 Table of Contents 1. INTRODUCTION... 7 2. METHODOLOGY... 8 2.1. DOCUMENT
More informationBenefits and Challenges of Architecture Frameworks
Benefits and Challenges of Architecture Frameworks Daniel Ota Michael Gerz {daniel.ota michael.gerz}@fkie.fraunhofer.de Fraunhofer Institute for Communication, Information Processing and Ergonomics FKIE
More informationCh 4: Requirements Engineering. What are requirements?
Ch 4: Engineering What are? Functional and non-functional The software document specification engineering processes elicitation and analysis validation management The descriptions of what the system should
More informationHuman Computer Interaction Lecture 16. User Support
Human Computer Interaction Lecture 16 User Support User Support Main Types of user support quick reference, task specific help, full explanation, tutorial Issues different types of support at different
More informationVocabulary-Driven Enterprise Architecture Development Guidelines for DoDAF AV-2: Design and Development of the Integrated Dictionary
Vocabulary-Driven Enterprise Architecture Development Guidelines for DoDAF AV-2: Design and Development of the Integrated Dictionary December 17, 2009 Version History Version Publication Date Author Description
More informationAbout the Tutorial. Audience. Prerequisites. Copyright & Disclaimer. Compiler Design
i About the Tutorial A compiler translates the codes written in one language to some other language without changing the meaning of the program. It is also expected that a compiler should make the target
More informationStandards Authorization Request Form
Standards Authorization Request Form When completed, email this form to: sarcomm@nerc.com NERC welcomes suggestions to improve the reliability of the bulk power system through improved reliability standards.
More informationSoftware Requirements Specification. <Project> for. Version 1.0 approved. Prepared by <author(s)> <Organization> <Date created>
Software Requirements Specification for Version 1.0 approved Prepared by Software Requirements Specification for Page 2 Table of Contents Revision
More informationLecture 5: Requirements Specifications
Lecture 5: Requirements Specifications Why we need to write specifications Purpose and audience Choosing an appropriate size and formality Desiderata for Specifications Properties of good specifications
More informationAuthoring and Maintaining of Educational Applications on the Web
Authoring and Maintaining of Educational Applications on the Web Denis Helic Institute for Information Processing and Computer Supported New Media ( IICM ), Graz University of Technology Graz, Austria
More informationFundamentals to Creating Architectures using ISO/IEC/IEEE Standards
Fundamentals to Creating Architectures using ISO/IEC/IEEE Standards What to Architect? How to Architect? IEEE Goals and Objectives Chartered by IEEE Software Engineering Standards Committee to: Define
More informationBusiness Requirements Specification for the. Nomination and Matching Procedures. In Gas Transmission Systems (NOM BRS)
27 May 2015 Rev14 1 2 3 4 for the In Gas Transmission Systems (NOM BRS) 5 6 Version 0 Revision 14 2015-05-27 7 8 ENTSOG AISBL; Av. de Cortenbergh 100, 1000-Brussels; Tel: +32 2 894 5100; Fax: +32 2 894
More informationCOSE312: Compilers. Lecture 1 Overview of Compilers
COSE312: Compilers Lecture 1 Overview of Compilers Hakjoo Oh 2017 Spring Hakjoo Oh COSE312 2017 Spring, Lecture 1 March 7, 2017 1 / 15 What is Compiler? Software systems that translate a program written
More informationThe DPM metamodel detail
The DPM metamodel detail The EBA process for developing the DPM is supported by interacting tools that are used by policy experts to manage the database data dictionary. The DPM database is designed as
More informationMathematics and Computing: Level 2 M253 Team working in distributed environments
Mathematics and Computing: Level 2 M253 Team working in distributed environments SR M253 Resource Sheet Specifying requirements 1 Overview Having spent some time identifying the context and scope of our
More informationRE Process. Lawrence Chung Department of Computer Science The University of Texas at Dallas
1 RE Process Lawrence Chung Department of Computer Science The University of Texas at Dallas 2 RE Process: What is a Process? Given input, transforms it into output Consist of a set of activities Process
More informationUser Interface Design. Interface Design 4. User Interface Design. User Interface Design. User Interface Design. User Interface Design
Specification of a conversation between the user and the computer. Generally results in either input, output or both. An important part of systems and software development. An intuitive and easy to use
More informationMega International Commercial bank (Canada)
Mega International Commercial bank (Canada) Policy and Procedures for Clear Language and Presentation Est. Sep. 12, 2013 I. Purposes: The Mega ICB (C) distributes a limited range of retail banking services,
More informationLecture 1/2. Copyright 2007 STI - INNSBRUCK
Introduction to modeling MSc 2008/2009 009 Lecture 1/2 1 Copyright 2007 STI - INNSBRUCK www.sti-innsbruck.at Course overview Introduces modeling as a discipline within Computer Science and Engineering,
More informationUsing Composition Trees to Model and Compare Software Process
Using Composition Trees to Model and Compare Software Process Lian Wen 1, David Tuffley 1, Terry Rout 1, 1 Software Quality Institute, Griffith University, Brisbane, Queensland, Australia {l.wen, d.tuffley,
More informationBEST PRACTICES FOR SOFTWARE LOCALIZATION
THE DEVELOPER S DOZEN: 12 BEST PRACTICES FOR SOFTWARE LOCALIZATION The global software market is valued at almost half a trillion dollars and growing across all sectors, from sophisticated ERP systems
More informationElements of Requirements Style
Elements of Requirements Style Sponsored by: Karl Wiegers Principal Consultant, Process Impact www.processimpact.com Sponsor: Seilevel Published in 2012: Visual Models for Software Requirements Karl and
More informationSoftware Requirements Specification. <Project> for. Version 1.0 approved. Prepared by <author> <organization> <date created>
Software Requirements Specification for Version 1.0 approved Prepared by Copyright 2002 by Karl E. Wiegers. Permission is granted to use, modify, and distribute
More informationThis document is a preview generated by EVS
INTERNATIONAL STANDARD IEC 62559-3 Edition 1.0 2017-12 colour inside Use case methodology Part 3: Definition of use case template artefacts into an XML serialized format IEC 62559-3:2017-12(en) THIS PUBLICATION
More informationProduct. e ss. P roc. so get the right requirements. Garbage in garbage out,
If software is simply for automation, what would a washing machine be like? 1 RE Process Lawrence Chung Department of Computer Science The University of Texas at Dallas 2 RE Process: What is a Process?
More informationMETADATA REGISTRY, ISO/IEC 11179
LLNL-JRNL-400269 METADATA REGISTRY, ISO/IEC 11179 R. K. Pon, D. J. Buttler January 7, 2008 Encyclopedia of Database Systems Disclaimer This document was prepared as an account of work sponsored by an agency
More informationISO/IEC TR TECHNICAL REPORT. Software and systems engineering Life cycle management Guidelines for process description
TECHNICAL REPORT ISO/IEC TR 24774 First edition 2007-09-01 Software and systems engineering Life cycle management Guidelines for process description Ingénierie du logiciel et des systèmes Gestion du cycle
More informationRequirements Validation and Negotiation
REQUIREMENTS ENGINEERING LECTURE 2015/2016 Eddy Groen Requirements Validation and Negotiation AGENDA Fundamentals of Requirements Validation Fundamentals of Requirements Negotiation Quality Aspects of
More informationISO/IEC JTC 1 N Replaces: ISO/IEC JTC 1 Information Technology
ISO/IEC JTC 1 N7859 2005-07-22 Replaces: ISO/IEC JTC 1 Information Technology Document Type: Document Title: other (defined) Document Source: National Body of Canada Project Number: Document Status: This
More informationRequirements Engineering
Requirements Engineering An introduction to requirements engineering Gerald Kotonya and Ian Sommerville G. Kotonya and I. Sommerville 1998 Slide 1 Objectives To introduce the notion of system requirements
More informationHL7 V3 User Model. The V3 Editing Team. April 9, Ockham Information Services LLC
HL7 V3 User Model The V3 Editing Team April 9, 2007 Ockham Information Services LLC Contents Profile orientation Profile drafts Use case drafts Document map prototypes The need for profiles Documents require
More informationA Survey Of Different Text Mining Techniques Varsha C. Pande 1 and Dr. A.S. Khandelwal 2
A Survey Of Different Text Mining Techniques Varsha C. Pande 1 and Dr. A.S. Khandelwal 2 1 Department of Electronics & Comp. Sc, RTMNU, Nagpur, India 2 Department of Computer Science, Hislop College, Nagpur,
More informationModeling Requirements, Architectures, Behaviour...
Modeling Requirements, Architectures, Behaviour... The System Modeling Language (SysML) and the SYSMOD modeling approach Budapest University of Technology and Economics Department of Measurement and Information
More informationSyntax Analysis. Chapter 4
Syntax Analysis Chapter 4 Check (Important) http://www.engineersgarage.com/contributio n/difference-between-compiler-andinterpreter Introduction covers the major parsing methods that are typically used
More informationA Novel Software Tool for Supporting and Automating the Requirements Engineering Process With the Use of Natural Language
International Journal of Computer Theory and Engineering, Vol. 5, No. 3, June 2013 A Novel Software Tool for Supporting and Automating the Requirements Engineering Process With the Use of Natural Language
More information2 Which Methodology for Building Ontologies? 2.1 A Work Still in Progress Many approaches (for a complete survey, the reader can refer to the OntoWeb
Semantic Commitment for Designing Ontologies: A Proposal Bruno Bachimont 1,Antoine Isaac 1;2, Raphaël Troncy 1;3 1 Institut National de l'audiovisuel, Direction de la Recherche 4, Av. de l'europe - 94366
More informationThe software lifecycle and its documents
The software lifecycle and its documents Supplementary material for Software Architecture course B. Meyer, May 2006 Lifecycle models Origin: Royce, 1970, Waterfall model Scope: describe the set of processes
More informationAll the subjective part of 2011 papers solved complete reference numbers
1 All current papers 2011 Solved papers (eagle_eye) CS504 Current data final term paper 15 FEB All the subjective part of 2011 papers solved complete reference numbers 1) Describe the the concept of cyclomatic
More informationArchiMate 2.0. Structural Concepts Behavioral Concepts Informational Concepts. Business. Application. Technology
ArchiMate Core Structural Concepts Behavioral Concepts Informational Concepts interaction Technology Application Layer Concept Description Notation Concept Description Notation Actor An organizational
More informationInterPARES 2 Project
International Research on Permanent Authentic Records in Electronic Systems Integrated Definition Function Modeling (IDEFØ): A Primer InterPARES Project Coordinator 04 August 2007 1 of 13 Integrated Definition
More informationTaxonomies and controlled vocabularies best practices for metadata
Original Article Taxonomies and controlled vocabularies best practices for metadata Heather Hedden is the taxonomy manager at First Wind Energy LLC. Previously, she was a taxonomy consultant with Earley
More information