1 / 35

Automating Requirements Analysis

Automating Requirements Analysis. Organisational Layers. Strategic Assessment. Most influences go forward from strategy to projects, but some influences go backward or sideways. Real Equipment. Why Pick On FPS?.

jerzy
Télécharger la présentation

Automating Requirements Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. AutomatingRequirements Analysis

  2. Organisational Layers Strategic Assessment Most influences go forward from strategy to projects, but some influences go backward or sideways Real Equipment

  3. Why Pick On FPS? An FPS is foundational – there is high value in getting it right, and having everyone read it the same way The language is formal and technical Altering a few words is much easier than rework of built equipment A requirement can be verifiable yet incorrect; … a requirement which has been overlooked. Mere analysis, inspection, or review alone will find some of these issues butgenerally is far weaker than usually is realized- Wikipedia

  4. 6 Pieces People can handle no more than six pieces of information in play at once

  5. Overload 6 Pieces We know what happens when a person is overloaded – they make mistakes Flying a helicopter is near the limit of what people can do – a mistake can cause an immediate crash Overloading a person with a new specification can cause a crash – it is just delayed a long time, so harder to see the cause

  6. We can bring in experts They can be familiar with what is old, but they have the same limit on what is new 6 Pieces

  7. We can build a model of it Building a model will build up familiarity, so what is new is reduced, but it will take a long time, so it doesn’t handle mistakes early in the process To keep the workload down, people filter out what they don’t think is necessary – but they have the same six pieces limit on working out what is necessary 6 Pieces

  8. Automated Requirements Analysis We are proposing the use of a system which takes the text of a plan or specification and turns it into a complete and accurate semantic working structure. 5. VEHICLE SUB-SYSTEM 5.1. Overview 5.1.1. The VSS shall comprise all SmartBus Equipment mounted on or installed in the SmartBus vehicle fleet. 5.1.2. A notional block diagram of the VSS is shown in Figure 3. The key VSS components are: a. Bus Controller. This Equipment processes inputs from the location sub-system, inputs and outputs from the communications sub-system and the on-board Electronic Ticketing Machine (ETM). The Bus Controller provides outputs to the driver console and also to optional on-board passenger information systems (both announcement and display). Apart from the processor, the Bus Controller comprises: (1) Location Sub-System. This includes the GPS receiver, odometer pulses and door sensor status (open or closed). (2) Bus Communications. This enables radio communications with the MSS. b. Driver console. This Equipment displays Trip information and on-time running performance to the driver.

  9. Documents as Machinery 3.2.4.3 Chapter 1, Space System Description. This chapter shall describe the space system and supporting facilities in sufficient detail to afford the reader a single source document of general system information. A brief narrative shall describe the purpose, main features and leading particulars for the space system as described below. Illustrations that clarify a particular system or reduce the verbiage necessary for explanation shall be included. 3.2.4.3.1 Description of the satellite. The description shall be of sufficient detail to provide an understanding of the purpose and function of the subsystems, their relation to overall system operation, and such additional information as to enable the crew member to understand subsystem functions peculiar to the satellite. Subsequent paragraphs shall describe in greater detail subsystems peculiar to that satellite. Such information shall include a general discussion of each major subsystem. • The goal is to have documents treated as just another piece of machinery. Then we can have tools to tell us about: • Things that are broken, not connected, or assembled the wrong way • A component not working properly • Something missing – not logically complete • Confusion from too many pieces in play • This is much easier to do on a realised working structure • because the structure does most of the work

  10. An Analogy We already have a tool that breaks the six pieces limit at the bottom of the planning hierarchy – what can we learn from that?

  11. Critical Path Method CPM – MAX and MIN People built amazingly complex structures before CPM, but no-one shows you the failures, or talks about the construction time Chartres

  12. Gantt Charts Before CPM there were Gantt Charts These helped a bit, by providing the scheduling problem with a visual interface But not enough, when there are hundreds of interlocking activities, and interlocking in ways other than time Visualising a complex problem works if it is all in one or two dimensions – whatever doesn’t fit is ignored

  13. Using CPM Using CPM, we can schedule projects with thousands of activities The machine stitches together all the activities into a network and analyses it We only need worry about the detail around each activity Simple CPM simplifies the problem a bit – sometimes too much

  14. CPM – MAX and MIN Can we do something like CPM with specifications and plans - get a machine to stitch it all together - but not simplify something that isn’t simple

  15. If we have done Project Management properly, and merged cost and risk with time, and provided for the interactions of activities to switch other activities on and off – if we have captured all the complexity, we are not too far away from language

  16. The Bad News • It is going to be a bit more difficult • A specification defines its own terms, it refers to itself and to other documents • It can talk about any technical thing • It can bring in objects, relations, groups, states, events, existence, as well as times and resources • It can be both broad concept and extremely detailed

  17. The Good News • A Function and Performance Specification is intended to: • Describe what is required, rather than how to do it • Be unambiguous • Be consistent • Be complete • Use “dumbed down” language – only the “shalls” count • Sometimes it is necessary to fall back on the freedom of natural language, because only it allows the seamless mixing of logic, groups, objects and relations. It may only take a few words, but those few words destroy the usefulness of any narrow, static approach (like tools with a fixed and limited subset).

  18. Consistent Evolution Relation In Text A secondary source shall supply system time Project Activity IF A + B = C THEN D + E = F A + B = C CPM – MAX and MIN We have come from CPM to the semantics of text, with the same technology

  19. Building Document Structures A large document may use a million small undirected elements in its structure. We can try to build these large complex structures by hand, but then we run into the six pieces limit, or we can build a machine which builds structures - just like a Jacquard loom, and for the same reason

  20. Self Extension We need a machine which uses an initial structure to read text, extends its structure as it does so, then uses that structure to read more text It is all made out of the same stuff – undirected structures can be seamlessly merged

  21. Some FPS Examples Tow Motor – 7 pages SmartBus – 74 pages

  22. Tow Motor At this level of complexity (not much), automated FPS analysis can show errors, inconsistencies, ambiguities, duplications, weak statements Too simple to be an adequate test

  23. Using The Structure The words here are building a group – “Instrumentation within the cabin”

  24. Slice And Dice The instrumentation within the cabin of the Tow Motor shall include a tachometer. AND The instrumentation within the cabin of the Tow Motor shall include an engine hour meter. ….. AND All instrumentation shall be back-lit and dimmable. Building a group Operating on a supergroup There is an approach to Requirements Management which consists of cutting the FPS into small pieces and putting them in a database, while the systems aspects – the connections among the pieces - are ignored. Text is much more subtle than a database can support

  25. Using Background Knowledge To Find Errors It looks like the FPS has a value for Turning Radius, when Turning Diameter was meant Turning Circle “contains” the turn relation of the vehicle

  26. SmartBus The SmartBus system is already a system of interacting subsystems, but the FPS is particularly dense and complex, as it was based on the performance of a commercial scale trial system We needed a complex FPS we could use as a test and talk about publicly. We came upon the FPS years after the project was completed. The Victorian Department of Transport has kindly permitted us to describe the results of automatic analysis.

  27. Technicalities • The FPS covers a wide range of technical issues: • Communications – Satellite, GPRS, Internet, RS232 • Electronic components – microprocessors, LEDs, LCDs • States - Any time delay between the last instance of the Door Closure event and the TOD event notionally represents “Unproductive Dwell At Stop with Door Closed” • Bits of a bus – engine ignition and coolant, braking equipment, doors, wheels, battery • Environment – standing in the sun, gravel bombardment, low hanging branches, wash systems, vandalism, arc welding near electronics • Environmental testing – Temperature, Vibration, Mechanical and Thermal Shock • It all seems daunting, until you see many of the same themes • repeating in other FPS

  28. FPS Contents The SmartBus FPS has the usual ingredients for an FPS of this size: A block of defined terms at the front, a glossary at the back, with other definitions scattered through the text Subsystems described in separate sections, with document references used for interlinking Use of indexed lists and tables It also has diagrams. Diagrams are not usually essential to an FPS, and the system can do a lot without knowing what they show.

  29. Local Dictionary The defined terms require a dictionary that expands as the text is read. The system starts with about 20,000 words, access to another 200,000 about which it knows little more than their parts of speech, and it has to accept new meanings, either for single or multiple words – “up” and “down” get additional meanings. Getting the definitions right is an important part of reading a large FPS. Given the forward references, it is a hard job in itself.

  30. Searching A search structure is created using free text, and it is then matched to the structure built from the specification or plan. These aren’t two different structures – the query structure is anchored in the structure built from the text to be searched, so common points are found during building of the query. Sets propagate through the structure – the structure “works”

  31. Structural Synonyms John omitted the data from the report The report omitted the data John didn’t include the data in the report John left the data out of the report John forgot to put the data in the report

  32. Automated Assistant A system to read complex documents and build their semantic structures allows people to concentrate on the problem areas without getting lost in the details – the six pieces limit is blown away

  33. Broadening the Application This presentation has been directed to one document, but once the structures are created, it is easy to analyse among document structures In any direction

  34. Suggestions • Make all the connections before beginning requirements analysis, so all possible influences can be seen • Accept that people have a limit on pieces of information in play – don’t fight it, work out how to get around it • Use inferences instead of statistics on something new • Don’t use computer logic – it throws away too much inferencing power • Use tools which maintain the systems aspects • Treat documents as machinery 6 Pieces

  35. Automating Requirements Analysis The things that make it hard to do are also the things that make it worth doing Interactive Engineering Pty Ltd www.inteng.com.au

More Related