Requirements Engineering From System Goals to UML Models

Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde 1

Requirements verification through formal checks – Similar to compilers: – Good for consistency and completeness – Good for input-output mapping – Can highlight non-deterministic behaviors – Provides good coverage 2

Language Checks u Syntax Checks u Type Checks u Static Semantic Checks u Circularity Checks, etc. 3

Dedicated consistency and completeness checks u Requires that relationships are functions u Requires that functions are total u Can be used to check for disjointness u Can be used to check for exhaustiveness (condition table example) 4

Model Checking u Checks that a property is satisfied. u Property can be a requirement, assumption or domain property. u Algorithmic proof, searching for counterexamples. u Reachability graph is recursively explored. Visited states are marked to avoid cycles. Stops when a bad state is reached. u [Example] 5

Model Checkers u Check 3 Properties: – Reachability (or unreachability) – Safety properties (check for undesirable state) – Liveness (a desirable condition must eventually hold) – Which type of search should one use? BFS or DFS? 6

7

8

Theorem Proving u Deductive rather than algorithmic u Generates new assertions from rules of inference u Can also prove false candidate theorems to show consequences of what is specified. u Pros: – Sound and complete – Can handle those that have state explosions w/ model checkers. – Failing Proofs can give insight into error causes. u Cons: – Experience needed, translation problem, no concrete counterexample for failures. 9

u A -> B u B->C u What can you deduct about A and C? 10

Example: PINES- Category: Financial Records u Req ID: PINES-031 Priority: 1 u Name: value of items report u Description: The system can generate a report of the value of items (based on data in item record) in the entire collection or a portion. Example: staff can obtain value of all items with status of long-overdue, or value of all DVDs in children's collection, or value of entire collection. u Source: RWG -------------------------------------------------------------------u All reports and data archiving must comply with standard accounting practice and state, county, and municipal auditing requirements. u Fines, charges, waivers, and ecommerce transactions are attached to patron and item records. System tracks fines waived and payments made per library. Financial information can be updated easily. As an example, a staff user can easily query patron accounts with balances greater than X dollars. u The system provides financial reports including: patron account balances by patron, home library, and system; fines and charges accrued per time period (e. g. last twelve months, YTD, last month) and per type of charge (overdue fines, damaged item charges, lost item charges, etc. ); fines waived per time period and per branch; payments made per time period and per payment method (e. g. staff desk, self-check station, OPAC). u The system maintains a ledger of patron payments, including which charges payments are applied to, to facilitate reconciliation. [Class Activity: Perform Checklist Requirements QA Activity based on and the checklist on p 190 of Requirements Engineering by Axel van Lamweerde (1 st ed. , Wiley) Source: Georgia Public Library System PINES SRS by the Requirements Working Group http: //pines. georgialibraries. org/reportsworking-group] 11