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

2. 2 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

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

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

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

6. 6 Model Checkers  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?

7. 7

8. 8

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

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

11. 11 Example: PINES- Category: Financial Records  Req ID: PINES-031 Priority: 1  Name: value of items report  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.  Source: RWG --------------------------------------------------------------------------------------------------------------------------------------  All reports and data archiving must comply with standard accounting practice and state, county, and municipal auditing requirements.  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.  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).  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/reports-working-group] http://pines.georgialibraries.org/reports-working-group