March 21, 2003 – Requirements Engineering Lecture Notes


How to translate different kinds of requirements into a graphical model, and then how to connect the different types of requirements/models


Inheritance –         objectA “is kind of a” or “is a” objectB (parent-child relationship)

                                e.g.  Grad Student is a kind of Student


Figure 1:  Inheritance

·         at a respective level in hierarchy, concept should same level of abstraction (level of detail)

·         need to be differences between: 

o        children and parents

o        one child and another

·         an inheritance model is referred to as a hierarchical model




Aggregation -             collections and decompositions (no inheritance)


Figure 2: Aggregation


RA Session – Analysis

1)  Take significant scenarios, start analysis:  Scenario, Functional, Temporal, Conceptual

2)  Task and concept identification ->  Task and concept generalization

3)  Repeat – very iterative


 Mental Model – high level, very important; not any contingencies or loops, normal flow of operation that bound the system from initiating event (something happened) through the final result (something happened)… should be expressed in past tense as an observed behavior, with verbs to describe steps, not nouns (unlike example).  “Actual process flows” are modeled elsewhere.


Unified Models:  collected requirements that have been modeled from a number of scenarios, and merged



Functional Analysis

·         Process Analysis – session with stakeholder to determine high-level tasks, temporal, I/O, resource dependencies… should result in process flow diagrams, mental models, IDEFs. This should be done first, before task analysis.

·         Task Analysis – not temporal… focuses on how one specific task decomposes (task aggregation).  May be described in process flow, but not necessarily.  Determine classification (task hierarchy) of tasks, understand details of tasks (task template)… task drill down

** IDEF – old school DOD format


Task Decomposition

·         there should be a task decomposition for every block in the mental model

·         Can be hierarchical or aggregative – stop at the point before implementation details


Task Abstraction


Task Template - collection of a lot of data

·         process analysis – task ID, I/O, temporal (a thread or exception), use cases

·         task analysis – determine which tasks to pick (leaf nodes)

·         pre-post (process flow) – timing diagrams, message sequence


Analysis following this step are for filling in the Task Template


Temporal Analysis – sequence diagram (swim lanes)


Functional and Temporal information combined – IDEFs per scenario (process flow)


Conceptual Analysis – comes from knowledge representation/AI community (SWE borrows)

·         purpose – classify resources (people, equipment, HW, SW), performers, data

·         output

o   characterizations (frames, entity-relationship diagrams)

o   classifications – hierarchies

o   definitions – domain dictionary

·         Resource hierarchy

·         Data hierarchy

·         Data ER diagram – all relationships labeled (levels of hierarchy - abstraction, aggregation)