Defining Systems for more that 40 years


Problem Statement Analyzer (PSA)

When a system description has been prepared, debugged, and compiled into a PSA Database, there are several options available to use the information:

  • different aspects of the system need to be described and summarized. PSA provides 36 standard reports.
  • ad hoc combinations of objects and relations, selecting information by various criteria, can be obtained by using the Query System (QS).
  • a generalized database management system access facility is provided by the Report Specification Interface (RSI). The output can be combined with formatting instructions to automated the production of pre-defined complex reports. An example of this is given in the Functional Specification Generator (FSGEN) pages.
  • Elements in the PSA database can be extracted and converted into source material for input into other utilities (for example, a COBOL Data Division can be extracted, a database schema can be produced, and sequencing information can be extracted to produce outline transaction definitions for a transaction processing monitor).
  • A normalized data model can be generated using the View Integration System (VIS).

PSA is used most effectively in a PSA Usage Process. This can implement completeness and consistency standards, generate standard specification documents, and produce some source material for input into other utilities.

PSL Relations

PSL Relations

PSL provides a range of 102 relations between various combinations of Objects:

access right bt terminates employs links receives subtype
adds bt triggers equivalent to locking causes references terminates
affects cardinality flows locking causes false relates terminates false
affects-false causes function-of locks removes termination causes
asserts causes-false generates locks-false responsible interface termination causes false
associated-data changes happens maintains responsible problem definer trace key
attributes classification identifies makes false resumes triggering causes
becoming false (bf) affects coding structure in-response to makes true resumes false triggering causes false
bf causes collection includes measures resumption causes triggers
bf interrupts composition interruption causes (ic) memo resumption causes if false triggers false
bf resumes connectivity ic-false modifies right-part unlocking causes
bf terminates consists interrupts ordered by satisfies unlocking causes false
bf triggers consumes interrupts false participation security unlocks
becoming true (bt) affects creates keywords performs source unlocks false
bt causes derives known process order subparts updates
bt interrupts destroys left-part project cross reference subsets utilizes
bt resumes duration level range subsetting criterion value

The relations connect PSL Objects in a variety of ways. Detailed discussion is in the website wiki.


Problem Statement Language (PSL)

The Problem Statement Language is used to express system requirements by means of a formal language.

The language is expressed using OBJECTS and RELATIONS.

There are several key steps in the PSL Language Process.

  • An editor is used to create a language source file
  • The source file is processed, checking for syntax errors. The langauge PSL defined as a set of objects and relations defines the consistency that must be achieved when writing PSL to produce correct input.
  • When the source is "correct", it is processed to populate a PSA database.
  • PSA reports are used to identify unacceptable levels of incompleteness, and a cycle of editing PSL, processing the source, and populating the PSA database is performed.

Implementing a particular method or standard for specifying systems is achieved by mapping the required combination of PSL objects and relations for each required element of the method or standard. This means that PSL/PSA can also be used to check the meta models of other CASE tools used for specification, analysis, and design.

PSL Objects

The language evolved from 1968-1991. Key version ranges were:

Date Range Version(s)
1968 1.0
1970 2.0
1975 3.0
1977 4.2
to 1981 5.0 - 5.2
1987 - 1990 6r0 - 6r3

Versions 3.0 of the Language could be used to define 14 Objects:


Versions 5.1 and 5.2 of the Language could be used to define 17 Objects:


Version 6.x made provision for 19 objects:



PSL/PSA - Past

PSL/PSA is perhaps the world's oldest and most comprehensive set of tools for stating system requirements. It started in 1968 and has had a very impressive set of sponsors at various times.

The history of CASE (Computer Aided/Assisted Software/System Engineering) shows that since the mid-1980s the evolution of the market for tools moved substantially in the direction of PC-based graphical techniques using methods such as data flow diagrams and data models. There is a view that these PC-based graphical techniques are generally only useful for relatively trivial systems, and when used for large (size or complexity) the techniques will be dysfunctional by rendering the proper checking of completeness and consistency either extremely difficult or impossible. Linguistic techniques such as PSL/PSA have no known limit of scalability (there is anecdote of one system modelled with PSL/PSA handling around 35,000 objects and 65,000 relations). Unfortunately there has been very little research in this area, so even today the choice of method is more likely to be based on familiarity, prejudice or ideology rather than supportable evaluation of alternatives.

PSL/PSA was the best-known output from the ISDOS (Information System Design and Optimization System) Project at the University of Michigan (UoM) under Professor Daniel Teichroew in the Department of Industrial and Operations Engineering. That project was sponsored by many substantial organizations.

Most ISDOS products were developed at UoM between 1968** and about 1983/4. Then a separate commercial operation (ISDOS Inc) was set up. After that, commercial operations were separated from UoM and went through a series of ownerships as described briefly in COMMERCIAL OPERATIONS.

There are additional sections to be added to the website:

  • ISDOS - covering UoM activities
  • Commercial Operations covering exploitation
  • Future - what next for PSL/PSA
  • Related Tools

**The ISDOS Project commenced initially during 1967 in the School of Management at Case Western Reserve University, Cleveland, Ohio. It moved to the University of Michigan in 1968. The terms 'Problem Statement Language' and 'Problem Statement Analyzer' are used right from the beginning in ISDOS Working Paper No. 1 (1967).

Additional tools have been developed alongside PSL/PSA and independently

The language evolved from 1968-1991. Key version ranges were:

Date Range Version(s)
1968 1.0
1970 2.0
1975 3.0
1977 4.2
- 1981 5.0 - 5.2
1987 - 1991 6r0 - 6r3
1991 - 2011 use on various large projects
2012 on - 7.0 -

The major phases of the ownership of PSL/PSA are shown in the following table:

Date Range Ownership of PSL/PSA
1968 - circa 1983 University of Michigan ISDOS Project
circa 1983 - circa 1987 ISDOS Inc.
circa 1987 - circa 1990 Meta Systems Ltd.
circa 1990 - 1996 LBMS Ltd.
1996 onwards Geoffrey Darnton

The last release generally available commercially was PSL/PSA Version 6.0 Release 3 around September 1990.

A simplified version of Problem Statement Language (PSL-lite) will be made available, and the language placed in the public domain (along with the original PSL). Commercial exploitation can be done by anyone who wishes to implement the language. Copyright will be retained to ensure a mechanism to certify compliance and prevent abuse. A new full version of PSL will be available commercially.

PSL/PSA, Related Tools and associated training can be provided now on reasonable commercial terms to anyone who has a need or interest to use them.

© Geoffrey Darnton 1992-2018