Measure Software Requirement Specifications by Ontology Reasoning

1. Measure Software Requirement Specifications by Ontology Reasoning Katja Siegemund1, Uwe Aßmann1, Jeff Pan2, Yuting Zhao2 1 Technische Universität Dresden, Germany 2 University of Aberdeen, UK

2. Outline Motivation Reasoning for Requirements Engineering ONTOREQ Architecture Requirements Ontology Identification of Quality Flaws in SRS Measuring Quality of SRS General Guidelines for Improving Knowledge in Ontologies Evaluation Outlook Measure SRS by Ontology Reasoning

3. Motivation • Requirements Engineering (RE): • „refers to the process of eliciting, evaluating, specifying, consolidating, and changing the objectives, functionalities, qualities and constraints to be achieved by a software-intensive system” [1] • SRS must be consistent, unambiguous, verifiable, and complete [2,3] • SRS often inconsistent, incomplete and thus, incorrect and of low quality • Davis proposes 24 criteria to ensure the quality of SRS, e.g.: • completeness, correctness, verifiability, internal consistency, conciseness and traceability [4] Measure SRS by Ontology Reasoning

4. Reasoning for RE Requirements Ontology with huge set of requirement metadata and requirement relationships (Tbox) Instantiation with concrete requirement information (ABox) Support for Goal-oriented RE (GORE) Foundation for completeness, consistency and quality checks Measure SRS by Ontology Reasoning

5. Architecture ONTOREQ RE backgroundknowledge Requirements Ontology RE Metamodel Abox TBox Req. Spec. of a project CompletenessChecking Rules CompletenessQueries ConsistencyQueries ConsistencyChecking Rules Quality Checking Rules Quality Queries Measure SRS by Ontology Reasoning

6. Reasoning for RE – Tbox Measure SRS by Ontology Reasoning

7. Identification of Quality Flaws in SRS (1/2) • Quality Rules • state essential requirement information • Provide specific suggestions for every rule violation detected • consist of a rule description, fault message and solution suggestion • Executed after completeness and consistency check • Allow detection of quality flaws • Provide means to correct quality problems Measure SRS by Ontology Reasoning

8. Example: Detecting Quality Flaws isNegativeContributionTo Goal1 FR1 isAlternativeTo FR2 • Req. Knowledge: • There must be no requirement that is a negative contribution to a goal to be achieved. “The following requirements are a negative contribution on a goal: FR1 on Goal1 Please choose one of the following options: • Exclude the following optional requirement from the requirement configuration: FR1 • Choose one of the alternative requirements instead of FR1: [FR2] • Revise the goal satisfaction relationship. Measure SRS by Ontology Reasoning

9. Identification of Quality Flaws in SRS (2/2) RxisNegativeContributiontoGoalx RxisMandatory ? AnyRiisAlternativeToRx ? NO YES RxisCoexistentWithanyRi ? RiisNegativeContributionToGoal x ? NO NO ExcludeRx UseRias alternative Revisegoalcontribution Specific suggestions require consideration of various requirement relationships Measure SRS by Ontology Reasoning

10. Identification of Quality Flaws Realisation • Various relationships between requirements knowledge • Identification of missing information requires CWA • RE knowledge is never complete, thus requires OWA • We need to switch between OWA and CWA • Local closed world (nbox) reasoning (e.g. TrOWL) [5], [6] • SPARQL 1.1 Measure SRS by Ontology Reasoning

11. Measure SRS for Quality • Set of 6 quality metrics based on [4] : • Internal completeness, correctness, verifiability, traceability (of SRS) • internal consistency, uncriticaility (of requirement configuration) • Described by definition, function and weight • Example: [Verifiable SRS] • “A requirement specification is verifiable if a test-case and/or metric is specified for each requirement.” • calculate the percentage of verifiable requirements: Q3 = rv / rn W3=0.7 Measure SRS by Ontology Reasoning

12. General Guidelines for Improving Knowledge in Ontologies Domain-specific ontology metamodel (Tbox) Meaningful relations between knowledge artefacts enable reasoning about alternative, optional, mandatory, coexistent, conflicting and excluding individuals Identify domain-specific quality attributes Define and implement quality rules Identify, define and implement quality measurements and weights Measure SRS by Ontology Reasoning

13. Evaluation SomeminorevaluationswithavailableUseCases Primary evaluationwith Case Studies within MOST Project Main evaluation with different user-groups planned Measure SRS by Ontology Reasoning

14. Conclusion All Requirement artefacts and meaningful relationships can be captured within an Ontology Metamodel Specification of requirements uses OWA, verification needs CWA ONTOREQ allows identification of incompleteness, inconsistency and quality flaws and quality measurement of SRS Further work planned: guidance for RE process Measure SRS by Ontology Reasoning

15. Thanks Measure SRS by Ontology Reasoning

16. References (1/2) [1] Axel van Lamsweerde. Reasoning about alternative requirements options. In Alexander Borgida, Vinay K. Chaudhri, Paolo Giorgini, and Eric S. K. Yu, editors, Conceptual Modeling: Foundations and Applications, volume 5600 of Lecture Notes in Computer Science, pages 380-397. Springer, 2009. [2] Donald Firesmith. Specifying Good Requirements. Journal of Object Technology, 2:77{87, 2003. [3] Ian Sommerville and Pete Sawyer. Requirements Engineering: A Good Practices Guide. John Wiley & Sons, 1997. [4] Alan M. Davis. Software Requirements: Analysis and Specication. Prentice Hall Press, Upper Saddle River, NJ, USA, 2nd edition edition, 1993. [5] TrOWL. http://trowl.eu/ Measure SRS by Ontology Reasoning

17. References (2/2) [6] Yuan Ren, Je Z. Pan, and Yuting Zhao. Closed World Reasoning for OWL2 with NBox. Journal of Tsinghua Science and Technology, 15(6), 2010. Measure SRS by Ontology Reasoning

18. Motivation • Deficienciesofcurrent RE Methodstobeaddressed: • Relationships among requirements are inadequately captured and are often limited to binary relations between requirements • Requirement problems (e.g. conflicts, unstated information) are detected too late or not all • Completeness and consistency are not verified • Models for RE need richer and higher-level abstractions [Mylopoulos1999] • Requirements knowledge (decisions, refinements, obstacles, etc.) not traceable • Causal relationship between consistency, completeness and correctness [Zowghi2002] Measure SRS by Ontology Reasoning

19. GORE • Lamsweerde defines goals as "declarative statements of intent to be achieved by the system under consideration" [Lamsweerde2000] • Benefits of GORE: • Goals provide a meaningful criterion for sufficient completeness of a requirement specification • Specification of pertinent requirements • relationships between goals and requirements can help to choose the best one • Concrete requirements may change over time whereas goals pertain stable • Goals drive the identification of requirements Measure SRS by Ontology Reasoning

20. Goal-Oriented RE (Motivation Example) <Goal> <Decision> <Risk> Win the game Early exhaustion Lehmann as goalkepper <Objective> <Objective> Goal … <Misuse-Case> <Obstacle> <Obstacle> <Scenario> <Use-Case> Red card for a player aggressiveFans 1st. Half time offensive play Nowotny backsSchweinsteiger Fouls <FR> <NFR> <NFR> <Metric> <Metric> Keeps 90% of the goals Good concentration Attack until 10th. minute Fast and good backing Early attack <Constraint> max. play time Measure SRS by Ontology Reasoning