1. Relating Problem & Solution Structures
Bashar Nuseibeh & Michael Jackson
Computing Department, The Open University, UK
David Bush
National Air Traffic Services, UK

2. The Open University One of the world’s 11 “mega-universities”:
The UK’s largest university (200,000+ students)
Specialist in distance education and e-learning
Computing Department research areas:
Software Engineering
Human-Computer Interaction
Educational Technology
© Bashar Nuseibeh, The Open University, 2001

3. Requirements & Architectures
Denote stakeholder goals & expectations
Are expressed in the vocabulary of the problem world
Can conflict & change
Architectures
Denote systems’ structure
Are expressed in terms of components & inter-connections in the solution world
Should be stable & robust
While most engineering has the notions of requirements and architectures, software/systems engineering has paid particular attention to these in recent years, and we believe they have applicability in the ATM domain …
At NATS, requirements are often described in business cases, requirements specifications, and to some extent in project plans.
At NATS, architectures take the form of (high-level) design.
The key to developing a system that meets stakeholder expectations is an explicit understanding of these stakeholders’ problems and requirements.
A system’s architecture provides an explicit design/solution structure upon which a system will be built.
© Bashar Nuseibeh, The Open University, 2001

4. Problem and Solution Structures
The development process constructs:
problem structures (requirements), and
solution structures (architecture).
For large systems that develop and evolve:
there is often a discontinuity between the two structures;
this leads to poor traceability of design decisions back to requirements, and inadequate change impact analysis.
The software engineering community has promoted and researched the explicit representation of requirements (problem structures) and architectures (solution structures).
Often the problem structure doesn’t exist at all, or has been lost over many years/iterations of change; e.g., STCA had some excellent design documentation, but hardly an requirements documentation.
There may be many views of architecture; e.g., physical, logical, etc…
© Bashar Nuseibeh, The Open University, 2001

5. Research Areas Development Processes - Development Products -
There is a need for closer intertwining of requirements & architecture development.
Development Products -
There is a need to develop and relate patterns of requirements & architecture.
The proposed project will contribute to both the processes of systems development, and the products.
Closer intertwining means that requirements and architectures can be co-developed and co-evolve. This concurrent engineering can lead to improved traceability between requirements and architectures, and more realistic/sensible/robust requirements and design documentation. Otherwise get a waterfal life cycle with all its disadvantages (and as in STCA, having to reconstruct the requirements in order to evolve the system and in order to identify reusable bits for MSAW).
Concurrent development is not enough. Need to relate the artefacts of the development as well. This can be difficult and can be assisted by using exiting patterns of requirements, architectures, and designs. Patterns capture commonality in structure
© Bashar Nuseibeh, The Open University, 2001

6. The “Twin Peaks” Process: weaving requirements & architectures
General
Detailed
Level of
Detail
Specification
This has implications on the organisational development processes, and potentially the contractual procedures deployed. It is not clear whether or not ATC systems would benefit from models that speed up the development process, but if that reasoning is not motivating enough, then the resultant improvement in quality of the documentation (and system) may be more convincing…
Requirements
Architecture
Implementation Dependence
Dependent
Independent
© Bashar Nuseibeh, The Open University, 2001

7. Problem Frames
A problem frame defines the shape of a problem for which there is an known solution.
Separates phenomena of “world” from “machine”;
separates assumptions (domain properties) from requirements.
Simple problem frames can be composed together to produce more complex (and realistic) composite frames.
A number of basic problem frames have already been identified by Jackson (2000).
Problem frames make assumptions (domain properties) explicit. This allows us to question whether these assumptions are correct.
From Michael:
Problem frames maintain the distinction between the machine and the problem domain right down to the lowest levels of problem decomposition. Each subproblem frame has its own machine and its own projection of the complete original problem domain. The approach also places great emphasis on appropriately identifying the phenomena with which the problem is concerned, and on the distinction between problem phenomena and machine phenomena. The simplest illustration of this distinction is in the treatment of model (surrogate) domains such as databases and stored assemblages of objects or other data structures: they are carefully distinguished from the reality that they are intended to model but necessarily can model only imperfectly.
In air traffic control applications, these careful distinctions may be expected to prove particularly valuable, especially in such areas as the of modelling planes, radar tracks, real trajectories and flight plans. The benefits we hope for include avoiding many potential sources of confusion, and being able to characterise and decompose the problem to be solved in a much simpler and clearer way.
A number of basic problem frames have already been identified by Jackson (2000); e.g., required behaviour, commanded behaviour, information display, simple workpieces, and transformation
© Bashar Nuseibeh, The Open University, 2001

8. Problem and solution patterns
Requirements
Problem Frames
Components
The Twin Peaks process necessitates a better understanding of the relationships between the artefacts produced during requirements engineering and design.
Patterns facilitate reuse.
Design Patterns
Architectural Styles
Design
Architecture
© Bashar Nuseibeh, The Open University, 2001

9. Research Issues
Searching for and identifying (basic & composite) patterns of requirements and architectures in existing ATM systems.
Relating these patterns to provide more effective traceability and (change) impact analysis.
Using these relationships to provide more effective reuse between different ATM systems and their development.
© Bashar Nuseibeh, The Open University, 2001

10. Research Methodology Case study-driven investigation
Initially, document-driven analysis
Eventually, stakeholder-driven elicitation
Precedent: working with NATS on STCA & MSAW.
To make the research issue less abstract, our plan is to analyse existing ATC documentation
© Bashar Nuseibeh, The Open University, 2001

11. Desirable Endpoint?
Architectural stability in the face of inevitable requirements volatility.
Maintainable systems though improved change impact analysis, traceability, and reuse.
Applicable to technical, socio-technical, and business systems?
© Bashar Nuseibeh, The Open University, 2001

12. Architectural Styles
Architectural styles define the shape or structure of a solution that has some known characteristics.
Describe components & interconnection types.
An architecture is a particular instance of an architectural style.
Examples: pipe-and-filter and blackboard.
This slide is optional – depending on time…
© Bashar Nuseibeh, The Open University, 2001