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)

·