Your SlideShare is downloading. ×
0
Analisi dei requisiti: due problemi importanti
Analisi dei requisiti: due problemi importanti
Analisi dei requisiti: due problemi importanti
Analisi dei requisiti: due problemi importanti
Analisi dei requisiti: due problemi importanti
Analisi dei requisiti: due problemi importanti
Analisi dei requisiti: due problemi importanti
Analisi dei requisiti: due problemi importanti
Analisi dei requisiti: due problemi importanti
Analisi dei requisiti: due problemi importanti
Analisi dei requisiti: due problemi importanti
Analisi dei requisiti: due problemi importanti
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Analisi dei requisiti: due problemi importanti

117

Published on

Aree in cui strumenti automatici possono aiutare nell'analisi dei requisiti: individuazione di ambiguità e identificazione di requisiti da testi legali

Aree in cui strumenti automatici possono aiutare nell'analisi dei requisiti: individuazione di ambiguità e identificazione di requisiti da testi legali

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
117
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Luisa Mich Nadzeya Kiyavitskaya
  • 2. 1. 2. Ambiguity identification in requirements specifications Identification of rights and obligations for regulation compliance Interdisciplinary workshop on requirements analysis Trento, December 15, 2008 2
  • 3. Natural language requirements specifications (NL RS) ◦ 79% of requirements documents are couched in unrestricted NL ◦ majority of developers (64%) think that a higher level of automation is needed to improve general efficiency in modeling requirements Interdisciplinary workshop on requirements analysis Trento, December 15, 2008 3
  • 4. Ambiguity ◦ Is an intrinsic phenomenon of natural language ◦ Means the capability of being understood in two or more possible senses or ways ◦ May cause: Implementation of incorrect set of system requirements Generation of the wrong test cases for system verification Interdisciplinary workshop on requirements analysis Trento, December 15, 2008 4
  • 5. Two step approach to identify ambiguities in NL RSs: 1. Tool T1 would apply a set of ambiguity measures to a NL RS in order to identify potentially ambiguous sentences in the RS 2. Tool T2 would show what specifically is potentially ambiguous about each sentence in the RS Final decision is made by a human that may want to rewrite the sentence Interdisciplinary workshop on requirements analysis Trento, December 15, 2008 5
  • 6. T1 ◦ The tool notifies of potentially ambiguous sentences by varying their background color ◦ lexical ambiguity at the sentence level approximates the semantic ambiguity of a sentence ◦ Uses free dictionaries to identify word lexical ambiguity Babylon, Wordnet, WordReference Interdisciplinary workshop on requirements analysis Trento, December 15, 2008 6
  • 7. T2 ◦ Not yet implemented ◦ Preliminary research studies allowed to derive a set of feasible requirements for T2 T2’s features will include drawing user’s attention to: ◦ ◦ ◦ ◦ Weak or vague words: similarly, clearly, appropriate Demonstrative pronouns used as a noun: This is… Undefined acronyms Verbs, subjects and verb complements joined by conjunction Etc. Interdisciplinary workshop on requirements analysis Trento, December 15, 2008 7
  • 8. Problem ◦ Law regulates some activities of organizations ◦ To verify if a system is compliant with a regulation, the requirements imposed by the regulatory document must be identified ◦ Requirements engineers don’t have expertise in law and need tool support Interdisciplinary workshop on requirements analysis Trento, December 15, 2008 8
  • 9. Solution ◦ Develop a systematic process for extracting requirements from regulations The semantic parameterization process proposed by Breaux and Antón ◦ Develop tool support for the process Implementation of the tool, called Gaius T., based on this process Interdisciplinary workshop on requirements analysis Trento, December 15, 2008 9
  • 10. Analysis of regulations with Gaius T. Interdisciplinary workshop on requirements analysis Trento, December 15, 2008 10
  • 11. Evaluation notes ◦ English and Italian data sets the HIPAA Privacy Act of U.S. the Italian Accessibility Law (Stanca act) ◦ The tool was able to largely support humans in identification of relevant information ◦ Unlike manual annotations, automatic markup is more consistent Interdisciplinary workshop on requirements analysis Trento, December 15, 2008 11
  • 12. N. Kiyavitskaya, N. Zeni, L. Mich, D. Berry (2008). Requirements for tools ambiguity identification and measurement in natural language requirements specification, REQUIREMENTS ENGINEERING, 13(3): 207-239. DOI: 10.1007/s00766-008-0063-7 N. Zeni, N. Kiyavitskaya, L. Mich, J.R. Cordy, J. Mylopoulos (2013). GaiusT: Supporting the GaiusT: Extraction of Rights and Obligations for Regulatory Compliance, REQUIREMENTS ENGINEERING, online first: ttp://dx.doi.org/10.1007/s00766-0130181-8 DOI: 10.1007/s00766-013-0181-8 Interdisciplinary workshop on requirements analysis Trento, December 15, 2008 12

×