Requirements Engineering:  4/12/03 Lecture Notes




Slide 2: 

  • While the requirements engineering could end once the requirements specification document has been produced, RE can also continue throughout the entire SW development process
  • Today’s focus is on the Formal specification document.


Slide 4:  Objectives

  • Abstraction – taking a broader view to gain understanding
  • Incremental modeling
  • Reuse
  • Why use informal?  More expressive, but imprecise
  • Formal representation – to be abstract, but precise


Slide 5:  Formal methods

  • computational model
  • mathematically based representation – well defined syntax
  • formal reasoning – want to be able to aske questions – well-defined approach to asking questions of these models, assurance that the answer is correct


Slide 6:  Formal system

  • Language – syntax and semantics
  • Deductive system
    • Axioms and inference rules - interprets language
    • Proofs
    • Automated


Slide 7:  Properties

  • More precise than informal systems
  • Consistency – does not support contradicting statements
  • Completeness – represents all relevant facts to the model
  • Soundness – represents only the relevant facts to the model
  • Decidability


Slide 8:  Formal Requirements Specification and Evaluation Process

  • Choose Formal Framework (for this lecture – ALCOA)
  • Btw, these languages are valuable for testing as well
  • Construct spec – within constraints of syntax and semantics
    • So how do you choose an appropriate framework?  There are a number of tools that are geared for particular types of models, depending on what the most important elements of the model are.
  • Validate, Synthesis – iterative process
  • How does this help towards the code generation?  It prevents gap identification (holes in the requirements) from being identified during the coding phase.  Those gaps get identified earlier, automatically through the use of a formal system.


Slide 9:  Benefits

  • SW Development Benefits
    • Coding – whether code is “generated” from this system or not
    • Guidance – structuring what to represent
    • Documentation – great for developers
    • Rigor
    • Mechanisms – automation
  • Quality
    • Greater assurance – reliability, security, safety… especially important for critical systems
    • Reduced liability – no potential holes, etc


Slide 10:  Benefits

  • Representation responsibility shifted from customer to developer – this is good because the developers are experts in the implementation space, and forces developers to become more familiar with the problem space, in a structured way that is similar to what they’re used to (programming languages)


Slide 11:  Not widely used, because…

  • Payoff not clear
  • Not a lot of experience – learning curve
  • Lack of support
  • Not as user-friendly as natural language
  • Too many existing tools and techniques – a company usually already has a “way of doing things”, resists change
  • Budget
  • Techniques not widely applicable to other spaces


Slide 13:  Characteristics

  • Model oriented – mathematical constructs
  • Property oriented – there are certain pre-conditions/post-conditions
  • Visual – graphical representation
  • Executable – model can be interpreted from the formal representation, and actually “run”


Slide 14:  Types of Languages

  • State Transition Specs – popular, most difficult to model – most useful for testing, coding often reflects “states”
  • Axiomatic – based on inherent truths about the model
  • Analysis/Design Model Specs – recent development, based on object-oriented analysis and design techniques, to leverage the work in that area.


Slide 15:  Clock Example

  • text fragments – outlining requirements
  • may seem like a simple example – this is because the scope is well-defined, limited


Slide 16:  Abstract Model

  • Model à  sets, sequences, relations, functions
  • Operation à  the effects on the elements of the model
  • Specification includes:  type, model, invariants, pre/post conditions (operations)


Slide 17:  Abstract Model

  • Pros
    • state is explicit (state is defined as the collection of all the values in a system at a given point)
    • widely applicable
  • Example:  Z is the most popular





* * * * * * * * * * * * * * * * * * * *                             

Homework #2:


Points on the grade guidelines:


Pts          Indicator               

0                     None

1                     Minus

2                     Check-minus

3                     Check

4                     Check-plus

5                     Plus


Total Pts                Grade     

99                              A+

34                              A

33                              A-

32                              B+

30                              B

27                              B-


* * * * * * * * * * * * * * * * * * * *                             


Slide 18:  Z Notation – see example


Slide 19:

  • Box1 :  Clock object, composing objects of clock
  • Box2:  Operation Init_Clock, with post-conditions defined (time=midnight AND bell=quiet AND alarm=disabled)
  • Box3:  Operation Tick,
    • Increment time
    • If time=alarm_time AND alarm=enabled, then bell=ringing
    • If alarm_time not= time and alarm=enabled, then bell stays same
    • Alarm state stays the same, alarm time stays the same


Slide 20:

  • Box1:  Operation SetAlarmTime
    • Assign alarm_time to new_time
    • More conditionals
    • Time’=time (because setting the alarm is instantaneous, so time is not updated)
  • Box2:  Operation EnableAlarm
  • Box3:  Operation DisableAlarm


Slide 21:  Alloy

  • simplified version of Z
  • evaluation provided to ALCOA  (Alloy Constraint Analyzer)



Family domain, with fundamental (atomic) constructs

  • Schemas (Family schema)
  • Domain – fundamental objects (Person)
  • State – classes & relations
    • “paritition man:woman” – a person can be either a man or a woman
    • “sibling = personàperson” – siblings have a person-to-person relationship
  • Invariants – rules, constraining object values and relations
    • “invBiological{ all p | (sole p.parents&Man) && (sole p.parents&Woman)” – a person can only have one male parent and one female parent (father and mother)
    • “all p | p.siblings = { q |q.parents /= p.parents } –p” – the set of siblings of p is all persons q whose parents are the same as p’s, excluding p him/herself
  • Conditions – realistic instances
  • Assertions – questions against the model
    • “assert SiblingsSiblings { all p | p.siblings = p.siblings.siblings}”  - a person’s siblings are his/her siblings’ siblings

Upon evaluating an assertion, ALCOA will look for situations where that assertion is not valid (counterexamples) that identify gaps in the invariants or states.


Slide 22-27:  Algebraic Specifications/Example (pretty straightforward)


Slide 28:  State Transition Specification

  • A state – the state of an object OR the state of a domain based on a set of specific  states of the domain’s objects


Slide 29:  State Transition Specifications

  • Pros and Cons
    • Pro:  Emphasis is not on representational details – don’t worry about data structures or operations, just states
    • Con:  State explosions – common, but well-recognized and solutions exist
  • Graphical as well as textual notations


Slide 30:  State Transition  Example – clock – State Chart


Slide 31-32:  ASLAN Example


Slide 33:  Axiomatic Specification

  • Inherent truths
  • Tied to formal work in computer science/computational science
  • Emphasis is on pre/post conditions


Slide 34:  Axiomatic Spec

  • Inductive assertion method – the combination of facts implies some new fact (as opposed to deductive – the assertion is validated against the existing facts)


Slide 35-36:  VDM – clock example


Slide 37:  Analysis/Design Model Specs

  • Object-oriented approach is well-defined, has high usage… this type of formal specification leverages the work done in OO programming


Slide 38:  Analysts/Design Model Spec

  • Executable UML – complaint is that it tries to express too much
  • SEPA Domain Reference Architecture



Slide 41:  How Formal Representation helps/hurts

  • Charts shows that some tasks are aided, others are hindered


Slide 42-44:  Conclusions



ANALYZING REQUIREMENTS (Dr Barber’s second packet)

For final exam, understand what verification and validation is.


Slide 5:  Verification

  • IEEE Definition
  • Minimum Verification analysis verifies – (from text book)
    • Do the features meet the needs (requirements)
    • Use cases and requirements from the features truly support features
    • Use cases are actually implemented in design
    • etc


Slide 6:  Verification is a study in traceability

  • Verification will keep you out of court. – “I did what you told me to do”


Slide 7:  Validation

  • Validation - Confirming the development results (implementation) are correct
  • Two aspects
    • Product conforms to requirements
    • Customer ACCEPTANCE
  • A system could be verified, but not valid – if requirements were wrong.
  • Validation is checking for correctness
  • Contractual obligation should be based on VERIFICATION, not VALIDATION (because verification is traceable)



Homework Assignment #4


  • Textual description is from HW #3 Assignment sheet
  • Use graphical models included with HW #4 (don’t use the ones you came up with in HW #3)



For next month:

Friday- Analysis of requirements, change management, managing the requirements engineering process

Saturday – The Final



  • Use lecture notes as explicit guideline
  • Won’t cover Friday’s lecture on management
  • Testing both technique and motivation for requirements engineering
    • E.g. Q: why would you categorize requirements into different areas?  A:  some requirements are more subject to change than others, like interface requirements or nonfunctional, while others don’t (like domain)
    • E.g. Q:  why would I use hierarchy model?  A:  Hierarchy is used for typing, to describe the general-to-specific characteristics of different objects
  • All short-essay questions, one-liners, create diagrams
  • Key points of class:
    • Scope and how it relates to requirements – in terms of functions, customer base, etc
    • Differentiating types of requirements
    • The layers of a scenario – domain, functionality, technology - interdependencies
    • Different types of representation and why each one is useful
    • Generalize as much as possible – abstraction of the model
    • Traceability – how are all the artifacts of requirements process related
    • Acquisition techniques, what kind of information