DataMuseum.dk

Presents historical artifacts from the history of:

CR80 Wang WCS documentation floppies

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about CR80 Wang WCS documentation floppies

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - download

⟦9a074464b⟧ Wang Wps File

    Length: 3435 (0xd6b)
    Types: Wang Wps File
    Notes: ARTIKLER (SYS. DESCRIPT.) 
    Names: »4563A «

Derivation

└─⟦61f87be83⟧ Bits:30006024 8" Wang WCS floppy, CR 0420A
    └─ ⟦this⟧ »4563A « 

WangText





                            - # -








R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲L̲a̲n̲g̲u̲a̲g̲e̲

The System Requirements Specification of any planned system,
 represents the first complete description of all the functions
 to be performed by the planned system. Desirable properties
 of a Requirement Specification includes completeness, consistency,
 comprehensibility, traceability, ambiguity (testability and
 verifiability), modifiability and writeability.

Today, no complete set of tools exist which will assist users
 and designers in descriptions of a new system to the extend
 desirable.


S̲y̲s̲t̲e̲m̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲

The Requirements Specification of a planned system is a contract
 between the receiver and the supplier of a system. Suppliers
 are skilled people, who may be trained in using any new tool,
 while the receiver or user must not be expected to adapt difficult
 new techniques, because they are normally just not acceptable.
 Hence, a formal Requirements Specification Language must have
 an apparent plain language interface to the receiver of a new
 system. This means that an end user of a planned system must
 accept any formal requirements language on a readable and understandable
 level after af very short training, while the designer of a
 planned system must be able to use a Requirements Language in
 a more active fashion.

Good specifications are the baseline for all the following phases
 like design, coding, testing and acceptance. The better the
 baseline is, the better the total result will be.

Considering that a Requirements Specification Language needs
 an apparent natural language interface, main technique that
 are candidates for using in a Requirements Specification Language
 are for instance natural language translations, where a text
 is analysed and broken down in components. This analysis could
 cover areas like sentence length, special ambiguity constructions
 and context apprehension, e.g. locate verb and noun of a sentence.

These techniques could be combined with cross reference techniques
 by identifying similar nouns in different parts of the specifications
 in order to highlight any possible ambiguities.

Using a formal Specification Language might also improve the
 planning of resources for the following phases, because a formal
 evaluation can be evaluated qualitative.


C̲e̲r̲t̲i̲f̲i̲c̲i̲a̲l̲ ̲I̲n̲t̲e̲l̲l̲i̲g̲e̲n̲c̲e̲ ̲w̲i̲t̲h̲i̲n̲ ̲A̲i̲r̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲

The importance of efficient Air Traffic Control procedures is
 well established in society today. Many of these procedures
 are dependant on human resources, but could be automated in
 order to releave the human role for supervision and emergency
 interceptions.


S̲y̲s̲t̲e̲m̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲

The use of reporting of flight leading to update of a data base
 and followed by a scheduling of all events could be automated
 and implemented on highly reliable systems using dublication
 or redundancy techniques. This type of information could be
 automatically compared to radar output information in order
 to alarm on any discrepancies between planned data and actual
 data for a management by exception concept.

An Air Traffic Control system which uses AI could be coupled
 directly with the radio communication system and give verbal
 directions to the airplane crew in or before emergency situations.