2011F outline

Guide to topics discussed in class:

• Slides 01: Introduction to requirements engineering. Solving the right problem (the one our customer needs to solve). Why “waste time” doing requirements? (i.e. the importance of RE).
• Required readings: Chapter 1 of suggested text (AvL09)
• Slides 02: Problem Domain vs. Solution Domain. Scope of RE. Requirements are about phenomena external to teh machine. E-descriptions, R-descriptions, S-descriptions, M-descriptions. Difference between a requirements and a Specification. Dependability/Certification argument. System-as-is vs. System-to-be. WHY, WHAT, WHO? Parnas 4-variable model.
• Do the specification exercise 1 (date validation) in the slides

• Tabular expressions help to provide complete and disjoint specifications
• Tabular expressions help to develop test cases. They cover all the corner cases.
• Why will tabular expressions help developers produce better code?
• What does it mean for a tabular expression to be well-defined?
• See slides 03 (Parnas function tables/tabular expressions) and 04 (birthday book example) for examples of tabular expressions.
• Required readings: Slides 1-15 of ReqIntro-Alexander.pdf (in SVN, and text on reserve in Steacie). These slides will introduce you to “soft” topics in RE.

• Context diagrams. Why do we need them? What are monitored and what are controlled variables?
• What are the phenomena of the environment? What are phenomena of the software machines? Can you give examples?
• What is the difference between a R-description and an E-description? Why do we need these descriptions?
• See 04 slides on leap years, date validation and birthday book for examples of context diagrams and R/E descriptions.
• To code we need requirements To write requirements we need domain knowledge. What is domain knowledge?
• Required reading: How to write requirements (Telelogic), on SVN. This important document will help you to produce precise unambiguous atomic R/E descriptions.

MSR uses a combination of ideas from Z, B, Event-B and Parnas function tables for the mathematical specification of systems. The suggested text uses Z for part of the course.

• What are specification modules? How do they differ from design modules or code modules?
• Review of predicate logic, set theory, functions (total, partial, injective, surjective, bijective), relations, sequences, bags.
• What are carrier sets, constants, variables, queries and invariants in specification modules?
• What are actions, events and procedures in specification modules?
• When do we use an event and when to use a procedure in a specification?
• What is a pre-state and what is a post-state? When do we use unprimed variables and when do we use primed variables?
• What is the difference between a procedure precondition and an event guard?
• What is an action predicate?
• What is the proof rule that ensure that actions (events or procedures) maintain the specification module invariant?
• What is an execution of a module having events?
• What are parameterized carrier sets? What is an injective constructor for carrier sets?
• Required readings: slides 04 for review and examples of the above using leap years, date validation and the birthday book example?
• Note that a precise and complete mathematical specification of the birthday book (specification modules and tabular expression) is less than two pages. The specification describes precise outputs for all possible inputs whether valid or invalid. The specification can be used to predict the future behaviour of any software machine that implements the specification.

We discuss the paper by Baber, Parnas and Vilkomer (it is in Slides/SVN).

Abstract: We describe our experience applying tabular mathematical approaches to software specifications. Our purpose is to show alternative approaches to writing tabular specifications and to help practitioners who want to apply such methods by allowing them to pick the best one for their problem. The object for the case study is software used by Dell Products for testing the functionality of the keyboards on notebook computers. Starting from informal documents, we developed a variety of tabular representations of finite state machine specifications and tabular trace specifications. We found that the discipline required by these methods raised issues that had never been considered and resulted in documents that were both more complete and much clearer. The various tabular representations are compared from a user’s point of view, i.e., clarity, consistency, unambiguity, completeness, suitability, etc Keywords: software, tabular specifications, finite state machine, traces, trace specifications.

Required: Watch a video recording of Precise Documentation: The Key to Better Software, David Lorge Parnas. The slides from this talk are on the SVN.

The suggested text discusses how UML models are used in requirements engineering. We discuss use cases/diagrams, class diagrams, statecharts (XOR and parallel composition) and sequence charts. UML does not have the formality of MSR; we discuss the pros and cons. We also distinguish between the use of UML in design as opposed to requirements. See slides and UML resources on this website. See the fully worked out requirements example involving the train transportation system on the SVN.

• Difference between transformational and reactive systems
• Safety critical systems are usually reactive
• Difference between proof systems and model checking
• Timed Transition Models
  • types, constants and variables
  • module templates with in, out and share variables
  • module instants
  • module compositions
  • model-checking and reachability graphs
  • temporal logic specifications
  • safety properties and liveness properties
  • discussion of the the bridge controller

This is covered in the slides in the SVN: Readings/ReqIntro-Alexander.pdf (based on the text in Steacie: Discovering Requirements (Alexander et.al). Stakeholders. Goals vs. Requirements. Context, interaction and scope. Scenarios. Priorities. Hazard/risk analysis. In Scenarios we reviewed how to use Use Cases and the include and extend relations.