Reusing the Products of Analysis

In the field of programming we have been identifying and reusing patterns for many years. Programmers save time by using the same algorithms, general data structures and programming language specific idioms over and over again. In the case of requirements analysis we don't take advantage of reuse. We duplicate a lot of work by starting each project as if it is unique. This is because traditional approaches to requirements analysis are too imprecise to uncover similar patterns between different business areas.

The last 10 years have seen major improvements in the way that we specify requirements. Improved specification methods make it possible to start development of a system by reusing analysis patterns from other projects. We have found that this "start by reusing" approach results in significant time savings and improvement in the quality of the analysis. This article gives examples of how a number of project teams have reused the products of analysis and discusses future possibilities for reuse over wider boundaries.

Keywords

Reuse, requirements analysis, analysis patterns.

Patterns in Analysis

An analysis pattern is any part of a requirements specification that originates in one project and can be reused in one or more other projects. Analysis projects start slowly because the analyst begins with a clean sheet of paper. But suppose that the analyst begins with a collection of potentially reusable analysis products. Think of it as an analysis pattern book. Now the requirements gathering interviews can be conducted not so much as "tell me all about your system", as "let's look for the patterns which are the best fit with what you do here".

This idea has already been implemented in other fields of knowledge. One notable example is the book "A Pattern Language" by Christopher Alexander and five other architects. The architects spent 9 years observing, researching and defining the most desirable characteristics of components of living spaces. The book contains 250 understandable, hence reusable, patterns for various aspects of living spaces ranging from a bedroom to a window seat. The book provides the knowledge for anyone to make a design for almost any kind of building, by reusing the appropriate patterns.

As the architects have illustrated, the work of defining, recognising, and reusing patterns takes time. First there is all the work of defining the best language for the subject matter. Next is the task of gathering potentially useful patterns. And then there must be a culture that makes reuse desirable and effective. Systems requirements analysis has made some progress in each of these areas. The first step is to agree on a way of expressing requirements.

During the last two decades a great deal of work has been done in the development of effective requirements definition languages. Modelling techniques such as structured analysis, essential systems analysis, information modelling and joint application development have been tested and refined on many projects. Today, instead of writing a free-form, text-based specification, (or spending time inventing a new way of writing requirements) competent analysts use some kind of recognised modelling technique to provide a common communication language.

Modelling languages provide a consistent way of defining requirements. Now each new requirement can be examined for its reusability potential. We have discovered that the skill most necessary for identifying reusable requirements patterns is the ability to abstract. As well as a communication language and abstraction skills analysis reuse also needs the right infrastructure. Historically, our systems development culture focuses on implementation and measures success based on how many lines of code are produced. A culture that supports analysis reuse is one that focuses on abstraction skills and measures success based on how many requirements components are reused. So there are some cultural changes necessary in order to take advantage of analysis reuse.

The projects that we have worked with have made some progress in defining, recognising and reusing the products of requirements analysis. The next sections describe the experiences of those projects.

First Abstraction - Patterns Within A Project

It's easy to fall into the trap of repeating work because, on the surface, most tasks look different. Topdanmark, a Danish insurance company, has a large and busy systems development department. The work of the department ranges from making changes to development of new systems for new areas of business. Some of the older systems are being redeveloped to take advantage of new technology. The company suspected that there is a great deal of overlapping business knowledge between different insurance systems. If they could identify and define potentially overlapping knowledge then they could save time by reusing that knowledge when building new systems. The company decided to concentrate on identifying potentially reusable business requirements knowledge.

The first project to use this thinking was building a system for insuring cars, houses and contents of houses. This was known as the private insurance system. The analysts and users, a team of 8 people, started by building separate requirements models for cars, houses and contents. At the beginning, the products all seemed to be quite different and nobody had the knowledge to see the similarities. After a while, however, the team members brought the three models together and reviewed them. They consciously looked for similarities between them. They had conversations like: "insuring a house against flooding is much the same as insuring a car against being stolen. It's true that the prices, dates and conditions are different, but the concepts are the same".

Comparisons of the models caused many heated discussions about the details. But one thing was agreed. In spite of all the differences between the different kinds of insurance, there were more similarities than anyone had expected. And if those similarities could be extracted there was potential for creating some generic type of insurance model which could cover all types of insurance - at least within their own context. The first step towards making the abstraction was realising that it was possible and useful.

The next step in trapping and defining the emerging pattern was to agree on terminology and representation. If insuring cars, houses and contents is similar then what shall we call the thing we're insuring? A number of new terms had to be invented and agreed before the effort could go further. Reaching agreement on which terms to use was surprisingly difficult. However, spending the time to have all the discussions proved invaluable in the long term because once a term was agreed everyone started using it and everyone knew its meaning.

Models, like the ones in figure 1, of specific types of insurance gave us a starting point for our discussions. In the insurance business different types of things like buildings, cars, cranes, antennas, contracts etc. can be insured against different kinds of damages like theft, fire, floods and so on:

Types of Insurance

Figure 1 Each model specifically defines the rules for insuring a particular type of thing with a particular type of coverage.

After building and reviewing models of a few of these valid combinations started to see how the concept could be generalised. If the types of things which are insured are called ASSET TYPES, the types of damages are called COVERAGE TYPES and the valid combinations are called ASSET COVERAGES then a pattern like this emerges:

Figure 2 This generic model covers all valid business combinations of Asset Types and related Coverage Types. Every Asset can have an Asset Coverage connection with many types of Coverage. And every type of Coverage could be connected via an Asset Coverage relationship to many types of Assets.

The discovery of the generic ASSET, COVERAGE and ASSET COVERAGE triggered other insights. For instance whenever the insurance specialists design a new product for sale, they ask the systems developers to add the product to the existing computer systems. This involves a lot of work as each new product is thought of as a new combination of new components. So time is spent in analysing all the details of the new product, and adding them to the system. Now, instead of seeing a new product as a brand new set of components, the analysts could see that it is a combination of asset coverages. An asset coverage, remember, had already been defined as the rules for giving a particular type of asset a particular type of coverage. Every time the insurance specialists design a new product, they are defining the selling conditions for a combination of asset coverages.

The experts agreed that the model in figure 3 defines the pattern that they follow.

Figure 3 A generic model for the concept of a Product. A Product is a collection of Asset Coverages which are sold as a package.

The definition of these requirements patterns meant that they could be reused by both the insurance experts and the systems developers. The systems developers use the patterns to build a system which reflects the requirements patterns. So the computer system contains identifiable ASSETS, COVERAGES, ASSET COVERAGES and PRODUCTS. The system is built so that the users can add new instances of these business components. The insurance experts can define new products using any combination of asset coverages. A new idea for selling insurance can be implemented by the insurers without necessitating any changes to programs.

The requirements patterns defined in the private insurance project helped that project group to capture knowledge for a business oriented system. If requirements patterns could be reused within one insurance project, we wondered whether the same patterns could be reused by other projects within the Topdanmark company.

Second Abstraction - Patterns Within An Organisation

The life insurance analysts were about to start a new project and they agreed to see whether they could use any of the requirements patterns that the private insurance project had discovered.

To start with we came up against some barriers because life insurance specialists, naturally enough, view life insurance as something totally different from private insurance. Someone who specialises in a business area sees it as quite different from any other business area in the same organisation. And so it is from the point of view of the details. However from a more abstract point of view there are usually similarities. Our challenge was to help the life insurance specialists recognise similarities between their world and the requirements patterns derived from the first project.

We started by defining the context of the life insurance project. Then, working with the life insurance team, we compared the context data with each of the private insurance requirements patterns looking for similarities.

The team worked together in room lined with whiteboards. After 3 days and copious quantities of coffee and Danish pastries we had a great success. By renaming some of the components on the private insurance models it was possible to reuse large parts of the models. For instance the life insurance analysts realised that an ASSET in the private insurance system is the equivalent to a PERSON in the life insurance system. And ASSET-COVERAGE in the public system is the equivalent of LIFE-COVERAGE in the world of life insurance. Once these patterns were recognised the detailed definition work done by the private insurance project could be reused, with some modifications, by the life project. And a great deal of time was saved. The reuse of the requirements patterns meant that the life insurance analysts only spent three days to produce the same amount of work that had taken the private insurance people six months:

Figure 4 Project 1 did the pioneering work by producing understandable analysis models. Project 2 reused this analysis, hence their preliminary analysis was completed much more quickly.

It should be noted that the productivity difference between the analysis of the life insurance and that of the private insurance had nothing to do with differences in individual skills. The private insurance analysts discovered the patterns while the life insurance analysts used the patterns. Discovering is a lot harder than using.

The time savings are very impressive but they are only a small part of the potential savings. The longer term savings come as developers of other systems start to reuse the same requirements patterns. The computer systems will start looking more similar which in turn will have a great impact on the maintenance. It will be much easier for people from different groups to understand what the other groups are doing and it will be easier to reallocate resources. The patterns create a common way for an organisation to view the world.

The first two abstractions give examples of the pattern recognition and reuse taking place within an organisation. The next two abstractions are a natural extension. The use of a common language means that we could extend the idea of reuse so that organisations in the same field of knowledge can share patterns. The next level of abstraction would ignore subject-matter boundaries and identify generic, subject-matter independent, reusable patterns.

Third Abstraction - Patterns Within A Field of Knowledge

Right now, an insurance company in Indonesia is developing an insurance system. Another company in Australia is writing an insurance system. In Buenos Aires they are working on insurance and a firm in London is developing yet another system for insuring.

The curious thing is that each of these insurance companies, and many others all over the world, are going through the same time-consuming and money-eating procedure of specifying each system from scratch. This is especially wasteful when you consider that large portions of that system have already been specified many times before. One reason that the Indonesians, Australians, Argentineans and English cannot take advantage of previous analysis work is lack of a common specification language.

Another more serious reason is that the builders of one insurance system consider their system totally different from that of other organisations building insurance systems. This is a world-wide problem within the systems development profession. Our, "not invented here", culture does not encourage the identification and reuse of requirements patterns within a field of knowledge.

Suppose that you have already built a computer system for an insurance company. At this stage you know all the rules contained in your system for creating new policies, reviewing policies, producing reminder letters, reports and so on. You also know about the design of your database, your programs, your user interface and the telecommunications network. The system that you have built is specific to the requirements of a particular organisation.

Now suppose that you have the task of building another insurance system for a different company. This company uses different hardware and software and the way they do business is different. But, not surprisingly, some of the insurance related knowledge that you learnt when building the first system is also relevant to the second company's requirements. This thinking is very similar to the thinking used by the Topdanmark life insurance analysts when they identified similarities between their project and the private insurance project. However there is one big difference. The abstraction is at a higher level and consequently more difficult for company specialists to see. In addition to ignoring boundaries between projects, we are also ignoring boundaries between organisations.

By abstracting one system's business requirements, ignoring details which are applicable only to the way the system happens to be implemented, and deleting anything which is specific to the particular type of insurance or type of company, you can reveal a pattern which is general enough to be the starting point for all types of insurance. For example, all insurance policies have to be renewed. Although there some details of the renewal which are applicable only to specific types of insurance or specific companies, there are also parts of the renewal process which would apply regardless of what sort of policy is being renewed. Figure 5 illustrates the requirements pattern for a generic policy renewal. These generic requirements, once defined, could be reused by any company wishing to build an insurance system. However, in order to reuse the requirements, two things must be done. First comes the work of discovering and defining the patterns. Then companies have to agree that it is to their advantage to share their generic requirements patterns with other organisations

Figure 5 There are some characteristics of a policy renewal that exist independent of the type of insurance being renewed. We could use this pattern as the starting point for a health, home, car, bicycle or any other type of insurance policy renewal.

Some organisations feel that they are sacrificing a competitive advantage if they share analysis knowledge with other organisations in the same field. However, other fields have proved that the real competitive advantage comes not from the requirements knowledge but from the particular way that the requirement is implemented. For instance, any musician can go to a music publisher and buy a copy of the music for Elgar's cello concerto, so the knowledge of the notes to be played is available to anyone who wants it. However it is the way that the concerto is played which makes a listener prefer one musician's performance to another. Lots of computer companies use the Intel 486 chip in their products. Yet two different products can look and behave very differently. The requirements for a spreadsheet are implemented by many builders of software products. But it's the way that those requirements are implemented and our perception of the company that we are dealing with that makes us choose one above the other. Providing the basic business problem is being solved, most of our preferences stem from the way that we are treated by an organisation. Once the subject matter is formally defined an organisation has more time to concentrate on human skills, the thing that really creates the difference.

Suppose our insurance company had access to a knowledgebase containing insurance requirements patterns. The patterns, a formal definition of the subject matter, could be the input to a project. The 6 months taken to analyse the requirements for the new system. could be spent on working out competitive ways of implementing them. And they would be implemented more quickly.

The less we consider physical boundaries: inter project, intra project, inter organisation, the more concentrated our requirements patterns become. In our first abstraction we thought past the differences between components of a project. Our second led us to a concentrated view of the knowledge within an organisation. An abstraction which focuses on subject matter regardless of inter organisational boundaries has provided us with a third level of abstraction. It is useful to go further and abstract past differences in subject matter.

Fourth Abstraction - Patterns Between Fields of Knowledge

In his book, Gödel, Escher, Bach, Douglas Hofstadter [see Hofstadter] illustrates how subjects that seem dissimilar on the surface can be shown to have many identical underlying patterns. Using this thinking, any specific subject can be abstracted to reveal potential similarities or patterns.

At first glance it is difficult to see similarities between the fields of health insurance and oil exploration. However, if one abstracts away from specific subject matter like oil wells and broken legs there are many things that the two fields have in common. For instance oil well leases have to be renewed and so do health insurance policies. So, for that matter do library books, fishing licenses, airline routing agreements, satellite broadcasting agreements and subscriptions to the fruit of the month club. If you compare the renewal rules you will find differences that are specific to the field in question. But you will also discover a pattern which is the same in each case.

You can tell that Figure 6.1 specifies the requirements for the renewal of a library book . The names of the processes and data make the analysis specific to a given type of subject matter. Similarly, Figure 6.2 is concerned with the requirements for renewing satellite broadcasting licences. Even though the subject matter of these two systems is very different, the two models expose some startling similarities. When someone wants to extend a library loan, the request is reviewed against the loan history. Similarly, the other model shows us that a broadcasting licence request is reviewed against broadcasting history. Sounds as if there are some rules about renewals which compare a request with past performance and either refuse the renewal or conditionally accept it. This sort of thinking results in Figure 6.3, the requirements pattern for renewing anything.

Figure 6.1 The requirements for renewing a library loan

Figure 6.2 Broadcasting Licence renewal is interested in different subject matter

Figure 6.3 This abstraction from the two subject matter specific models ignores subject-matter boundaries and focuses on the requirements for renewing anything.

You could use this generic requirements pattern as the starting for building a system to renew computer rentals, home loans, airline landing rights or anything else that needs renewing. The analyst would then add the policy and data that are specific to that field of knowledge in that organisation within that project.

Classifying Requirements Patterns

We have examined four levels of analysis abstraction and each abstraction focuses on knowledge patterns which are particular to that level. It helps to think about the different levels of abstraction by using the object-oriented paradigm to express them as a hierarchy of classes where lower levels inherit the higher level policy. Our requirements classification hierarchy is concerned with classes of requirements patterns at various levels of abstraction. If we reuse these requirements patterns we avoid repeating analysis work.

We have arranged our requirements hierarchy into four levels. Our fourth level of abstraction is at the highest level of the hierarchy. This level ignores project, organisational, and subject-matter boundaries. It focuses on knowledge particular to a domain. The third abstraction level inherits knowledge from the domain level and adds knowledge particular to a specific field. Similarly the second abstraction inherits all the knowledge from the domain and field level and adds knowledge specific to an organisation. Finally the first abstraction, being at the bottom of the inheritance path, inherits knowledge from all the other levels and adds knowledge specific to a particular project.

Figure 7 Projects X and Y have inherited the same policy for rare manuscript loan renewal. Tracing through the inheritance tree the projects have also inherited policy that is common to library loan renewals and renewals. Project Y has also inherited policy that is specific to fiction renewals.

An example of requirements inheritance patterns is illustrated in Figure 7. The requirements classification hierarchy is an inventory of patterns at 4 level of abstraction. The domain level of abstraction captures knowledge at a level that is independent of projects, or specific subject matter. At the subject-matter level of abstraction the patterns contain details specific to a particular field of knowledge. The next level of abstraction, the specialised-subject level, includes details specific to a detailed view of a subject. And at the project level of abstraction each of the patterns contains details specific to a given project.

Each level of our classification hierarchy is linked to the levels above and below.

In our example the domain level is RENEWAL and it contains all the knowledge that is common to any type of renewal. In the next level down, the subject matter level, the LIBRARY LOAN RENEWAL, INSURANCE POLICY RENEWAL and MAGAZINE SUBSCRIPTION RENEWAL inherit all the domain knowledge about renewals. Then each subject-matter area, adds knowledge specific to itself. For example library renewals, adds knowledge that is specific to renewing in a library system. Going further down the tree to the specialised-subject level, suppose we are looking at a system that deals with RARE MANUSCRIPT RENEWALS. Then the specialised-subject level inherits all the knowledge about the library renewals and adds its own knowledge specific to rare manuscripts. At the bottom of the tree, PROJECT X inherits all the knowledge on the path we have followed and adds any extras that are specific to the way that this project deals with rare manuscript renewal.

Requirements inheritance patterns provide a way of categorising requirements patterns at different levels of abstraction. Requirements patterns expressed in this way provide an accessible path into a requirements pattern knowledgebase. If we are going to do a project for renewing rare manuscripts then we will reuse the requirements at the specialised subject level. However. if we are planning to build a library loan renewal system for compact disks and video tape then we will reuse the requirements at the subject-matter level. Of course each new project potentially discovers new requirements patterns which must then be added to the hierarchy. By formally expressing analysis knowledge in this way, we would be easily able to reuse well tested knowledge collected from many different fields. The next sections explain our progress and future plans on the road to requirements analysis reuse.

Mechanisms for analysis reuse

Given that there are all sorts of advantages in pursuing the idea of analysis patterns, the next question is "how do we quantify them?" Here are the measurables that we are using at Topdanmark to identify patterns:

Entities within the context of the project
Relationships between the entities
Groups of entities and relationships
Events to which the project must respond
Behaviour patterns between processors

Identification of the entities and relationships within a context of study captures the overall flavour of the business policy. As in the case of the life insurance project, a data model from one project in an organisation can provide a starting pattern for another project. Sometimes two projects will be interested in the same data for completely different reasons. In this case only the high level definition of the entities will be reusable. The more the contexts of two projects overlap, the more the detailed definition of data content and relationships will be reusable.

Identification of a system's event responses captures knowledge about the processes and dependencies between the processes. We use existing context diagrams and event lists as starting patterns for new projects.

Definition of a system's behaviour pattern focuses on environment rather than subject matter. A well designed behaviour pattern between say a user and an interactive computer can be reused in a similar environment regardless of the subject matter of the system. Synchronisation models and prototypes are the vehicles that we use to capture and communicate behaviour patterns.

Figure 8 This modelling language is used to specify requirements. The same language is used to identify and communicate reusable patterns.

We work with an up-to-date version of systems analysis modelling that links process, information, event response and behavioural modelling. The modelling components, that also provide pattern recognition facilities, are illustrated in Figure 8 The technique combines the ideas of DeMarco, McMenamin and Palmer, Chen, and Robertson (See bibliography for references). The examples in this paper use this modelling language.

In Figure 9 you can see how our internal consultants work with the project groups. When a new project starts, there is a formal activity called project blastoff. The objective of project blastoff is to do enough preliminary analysis to set the boundaries of the project, see if there are any known patterns. The knowledge about patterns has been gathered from previous projects. This knowledge is used to help start the project and to set initial estimates. The important point is that part of the project blastoff is to identify which existing patterns can be reused by the project. During analysis, any new patterns that are discovered are added to the analysis pattern book.

Figure 9 During project blastoff, internal consultants help new projects to reuse existing analysis patterns. When detailed analysis is being done the consultants attend reviews and identify new analysis patterns.

We have already had some success with the approach we are taking. First of all, the internal consultants are getting more and more requests for help from other groups. The company's culture is becoming more receptive to the idea of reusing requirements analysis patterns. Another positive side effect of our work with patterns is that it has improved our communication with users. Analysis is a time consuming activity but the fact that patterns speed it up so much has encouraged more of the relevant people to contribute to requirements specifications.

Towards The Requirements Pattern Book

Visualise yourself at the start of a project. Before you do any detailed analysis you go to the requirements pattern book. Laid out before you is all the analysis that has already been done on projects similar to yours. You browse through the book looking at patterns for entities, relationships, events, contexts and behaviour patterns. You choose a number of patterns to use in your project. Some of the patterns you use in their current form, some you change to suit your special requirements.

In order to make the requirements pattern book a reality several things must happen. The patterns must be recorded using some common language that spans the culture of all the pattern users. The patterns must be organised using some readily accessible medium. The pattern book must be kept up to date. Our long term plan for making the pattern book a reality is:

Design a detailed classification scheme for types of patterns
Analyse expert system pattern interface for analysts
Design expert system pattern interface, probably using a combination of
expert system shell, CASE tool repository and Smalltalk
Design a pattern collection procedure to be followed by all projects
Design a pattern reuse procedure to be followed by all projects
Design a scheme to encourage and enable other organisations to participate in the pattern book project

The work we have already done has made a start on some of these tasks. However this is a multi-year project.

The analysis language that we are using expresses the patterns as entity relationship diagrams, context diagrams, event lists, event response models, implementation maps, transaction synchronisation models and data definitions. At the moment, our requirements pattern book is a collection of these components culled from a number of projects. We have used a CASE tool to record these patterns. A group of internal consultants are responsible for maintaining and communicating this requirements pattern book.

Our current expert system interface is in the guise of internal consultants. The consultants are involved in all project blastoffs. This experience helps them build up pattern recognition skills and they become pattern gurus for the organisation. So for the moment, the index to our pattern book is exclusively in human form.

Our next step is to examine ways that we could make the patterns accessible to a wider range of people by automating some of the consultants' knowledge. We are considering the idea of building an expert system to catalogue and cross reference the analysis patterns. At present we are working on a classification of all the components that we wish to catalogue. To do this, we are analysing the expert knowledge applied by the consultants when they identify potentially reusable patterns. We have identified two classification schemes.

The consultants recognise events, processes, data and behaviour patterns by their relationship to a business subject-matter area. For instance, if the new system is concerned with health insurance claims then the consultant looks for patterns in parts of previous systems dealing with claims. The other classification scheme is topological. There are certain shapes that frequently occur in analysis specifications. The experienced eye can recognise these shapes as potentially reusable patterns. Our analysis is concerned with quantifying both of these classification schemes so that we can use them as an index to our pattern book. The ideal conclusion to all this would be to integrate our expert index as the front end of a CASE tool. Each pattern and each component of each pattern will be defined as a separate object so that we can take advantage of requirements reuse at a number of different levels of abstraction as defined in figure 7. The lowest level would be reuse of a component, for instance a process specification, within a project. Reuse at the highest, or domain, level would be concerned with reusing all the patterns inherited by that domain.

One essential element is the ability to take an abstract view of known subject matter. We are spending a great deal of time in teaching and encouraging analysts to improve this skill. Formal reviews of the analysis, apart from their usual purpose of trapping defects, are also used as a forum for encouraging abstraction and identification of requirements patterns. Another key factor in being successful with reuse is to have reuse of analysis as one of the stated goals of the project.

Conclusion

We have already seen many signs of success with our use of patterns:

Projects get started very quickly now because of the use of patterns as a starting point during project blastoffs.
Using patterns as guidelines for the analysis activities helps to avoid a lot of unproductive discussions about partitioning themes and techniques and focuses concentration on the business problems.
The analysis is more rapid because the work which is reflected in the patterns is not repeated.

A positive side effect of our work with patterns is that it has improved our communication with users. Analysis is a time-consuming activity but the fact that patterns speed it up so much has created an interest among people who have previously been rather sceptical. We have actually heard some users saying that this type of analysis doesn't belong in the DP department. The users can understand the analysis and are keen to move the responsibility for business policy decisions into the user area where it belongs.

Another encouraging factor is that the internal consultants are getting more requests for help from new project groups. News of the successes is spreading round the company and more and more analysts are becoming aware of the benefits of using analysis patterns. We have taken the first step towards changing our culture to accept the idea of requirements analysis as a reusable commodity.

References

Alexander C. A Pattern Language. Oxford University Press. New York 1977.

Bohm C. and G. Jacopini. Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules. Communications of the ACM Vol. 9, No. 5, May 1966.

Chen, P.P. Proceedings of the International Conference on Entity Relationship Approach to Systems Analysis and Design. Los Angeles, 1979.

DeMarco T. Structured Analysis and System Specification. Prentice-Hall. NJ, 1978.

Dijkstra E. Programming Considered as a Human Activity Proceedings of the 1965 IFIP Congress

__________The Humble Programmer. CACM Vol. 15, No. 10 (Oct. 1972)

Flavin M. Fundamentals of Information Modelling. Prentice-Hall. NJ, 1981.

Gilb T. Principles of Software Engineering Management. Addison-Wesley. Reading, Mass. 1988.

Hofstadter Douglas R.Godel, Escher, Bach: An Eternal Golden Braid. Penguin Books Ltd. England, 1980.

Maiden Neil A.. and Alastair G. Sutcliffe. Exploiting Reusable Specifications Through Analogy. Communications of the ACM April 1992.

McMenamin S. and J. Palmer. Essential Systems Analysis .Prentice-Hall. Englewood Cliffs, NJ, 1984.

Robertson, J. and S. The Use of Transaction Synchronisation Models to Design Interactive Systems. The Atlantic Systems Guild, London. 1988.

Robertson, J. and S. Complete Systems Analysis Dorset House New York 1994.

Rock-Evans, R. Analysis Within the Systems Development Lifecycle. Pergamon Infotech. Maidenhead, Berks., England, 1987.

Schlaer S. and S. Mellor. Object Oriented Systems Analysis. Prentice-Hall. Englewood Cliffs, NJ, 1988.

Stevens W. P., G. J. Myers and L. L. Constantine. Structured Design. IBM Systems Journal, 13, 2, 115-139 1974.

Tsichritzis D.C. and F.H. Lochovsky. Data Models. Prentice-Hall, Englewood Cliffs, NJ. 1982.

About the Authors:

SUZANNE ROBERTSON is a principal of the Atlantic Systems Guild a London and New York based software engineering research company. Her research interests include analysis reuse, object oriented analysis and design and human factors in systems engineering. Contact details: The Atlantic Systems Guild Ltd., 11 St Mary's Terrace, London W2 1SU. Email: suzanne@systemsguild.com

KENNETH STRUNCH is a senior consultant with Topdanmark. He is involved in the practical application of analysis reuse techniques and the research for developing and implementing a requirements pattern book. Contact details: Topdanmark, Borupvang 4, 2750 Ballerup, Denmark.

top of page