Domain Science

6.4 Discussion

⁵¹⁷

Requirements

From Domains to Requirements

⁵¹⁸

7.1 Introduction

⁵¹⁹

Definition 42 Requirements: By a ^′requirements^′ we understand (cf. IEEE Standard 610.12 [63]): “A condition or capability needed by a user to solve a problem or achieve an objective” .

520

Example72 First ‘Requirements’ Examples We give a few examples of requirements. The examples are very brief, hence they are far from representative of comprehensive requirements prescriptions. The examples below are meant to give some very first hints as to what requirements prescriptions may look like.

Take them as rough sketches.

1. Administrative forms processing: Office managers shall be able to design forms, aggregations of forms and routines for extracting information from forms and their aggregations.

2. Airport: Boarding cards shall be electronic cards that automatically register where in, or near an airport, or in an aircraft the card is located.

3. Air traffic: The aircraft tracking system shall alert the terminal control centre operator responsible for handling certain aircraft if any of these deviate significantly from their planned routes. 521

4. Container terminal: The bar-code system which registers each and every container subject to un-loading or un-loading shall fail at most once in every 200,000 registrations.

5. Document system:Each and every (electronic) document shall contain its entire history: from some original as first created, via all intervening editing and/or copying, etc., including the location, time and person responsible for creation, copying and editing.

6. Freight logistics: The freight logistics system, relying on each freight item being suitably equipped with a GPS system responder, is allowed to miss at most one in every 300,000 traced items. 522

7. Financial service system:The stock exchange (system) shall be able to trace all buy and sell orders, as well as all withdrawn such, and all actual transactions, by buyer and seller identification.

8. Hospital:The hospitalisation system which to every actual and scheduled patient provides a (flowchart-like) hospitalisation plan, shall be able, at any moment, to estimate and plan for (allocate and schedule) current, immediate and longer-term resource needs: beds, staff (of all categories), medicine, food and beverages, and operating theatres.

9. Manufacturing company: For each production cell its current, immediate and longer-term uses, supply of production parts, preventive maintenance schedules, as well as staffing, shall be computable

(hence displayable) at any moment. 523

10. Market: Retailer orders with wholesalers, and wholesaler orders with producers (i.e., distributors) shall be automatically issued subject to precisely stated script constraints, and as prompted by “low stock” of certain composites of merchandise.

11. Metropolitan area tourism:TheMetaTourismsystem shall enable any suitably equipped (home PC + special GPS, display screen + software controlled mobile phone) person to plan and execute a sequence of visits to places (hotels, restaurants, shops, museums, etc.) and the transport between these. 524

12. Railways:The train monitoring and control system,RaCoSy,being required, shall be able to monitor trains and, if needed, reschedule train traffic, and to do so continuously, and thus to set signals, switches and train speeds accordingly, and to inform all relevant stake-holders (passengers, train driver, and line and station staff ) of any such changes.

The above examples were presented, at this early stage, just to give you a first “feel” for what we are talking about .

525

The objective of requirements engineering is to create a requirements prescription: A requirements prescription specifies externally observable properties of entities, functions, events and behaviours ofthe machinesuch as the requirements stake-holders wish them to be. Themachineis what is required: that is, the hardware and software that is to be designed and which are to satisfy the requirements. A re-quirements prescription thus (putatively) expresses what there should be. A requirements prescription expresses nothing about the design of the possibly desired (required) software. We shall show how a major part of a requirements prescription can be “derived” from “its” prerequisite domain description.

526

Rule 1 The “Golden Rule” of Requirements Engineering: Prescribe only those requirements that can be objectively shown to hold for the designed software .

“Objectively shown” means that the designed software can either be proved (verified), or be model checked, or be tested, to satisfy the requirements.

527

Rule 2 An “Ideal Rule” of Requirements Engineering: When prescribing (including formalising) require-ments, also formulate tests (theorems, properties for model checking) whose actualisation should show adherence to the requirements .

The rule is labelled “ideal” since such precautions will not be shown in this volume. It ought be shown, but either we would show one, or a few instances, and they would “drown” in the mass of material otherwise presented. Or they would, we claim, trivially take up too much space. The rule is clear. It is a question for proper management to see that it is adhered to.

528

Example73 Analysis of First ‘Requirements’ Examples We analyse the examples of Example 72. Our analysis merely consists in listing the domain-specific terms that need to have been precisely described in a prior domain description:

1. Administrative forms processing:(i) office managers, (ii) design, (iii) forms, (iv) aggregations of forms, (v) routines (scripts) for extracting information from forms and their aggregations.

2. Airport:(i) boarding cards, (ii) where (i.e., airport and aircraft locations).

529

3. Air traffic: (i) terminal control centre operator, (ii) responsible for handling certain aircraft, (iii) aircraft, (iv) deviate significantly, (v) planned route.

4. Container terminal: (i) bar-code system, (ii) register, (iii) container, (iv) unloading, (v) loading, (vi) registration.

5. Document system:(i) document (ii) [document] history, (iii) original, (iv) created, (v) editing, (vi) copying, (vii) location, (viii) time, (ix) person, (x) responsible.

530

6. Freight logistics:(i) freight logistics system, (ii) freight item, (iii) GPS system responder, (iv) trace.

7. Financial service system: (i) stock exchange, (ii) trace, (iii) buy order, (iv) sell order, (v) with-drawals, (vi) actual transactions, (vii) buyer and seller identification.

8. Hospital: (i) hospitalisation system, (ii) actual patient, (iii) scheduled patient, (iv) hospitalisation plan, (v) allocate and schedule resources, (vi) current, immediate and longer-term resources, (vii) bed, (viii) staff, (ix) medicine, (x) food and beverages, (xi) operating theatre.

531

9. Manufacturing company:(i) production cell, (ii) current, immediate and longer-term use, (iii) use, (iv) supply, (v) production part, (vi) preventive maintenance schedules, (vii) staffing.

10. Market: (i) Retailer, (ii) orders, (iii) wholesaler, (iv) producer, (v) distributors, (vi) ordering (“is-sued”), (vii) ordering constraint, (viii) “low stock”, (ix) composite of merchandise.

11. Metropolitan area tourism:(i) person (i.e., potential or actual tourist), (ii) plan, (iii) execute, (iv) visit, (v) place, (vi) hotels, (vii) restaurant, (viii) shop, (ix) museum, etc. (. . . ), (x) transport.

532

12. Railways: (i) monitor train, (ii) reschedule, (iii) train traffic, (iv) set, (v) signal, (vi) switch, (vii) train speed, (viii) inform, (ix) relevant stake-holders, (x) passenger, (xi) train driver, (xii) line staff, (xiii) station staff, (xiv) change.

The above examples were presented, at this early stage, to let you see why we need a precise domain description .

533

Rule 3 Requirements Adequacy: Make sure that requirements cover what users expect .

That is, do not express a requirement for which you have no users, but make sure that all users’ require-ments are represented or somehow accommodated. In other words: the requirerequire-ments gathering process needs to be like an extremely “fine-meshed net”: One must make sure that all possible stake-holders have been involved in the requirements acquisition process, and that possible conflicts and other inconsistencies have been obviated.

534

Rule 4 Requirements Implementability: Make sure that requirements are implementable .

That is, do not express a requirement for which you have no assurance that it can be implemented. In other words, although the requirements phase is not a design phase, one must tacitly assume, perhaps even indicate, somehow, that an implementation is possible. But the requirements in and by themselves,

stay short of expressing such designs. 535

Rule 5 Requirements Verifiability and Validability: Make sure that requirements are verifiable and can be validated .

That is, do not express a requirement for which you have no assurance that it can be verified and validated.

In other words, once a first-level software design has been proposed, one must show that it satisfies the requirements. Thus specific parts of even abstract software designs are usually provided with references to specific parts of the requirements that they are (thus) claimed to implement. 536

We repeat the characterisation of the concept of ‘requirements’.

Definition 43 Requirements: By^′requirements^′we shall understand a document which prescribes desired properties of a machine: (i) what entities the machine shall “maintain”, and what the machine shall (must;

not should) offer of (ii) functions and of (iii) behaviours (iv) while also expressing which events the machine shall “handle” .

537

By a machine that “maintains” entities we shall mean: a machine which, “between” users’ use of that machine, “keeps” the data that represents these entities. From earlier we repeat: 538

Definition 44 Machine: Bymachinewe shall understand a, or the, combination of hardware and software that is the target for, or result of the required computing systems development .

539

So this, then, is a main objective of requirements development: to start towards the design of the hardware + software for the computing system.

Definition 45 Requirements: To specify the machine .

When we express requirements and wish to “convert” such requirements to a realisation, i.e., an imple-mentation, then we find that some requirements (parts) imply certain properties to hold of the hardware on which the software to be developed is to “run”, and, obviously, that remaining — probably the larger parts of the — requirements imply certain properties to hold of that software. So we find that although 540

we may believe that our job is software engineering, important parts of our job are to also “design the machine”!

7.2 The Example Requirements – The General Setting

⁵⁴¹

The domain was that of transportation. The requirements is now basically related to the issuance of tickets upon vehicle entry to a toll road net¹and payment of tickets upon the vehicle leaving the toll road net both issuance and collection/payment of tickets occurring at toll booths²which are hubs somehow linked to the toll road net proper. Add to this that vehicle tickets are sensed and updated whenever the vehicle

crosses an intermediate toll road intersection. 542

7.3 Stages of Requirements Engineering

⁵⁴³

The following are the stages of requirements engineering:

• stake-holder identification,

• business process re-engineering,

• domain requirements development,

• interface development,

• machine requirements development,

• requirements verification and validation, and

• requirements satisfiability and feasibility.

tp1 tp2 tp3 tpj tpn−1 tpn

ti1 ii2 ii3 iij iin−1 tin

Fig. 7.1.A simple, linear toll road net:

tpi:tollplazai,

ti¹, tin:terminalintersectionk,

iik:intermediateintersectionk, 1<k<n

lxy: tollwaylink from ix toiy,y=x+1 ory=x-1 and 1≤x<n.

544

The domain requirements development stage consists of a number of steps:

• projection,

We shall basically only cover business process re-engineering, domain requirements development, and interface development.

7.4 Business Process Re-engineering

⁵⁴⁵

Business process re-engineering (BPR) re-evaluates the intrinsics, support technologies, management &

organisation, rules & regulations, scripts, and human behaviour facets while possibly changing some or all of these, that is, possibly rewriting the corresponding parts of the domain description.

7.4.1 Re-engineering Domain Entities ⁵⁴⁶

The net is arranged as a linear sequence of two or more (what we shall call) intersection hubs. Each intersection hub has a single two-way link to (what we shall call) an entry/exit hub (toll plaza); and each intersection hub has either two or four one-way (what we shall call) tollway links: the first and the last intersection hub (in the sequence) has two tollway links and all (what we shall call) intermediate intersections has four tollway links. We introduce a pragmatic notion of net direction: “up” and “down”

the net, “from one end to the other”. This is enough to give a hint at the re-engineered domain.

7.4.2 Re-engineering Domain Actions ⁵⁴⁷

We first briefly sketch the tollgate actions. Vehicles enter and leave the tollway net only at entry/exit hubs (toll plazas). Vehicles collect and return their tickets from and to tollgate ticket issuing, respectively payment machines. Tollgate ticket-issuing machines respond to sensor pressure from “passing” vehicles or by vehicle drivers pressing ticket-issuing machine buttons. Tollgate payment machines accept credit cards, bank notes or coins in designated currencies as payment and returns any change.

548

We then briefly introduce and sketch an operation performed when vehicles cross intersections: The vehicle is assumed to possess the ticket issued upon entry (in)to the net (at a tollgate). At the crossing of each intersection, by a vehicle, its ticket is sensed and is updated with the fact that the vehicle crossed the intersection.

The updated domain description section on support technology will detail the exact workings of these tollgate and internal intersection machines and the domain description section on human behaviour will likewise explore the man/machine facet.

1 Toll road: in other forms of English; toll-way, turnpike, pike or toll-pike, in French p´eage.

2 Toll plazas, toll stations, or toll gates

7.4.3 Re-engineering Domain Events ⁵⁴⁹

The intersections are highway-engineered in such a way as to deter vehicle entry into opposite direction tollway links, yet, one never knows, there might still be (what we shall call ghost) vehicles, that is vehicles which have somehow defied the best intentions, and are observed moving along a tollway link in the wrong direction.

7.4.4 Re-engineering Domain Behaviours ⁵⁵⁰

The intended behaviour of a vehicle of the tollway is to enter at an entry hub (collecting a ticket at the toll gate), to move to the associated intersection, to move into, where relevant, either an upward or a downward tollway link, to proceed (i.e., move) along a sequence of one or more tollway links via connecting intersections, until turning into an exit link and leaving the net at an exit hub (toll plaza) while paying the toll.

• • •

This should be enough of a BPR rough sketch for us to meaningfully proceed to requirements prescription proper.

7.5 Domain Requirements Prescription

⁵⁵¹

Definition 46 Requirements Prescription: A ^′domain requirements prescription^′ is that part of the re-quirements prescription which can be expressed sˆolely using terms from the domain description .

Thus to construct the domain requirements prescription all we need is collaboration with the requirements stake-holders (who, with the requirements engineers, developed the BPR) and the possibly rewritten (resulting) domain description.

7.5.1 Domain Projection 552

Definition 47 Domain Projection: By a^′domain projection^′we mean a subset of the domain description, one which leaves out all those entities, functions, events, and (thus) behaviours that the stake-holders do not wish represented by the machine. The resulting document is apartial domain requirements prescription .

Domain Projection — Narrative 553

We copy the domain description and call the copy a 0th version domain requirements prescription. From that document we remove all mention of link insertion and removal functions, to obtain a 1st version domain requirements prescription.³

Domain Projection — Formalisation ⁵⁵⁴ Root Sorts

type

1. ∆

1a. N value

1a. obsN:∆→N

Sub-domain Sorts and Types

type 2. HS, LS value

2a. obsHS: N→HS 2b. obsLS: N→LS

3 Restrictions of the net to the toll road nets hinted at earlier will follow in the next domain requirements steps.

555

Definition 48 Instantiation: By^′domain instantiation^′ we mean a refinement of the partial do-main requirements prescription, resulting from the projection step, in which the refinements aim at rendering the entities, functions, events, and (thus) behaviours of the partial domain require-ments prescription more concrete, more specific. Instantiations usually render these concepts less general .

Domain Instantiation — Narrative ⁵⁶¹

The 1st version domain requirements prescription is now updated with respect to the properties of the toll way net: We refer to Fig. 7.1 and the preliminary description given in Sect. 7.4.1.

There are three kinds of hubs: tollgate hubs and intersection hubs: terminal intersection hubs and proper, intermediate intersection hubs. Tollgate hubs have one connecting two way link.

linking the tollgate hub to its associated intersection hub. Terminal intersection hubs have three 562

connecting links: (i) one, a two-way link, to a tollgate hub, (ii) one one-way link emanating to a next up (or down) intersection hub, and (iii) one one-way link incident upon this hub from a next up (or down) intersection hub. Proper intersection hubs have five connecting links: one, a two way 563

link, to a tollgate hub, two one way links emanating to next up and down intersection hubs, and two one way links incident upon this hub from next up and down intersection hub. (Much more need be narrated.) As a result we obtain a 2nd version domain requirements prescription.

Domain Instantiation — Formalisation, Toll Way Net 564

We simplify the model of nets. Instead of observing hubs and links from nets,n:N, these now are pairs of sets of hubs and links !

type

cN = H-set×L-set

TN = ((H ×L)×(H×L×L))^∗×H×(L×H) value

abs cN: TN→cN

abs cN(tn)≡(tn hubs(tn),tn links(tn)) pre: wf TN(tn)

tn hubs: TN→H-set, tn hubs(hll,h,( ,hn))≡

{h,hn} ∪ {thj,hj|((thj,tlj),(hj,lj,lj^′)):((H×L)×(H×L×L))^•((thj,tlj),(hj,lj,lj^′))∈elemshlll}

tn links: TN→L-set tn links(hll, ,(ln, ))≡

{ln} ∪ {tlj,lj,lj^′|((thj,tlj),(hj,lj,lj^′)):((H×L)×(H×L×L))^•((thj,tlj),(hj,lj,lj^′))∈ elemshlll}

theorem∀tn:TN^• wf TN(tn)⇒wf aN(abs cN(tn))

wherewf aNis expressed in the form of axioms: 8a, 8b, 9b, 10a, 10b, 11a, 11b, Pages 7–9. 565

Domain Instantiation — Formalisation, Well-formedness ⁵⁶⁶ type

LnkM == plaza|way value

wf TN: TN→Bool wf TN(tn:(hll,h,(ln,hn))) ≡

wf Toll Lnk(h,ln,hn)(plaza)∧wf Toll Ways(hll,h)∧ wf State Spaces(tn) [ to be defined under Determination ]

567

value

wf Toll Ways: ((H×L)×(H×L×L))^∗×H→Bool wf Toll Ways(hll,h)≡

∀j:Nat ^• {j,j+1}⊆indshll⇒ let((thj,tlj),(hj,ljj^′,lj^′j)) = hll(j),

ti1

Fig. 7.2.A simple, linear toll road net:

thi:tollplazai,

h¹, hn:terminalintersections,

h2, hj, h^′_j, hk:intermediateintersections, 1<j≤k,k=n-1 lxy, lyx: tollwaylink fromhxtohy and fromhy tohx, 1≤x<n.

lx−1x,lxx−1: tollwaylink fromhx−1 tohx andhx tohx−1, 1≤x<n, dashed links are not in formulas.

( ,(hj^′, , )) = hll(j+1)in wf Toll Lnk(thj,tlj,hj)(plaza)∧

wf Toll Lnk(hj,ljj^′,hj^′)(way)∧wf Toll Lnk(hj^′,lj^′j,hj)(way)end∧ let((thk,tlk),(hk,lk,lk^′)) = hll(lenhll)in

wf Toll Lnk(thk,tlk,hk)(plaza) ∧

obs Ps(l)={(obs HI(h),obs LI(l),obs HI(h^′)), (obs HI(h^′),obs LI(l),obs HI(h))} ∧ obsΣ(l) = casem of

plaza→obs Ps(l),

way→ {(obs HI(h),obs LI(l),obs HI(h^′))} end

7.5.3 Domain Determination ⁵⁶⁹

Definition 49 Determination: By^′domain determination^′ we mean a refinement of the partial domain requirements prescription, resulting from the instantiation step, in which the refinements aim at rendering the entities, functions, events, and (thus) behaviours of the partial domain requirements prescription less non-determinate, more determinate. Instantiations usually render these concepts less general .

Domain Determination — Narrative ⁵⁷⁰

We single out only two ’determinations’:The link state spaces.There is only one link state: the set of all paths through the link, thus any link state space is the singleton set of its only link state.The hub state spaces are the singleton sets of the “current” hub states which allow these crossings:

(i) from terminal link back to terminal link, (ii) from terminal link to emanating tollway link, (iii) from incident tollway link to terminal link, and (iv) from incident tollway link to emanating tollway link. Special provision must be made for expressing the entering from the outside and leaving toll plazas to the outside.

Domain Determination — Formalisation ⁵⁷¹ wf State Spaces: TN→Bool

wf State Spaces(hll,hn,(thn,tln))≡ let((th1,tl1),(h1,l12,l21)) = hll(1),

((thk,ljk),(hk,lkn,lnk)) = hll(lenhll) in wf Plaza(th1,tl1,h1)∧wf Plaza(thn,tln,hn)∧

wf End(h1,tl1,l12,l21,h2)∧wf End(hk,tln,lkn,lnk,hn) ∧

∀j:Nat ^• {j,j+1,j+2}⊆indshll⇒

let(,(hj,ljj,lj^′j)) = hll(j),((thj^′,tlj^′),(hj^′,ljj^′,lj^′j^′)) = hll(j+1) in wf Plaza(thj^′,tlj^′,hj^′)∧wf Interm(ljj,lj^′j,hj^′,tlj^′,ljj^′,lj^′j^′)end end

572

wf Plaza(th,tl,h)≡

obs HΣ(th) = {[ crossings at toll plazas ] (^′′external^′′,obs HI(th),obs LI(tl)),

(obs LI(tl),obs HI(th),^′′external^′′), (obs LI(tl),obs HI(th),obs LI(tl))} ∧

obs HΩ(th) ={obs HΣ(th)} ∧obs LΩ(tl) = {obs LΣ(tl)}

wf End(h,tl,l,l^′)≡

obs HΣ(h) = {[ crossings at 3−link end hubs ]

(obs LI(tl),obs HI(h),obs LI(tl)),(obs LI(tl),obs HI(h),obs LI(l)), (obs LI(l^′),obs HI(h),obs LI(tl)),(obs LI(l^′),obs HI(h),obs LI(l))} ∧ obs HΩ(h) ={obs HΣ(h)} ∧

obs LΩ(l) = {obs LΣ(l)} ∧obs LΩ(l^′) = {obs LΣ(l^′)}

573

wf Interm(ul 1,dl 1,h,tl,ul,dl) ≡

obs HΣ(h) ={[ crossings at properly intermediate, 5−link hubs ] (obs LI(tl),obs HI(h),obs LI(tl)),(obs LI(tl),obs HI(h),obs LI(dl 1)), (obs LI(tl),obs HI(h),obs LI(ul)),(obs LI(ul 1),obs HI(h),obs LI(tl)), (obs LI(ul 1),obs HI(h),obs LI(ul)),(obs LI(ul 1),obs HI(h),obs LI(dl 1)), (obs LI(dl),obs HI(h),obs LI(tl)),(obs LI(dl),obs HI(h),obs LI(dl 1)), (obs LI(dl),obs HI(h),obs LI(ul))} ∧

obs HΩ(h) ={obs HΣ(h)} ∧obs LΩ(tl) ={obs LΣ(tl)} ∧ obs LΩ(ul) ={obs LΣ(ul)} ∧obs LΩ(dl) ={obs LΣ(dl)}

and add: 574

value

xtr HIs: (H ×L ×L)^∗

xtr HIs(hlll)≡ {h|(h,l,l^′):(H×L×L)^•(h,l,l^′)∈elemshlll}

Not all determinism issues above have been fully explained. But for now we should — in principle

— be satisfied.

7.5.4 Domain Extension 575

Definition 50 : By^′domain extension^′ we understand the introduction of endurants, functions, events and behaviours that were not feasible in the original domain, but for which, with computing and communication, there is the possibility of feasible implementations, and such that what is introduced become part of the emerging domain requirements prescription .

Informal Sketch ⁵⁷⁶

The following is a prolonged example. It contains three kinds of formalisations: aRAISE/CSPmodel, aDuration Calculusmodel [108, 80] and aTimed Automatamodel [2, 80]. The narrative for all three models are given when narrating theRAISE/CSPmodel.

Domain Extension — Narrative ⁵⁷⁷

The domain extension is that of the controlled access of vehicles to and departure from the toll road net: the entry to (and departure from) tollgates from (respectively to) an"an external"net — which we do not describe; the new entities of tollgates with all their machinery; the user/machine functions: upon entry: driver pressing entry button, tollgate delivering ticket; upon exit: driver presenting ticket, tollgate requesting payment, driver providing payment, etc.

578

One added (extended) domain requirements: as vehicles are allowed to cruise the entire net payment is a function of the totality of links traversed, possibly multiple times. This requires, in our case, that tickets be made such as to be sensed somewhat remotely, and that intersections be equipped with sensors which can record and transmit information about vehicle intersection crossings. (When exiting the tollgate machine can then access the exiting vehicles sequence of intersection crossings — based on which a payment fee calculation can be done.)

All this to be described in detail — including all the thinks that can go wrong (in the domain) and how drivers and tollgates are expected to react.

Intuition ⁵⁷⁹

A toll road system is delimited by toll plazas with entry and exit booths with their gates. To get access, from outside, to the roads within the toll road system, a car must pass through an entry booth and its entry gate. To leave the roads within the toll road system a car must pass through an exit booth and its exit gate. Cars collect tickets upon entry and return these tickets upon exit and pay a fee for having driven on the toll roads. The gates help ensure that cars have collected

A toll road system is delimited by toll plazas with entry and exit booths with their gates. To get access, from outside, to the roads within the toll road system, a car must pass through an entry booth and its entry gate. To leave the roads within the toll road system a car must pass through an exit booth and its exit gate. Cars collect tickets upon entry and return these tickets upon exit and pay a fee for having driven on the toll roads. The gates help ensure that cars have collected

In document Dines Bjørner From Domains to Requirements (Sider 114-0)