V. Ambriola V. Gervasi Dipartimento di Informatica University of - PowerPoint PPT Presentation

V. Ambriola V. Gervasi Dipartimento di Informatica University of Pisa - Italy Vincenzo Ambriola: ambriola@di.unipi.it Vincenzo Gervasi: gervasi@di.unipi.it Web site: http://circe.di.unipi.it

� Mapping the Requirements Country � A general overview of CIRCE � Natural language in CIRCE � A few software models � Integrating Lyee TM and CIRCE � Conclusions

Mapping the Requirements Country � Mapping the Requirements Country � � A general overview of CIRCE � Natural language in CIRCE � A few software models � Integrating Lyee TM and CIRCE � Conclusions

� “ Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems . It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families” P. Zave, 1997

� Technical world: � Functions � Constraints � Precise specifications � Human world: � Cognitive psychology � Anthropology � Sociology � Linguistics

� RE, a discipline of description � What is the best way to describe… � the system’s goals, constraints, etc. � to different people (user, developers…) and tools (design checkers, verification tools…) � Time to go Greek! � Epistemology (what do the stakeholders believe?) � Phenomenology (what can I observe in the world?) � Ontology (what has objective existence?)

� Requirements elicitation � Who has the information I need? � How can I obtain that information? � Requirements modeling and analysis � How can I represent the information I got? � What analysis can I perform on the information? � Requirements communication � What is the best way to communicate that information to different people, for different purposes? � Requirements agreement � Do we agree on those requirements? � If not, how can we reach an agreement? � Requirements evolution � The world is changing: how can I adapt the requirements? � My needs are changing: how can I adapt the requirements?

� Building formal models of relevant entities: � Organization/Business/Enterprise models � Information/Data models � Behavior/Procedure models � Domain models � Constraints models � Performance (non-functional) models

(cont’d) � Formal models can be analyzed � To measure attributes and predict features of the final system � To check the consistency of the models � Many conceptual and technological tools, e.g.: � Requirements animation � Model checking

� Requirements “travel” back and forth among many parties � Each party may prefer a certain language (due to different skills and goals) � Requirements must be managed and traced across all those translations � Requirements must be identifiable in different formalisms

� Mapping the Requirements Country A general overview of CIRCE � A general overview of CIRCE � � Natural language in CIRCE � A few software models � Integrating Lyee TM and CIRCE � Conclusions

IRCE � Analyze natural language* requirements � Build formal models of � a requirements document � the system described by the requirements � the requirements development process � Present those models ( visualization ) � Check them ( validation ) � Measure their attributes ( metrication ) * English and Italian currently implemented

IRCE

(domain-based) � “Ten seconds after the system has received a Launch Confirmation Command from Main actatpit Control, it shall set the main engine on, until the untilact tspanafterevt current altitude reaches the cruise altitude.” gt tspan set receives 10 secs system ON Main system Main engine control Current Cruise LCC altitude altitude

Functional: a data flow carrying LCC exists from Main � Control to our system a data flow carrying “ON” commands exists from � our system to the main engine Validation: “current altitude” and “cruise altitude” � must be either built-ins or received from some source Metrics: this requirement specifies operations that � imply a certain complexity for our system � “Ten seconds after the system has received a Launch Confirmation Command from Main Control, it shall set the main engine ON until current altitude reaches cruise altitude.”

Main control GPS Altimeter LCC position altitude Cruise altitude time old pos. > target pos. heading ON Cruise control command Maneuver Engine Main Engine

Altimeter GPS Main Engine Main control Missile Control System Maneuver Engine MCS Diagnostics

Behaviour: A complex temporal ordering of events is � described Validation: events for which the system � waits should eventually happen Metrics: this requirement specifies � operations that imply a certain complexity for our system � “Ten seconds after the system has received a Launch Confirmation Command from Main Control, it shall set the main engine ON until current altitude reaches cruise altitude.”

LCC received from Main control Idle Waiting 10 seconds elapsed Engine off Engine on Current altitude reaches cruise altitude

� CIRCE can observe process events � Document and system attributes can be traced during the evolution of the requirements � Collection of process profiles � Process guidance as outcome of validation

A “good” process: functional and behavioural complexity grows with time, validation violation are kept under control.

An instable process: functional and behavioural complexity oscillate, validation violation are addressed only at the end of the process

IRCE

� Mapping the Requirements Country � A general overview of CIRCE Natural language in CIRCE � Natural language in CIRCE � � A few software models � Integrating Lyee TM and CIRCE � Conclusions

� Universal : can express any model or property � Shared : stakeholders from different backgrounds can communicate using NL � Ease of experimentation : “early” requirements as matter for thought � Good as a process unit : sentences are the right “atoms” for analyzing RE processes

(cont’d) � Arbitrary abstraction level : requirements can be vague or precise without having to change language � Most used in common industrial practice (despite the remarkable progresses of formal methods)

� Designations � Identify entities in the domain � Assign a name and establish synonyms � Definitions � Explain how a certain language should be interpreted � Requirements � Use designation, definitions, and basic language to express relationships among entities in the domain

� Participant , is a user of the system participating to a meeting. Also “user”. Designations � Terminal , is a device for wireless communication. Also “mobile phone”. Definitions � “ Alert someone” means “send an SMS to his/her terminal”. Requirements � Every user has a mobile phone. � Two hours before a scheduled + meeting, the system shall alert the domain description participants to the meeting. statements

Requirements Definitions User language Designations Basic language Real world

� Use domain-specific knowledge in parsing natural language sentences � Replaces or supplements “traditional” grammar � Terms are tagged with their domain- specific properties (semantic classes) � POS-tagging may also be used

� Rule-based rewriting system � Rule matching can be imperfect (allows information extraction applications): � Missing terms � Order inversions � Extra terms � Backtracking and scoring system to select “best” parse tree � Language-independent (but tested only on western languages)

IRCE � Participant/ HUMAN : user. Designations � Terminal/ IN / OUT : mobile phone. � ALERT x / HUMAN -> Definitions send an SMS to $x ’s terminal. � Every user has a mobile Requirements phone . + � Two hours before the domain description time scheduled for a meeting, the system statements shall alert all the participants to the meeting.

d. If the ACS N1S2 Cabin Pressure FDIR State is equal to ENABLED, then upon receipt of ACS N1S2 Cabin Pressure HW Data less than the Node 1 Cabin Pressure Lower Limit (initial: 13.9 psia) for 3 consecutive acquisitions, the NCS shall within 1.1 seconds: 1) Set the ACS N1S2 Cabin Pressure Lower Limit Warning State (initial value: FALSE) to TRUE, and 2) Issue a warning level alarm (message: “Node 1 Cabin Pressure Lower Limit Warning Violation”) in accordance with the section on “annunciate alarms”. (NASA requirements for the ISS)

DEPC RELOP DEPT CP FDIR state ENABLED equals EVTFORSPAN DOOP NCS CONDRECEIPT TSPAN WITHIN Less 3 sampling CP Lower CP HW data than Limit TSPAN CONJ 1.1 secs DEFAULTVAL DEFAULTVAL SET STANDARDEF CP Lower Limit TRUE CP Lower Limit FALSE Warning state CP Lower UNITVAL Warning state Limit 13.9 psia ISSUEMSG SECTION Warning level “Node 1 Cabin “Annunciate Pressure Lower alarm alarms” Limit Warning violation”