In the set of documents above, I did not mention the User Requirements Specification. What is its role and where does it belong in the development life cycle? Well, where it belongs is easy enough: it's before the Functional Specification, as a precursor to it. And what is its relationship to the FS? This often translates into one of two questions: given that an FS is in preparation (or a decision in principle has been made to make an FS), is a URS required too, up front? and, having prepared a URS (or a document that can best be described as such), do we really need an FS as well? The answer in both cases is, "it depends". Before elaborating on that, what is a User Requirements Spec anyway? The URS expresses requirements from the user point of view (whether or not actually produced by the user organisation). They should cover functional requirements, of course, but will usually state may other kinds of requirement also. An important principle for the URS is that it allows the user organisation to express requirements freely, unconstrained by the formalities of the Functional Specification. The accent in the URS is on expressing needs or current problems. For instance, user requirement: "We need to be able to process more than one customer at a time, keeping one on hold"; or "We need to support several kinds of process, though only one is operational at a time". In the FS both these requirements could translate into may system-functional consequences. Of course there is nothing preventing the user organisation from writing down well thought-out, detailed functional requirements from the outset and these being sufficient as basis for designing and building the system. So, then there's no need for an FS. One should beware of drawing this conclusion too easily, however. Unless the development is small and low risk, a URS is unlikely to form sufficient basis. What about the other way round? If we know we are going to make an FS, do we need a URS also? Unless the requirements are clear and well-known up front, it is probably a good idea to have a URS preceding the FS. It establishes a good basis of (hopefully) clear requirements and helps the FS phase to set off on the right foot. Note that the lack of formality in a URS applies also to the contractual framework in as far as (assuming an FS is to be prepared) the URS should not be regarded as the contractually binding baseline for the system development - the FS will supersede it, certainly as far as functional requirements are concerned. The URS is of course a basis for the FS itself, but it would place undesirable demands on the document to regard it as a formal baseline.

In the context of the functional, black-box view of a system, with emphasis on the interfaces, the concept of an algorithm presents a potential problem. An algorithm is clearly a machine-internal thing: it is not visible on the outside. So what is its relationship with the visible behaviour? with the interfaces? In essence, the system receives input data [via the user interface, telemetric measurement points, messages from other systems via a communication line, fixed internal data etc.], processes this and generates output. So ultimately, the algorithm expresses a relationship between certain input data and certain output data. In a Yourdon-type transformation model, the algorithm can be seen as a particular transformation. So, although a system functions by virtue of its interfaces with the environment, in certain cases, the output is related to the input by a well-defined algorithm. This algorithm may be of legitimate concern for the FS.

A heavy reliance on calculations does not however necessarily mean that they are of concern for the FS. Take a Planetarium application: its functions can be quite clearly and fully described in a rather short document (if it is a simple Planetarium). The functional objective - to display stars and planets on a screen - is quite clear without specifying the required algorithms. Indeed, this is a good example of an application where algorithms almost certainly should not be specified up front; there may be different ways of doing it.

In the case of, say, a pipeline monitoring or simulation system, it may be that quite specific algorithms are to be implemented. We should also mention the simpler case of an 'algorithm': a screenful of data (a database application, typically) with, at the bottom, a calculated value based on a very specific calculation using the raw data. Naturally, the required algorithm is specified, though probably not visible to the user.

So, what makes the algorithm relevant or not for the FS? Well, primarily whether the client feels the need to specify it. Maybe also because it's the only practical way of describing the function.

But if we admit that an internal algorithm can be the legitimate concern of an FS, then we potentially open the floodgate! After all, virtually anything a computer does in executing its internal program to achieve its functional objectives can be considered to be an algorithm. So if we follow this route, we have the program code as the ultimate FS! (or, at least, a specification so detailed that it is directly translatable into program code). Nevertheless, the Planetarium example (and the human being analogy) clearly shows the distinction between functionality and design: the FS in this case is quite simple if one leaves it to the designer or programmer to work out how to achieve that functionality.

On the other hand, if we examine more closely why it is possible to take this approach in the case of the Planetarium, it is because we know that the functionality is based on generally available mathematical and astronomical principles - we demand the functionality knowing that it is possible; knowing, at least in principle, how to do it. So this contrasts with cases in which, although very probably the required knowledge exists (otherwise the system would not be demanded in the first place), it is not generally available, i.e. it is something which in particular the client knows about.

The simple FS for the Planetarium works because virtually anyone can understand what it means without having any idea at all how to achieve it. The most extreme case where specification of an algorithm appears desirable would be that in which the functionality cannot really be explained without it. Nevertheless, it seems doubtful whether a system should be conceived in which the functional essence is not clear.

In this context, the clearest and most practical way to define functionality is to recognise that the design (anything internal, including an algorithm) can potentially change whilst achieving the same functionality. In other words, we recognise that, at least in principle, we could do it a different way.

I therefore advocate a very clear distinction between functionality and design. Regarding algorithms, I recommend that, in the case of larger, prominent algorithms, whilst it may be desirable to specify the algorithm up front in some cases, i.e. to promote it to part of the contracted supply demanded by the client, it should be clearly recognised as such and should be kept separate from the rest of the specification. In any case, both client and supplier should exercise caution in this respect and only include such a specification in the contracted supply if very clearly justified. Otherwise, it becomes the classic problem of over-specification. In the case of smaller algorithms (e.g. the calculated value on a data screen), the algorithm should be integrated in the specification, however, in such a way that the functional purpose is first made clear and then the required algorithm clearly identified as such.

Sometimes, an FS may appear unusually detailed. Is this a sign that it has gone 'too far'? Or is it just a system with unusually detailed functionality? It's worth remembering, first of all, that any FS may make use of 'pseudo-code' to describe functional behaviour. And such code can get very detailed - or make the FS look very detailed. Can such code be translated directly into (fragments of) real program code? Probably, yes. So then we are equating it to an algorithm... we have already recognised that any internal code can be regarded as an algorithm.

But we have to ask ourselves, is the pseudocode really just describing the externally visible behaviour? (If it concerns a user interface, could the user see all the described behaviour?) If the answer is 'yes', we are describing functionality; functional behaviour. But this also illustrates that, inevitably, functional behaviour is in some sense modelled internally by the system; is reflected internally. Of course.

This then also illustrates that the distinction between functionality and design can to a certain extent be seen as a difference in the level of detail. Nevertheless, it should be clear which details are internal, i.e. could change without affecting the system function - and therefore should not be included in the FS.

Now certain systems, e.g. signalling and control, may have very detailed functional requirements which moreover lend themselves to formalisation, whereby this formalisation therefore lends itself in turn to direct translation into executable code - whether for simulation, prototyping or even real operational purposes. In such cases, there is a very close match between external functional model and internal model.

Against this background, we can pose again the question, how detailed should an FS be? The question here is, quite apart from the recognised distinction between functionality and design, can we say something about the required level of detail generally? Well, the main thing an FS should be is unambiguous. And it should be sufficiently detailed that the implementer can realise the system without constantly having to enquire about functional details or having to fill in such details himself; and sufficiently clear and detailed that the client or any objective observer can unambiguously verify, based on the FS, whether the system meets its functional objective. In principle, the FS should be fully detailed. But we should recognise that in most cases, generic descriptions are sufficient to cover many detailed variations. A good test in practice is to determine whether it is possible, based solely on the FS, to produce a detailed functional Test Specification.

Is the term 'generic specification' an oxymoron? Hopefully not! We should be able to be specific regarding a generic function. In the context of generic products or system kernels vis a vis an application built using such a product or kernel, this is important and levels of functionality are of interest too. Take a product such as Microsoft Word or Excel. They support general functionality for a wide range of tasks and are also programmable, enabling customisation and realisation of specific applications. (One can argue that the use of the basic spreadsheet functions of Excel constitutes a sort of programming in its own right.)

The main potential problem when using a product or kernel as basis for an application is that, because the underlying product supports the resulting system functionality directly or indirectly, we probably do not want our FS to include a complete specification of the underlying product. We would generally assume it is known, or given - seeing as a conscious decision has presumably been taken beforehand to use that particular product as basis. Clearly, the application functionality is constrained by the functionality of the product. So in practice, the application's functionality will be described largely in terms of the product functionality - preparing such an FS will require good knowledge of the product and its capabilities. The problem perhaps then arises of an unclear boundary between functionality of the application and functionality of the underlying product. Note, however, that even the operating system can be considered such a 'product', in as far as it provides visible functionality and affects the overall style - think, for instance, of a typical Windows program.

Note finally, that, at this 'higher level' of programming, there remains a distinction between functionality and design - 'behind' the visible result may be much that we need not bother with in the FS.

Through the last 20 years or so there have been various methodologies and techniques for system development in general and system (functional) specification in particular. I want here to briefly discuss the influence of such techniques on the FS. I have already alluded in this paper to the concept of a "functional design". Whether a graphical structuring of functionality is any more a "design" than the structuring implicit in a more conventional description is a moot point. If there is a problem with graphical techniques, it is (a) the question, is the functionality really any more clearly expressed by this means? and (b) such a technique looks like design rather than functionality. Over the years, I have found both of these to be real problems!

At the core of traditional techniques has been the 'data flow diagram'. Taking the Yourdon methodology as representative (at least for real-time systems), the data-flow diagram is there called a 'transformation schema'. This methodology distinguishes the "Essential Model" and the "Implementation Model", which can be considered to correspond to my split between functionality and design. The methodology makes clear distinction between the two types of model. However, in my experience, it is rare to see both models worked out. The Essential Model looks like a design, and, regarding 'data-flow diagrams', the same technique is used in both types of model. Inevitably, having made a transformation schema for the Essential Model, the prospect of repeating the exercise for the Implementation Model tended to confront system engineers with a daunting task. What exactly is the subtle difference in the Implementation Model? And if we can identify it, is it really worth the effort of a separate model? And this of course underlined the somewhat unclear distinction between functionality and design in this case.

Another characteristic of the Essential Model was the working out in levels. A system Context Diagram was worked out in a first level transformation schema; then each transformation in second level diagrams; and possibly a third level too. This process too obviously smacked of design. And as to whether the result really communicated a clear expression of functionality - perhaps it's a question of taste, but I never thought so; not really. And I remember some decidedly awkward discussions with suppliers, trying to convince them that they should view the specification as a conceptual model and it was not really dictating the design! I can tell you, the methodology seemed more trouble than it was worth, sometimes.

As already mentioned, nowadays an Object Oriented approach is more likely. As regards UML (Unified Modelling Language), I have a much better feeling about this on both counts. It provides a structured way of gathering functional requirements, that structure communicates well because it is based on recognisable objects in the application domain, and there is a natural distinction between functionality and design.

Whatever technique is used, there is no substitute for making sure the functionality is understood. Avoid the danger of believing or assuming the specification is good just because a 'good-looking' technique has been employed. It's remarkable how many people 'need' to see evidence of such a technique before a specification can be taken seriously. To a certain extent, it is true that suitable techniques ought to be employed in this day and age - not doing so may indicate indeed a lack of awareness or expertise. But doing so by no means guarantees success or quality. The specifier needs to be good at analysing the problem in functional terms, and then to express it appropriately. And it is important to understand that a model - any model - is just that: a model; an abstraction. That is, a representation of certain characteristics or properties using a technique conducive to expressing such characteristics in a graphic or other form. No model is perfect; no model represents the complete truth. That's why the specifier needs to be alive to the possibility of supplementing any model with textual explanations to clarify or fill in various aspects of the system functions. If extra text is provided, this must not be seen as a weakness in the model per se. It merely reflects the fact that no model is perfect or can represent all facets of a system in one or two diagrams.

What is the role of data specification in a functional specification? Some methodologies place much emphasis on the data and on data modelling. This is perhaps not surprising for database systems. But, following on from the previous section, one should beware at this stage of investing too much effort in detailed data modelling. The vital thing is that the system performs the functions it is supposed to perform. Of course those functions operate on data. It may however be worth considering making a simpler data model at the FS stage than may be required at the system design stage. What certainly is important is to realise that the (details of) system functionality will evolve during the specification activity. It simply is not realistic to expect that people will have it all in their heads at the outset and that preparation of the FS is just a question of writing it all down. In the course of analysis and formulation on paper, new insights or unforeseen complications will inevitably arise. The (draft) data model must be adaptable in a flexible way - it should evolve too. If every new functional detail requires exhaustive critical examination of the data model to see whether or how it can be accomodated, this greatly impedes progress and quality.

An object oriented approach may be helpful in this respect, because the natural tendency then is to identify the main players in terms of objects, and this will lead to fewer objects and a simpler model than will be the case with a more datacentric approach. To repeat, of course the data are important and of course a clear and consistent definition of the relevant data elements is necessary on a functional specification task. But it's a question of not taking it too far and resulting in a particular form of over-specification by defining details that can best be defined later.

For the Functional Specification, the important thing is to identify the entities that are directly relevant to the functional problem domain. This should be a relatively straightforward process. Some entities may be of an abstract nature but should be directly visible in the functional view of the system. What we do not want at this stage is to 'invent' those artificial entities that might later be found necessary for a formal model intended (for instance) as basis for the design of a relational database; that can be done later. Thus the functionally relevant entities must be identified and their attributes listed. Other characteristics may include data type (text, number or boolean being probably sufficient in most cases unless specific constraints are already known, e.g because it concerns data from another system) and a description of the functionally important relationships with other entities. These relationships should be described with a view to clarifying the functionality and not with technical formalities in mind - thus a 'many-to-many' (n:m) relationship is allowed at this stage. The only caveat (perhaps 'excusing' a more formal model) may be the need to ensure that the functional model is amenable to implementation without unwanted technical complications. Note two things in this regard, however: (a) when preparing a Functional Specification, it is always a good thing to look ahead and to ask oneself whether the specified functionality is feasible to implement technically; if any such assessment is committed to paper, this does not mean that it is to be included in the FS (it may be retained in the form of a technical note); and (b) the manipulation of data in a system does not necessarily have to be the sole domain of a database engine - certain operations, including checks on data integrity with regard for possibly complex relationships - can be carried out in the 'surrounding' program code. There is no law that says, just because a database product is to be employed, the database must therefore 'know about'  every functional aspect of the system.

This topic, finally, highlights another aspect of the FS (though in common with other stages of development) regarding project organisation. Part of the importance of data definitions lies in the intra-project communication: team members should, of course, share a common understanding of data elements, their specification and their meanings. However, a good organisation will have as little dependence on this as possible. Organisation in this respect should be like a good design: team functions should be defined to be as independent - loosely coupled - as possible. In terms of data elements, this means that (as far it can be foreseen) any two team members should have as little overlap as possible, that is, as few data elements as possible that are of common interest. This minimises confusion resulting from mis-comminication and reduces complications when, for instance, changes are introduced.

A few words about 'internal' functions and 'subsystems'. I should point out that a system can be whatever you want it to be - so long as its boundary or external interfaces can be completely and clearly defined. A subsystem is a system (just as a subdirectory is a directory). Everything I have said about system functions and their definition applies at whatever level a system is defined. (The contractual significance of a Functional Specification relates of course to the contracted supply.) At the upper end of the scale, a specified system may in practice be one of a number of systems intended to work together. In this case, it is worth noting that a design decision has already been taken when it is defined what systems will participate. At the other end of the scale, software modules have interfaces with other modules, which need to be defined. (Indeed, such interfaces are often referred to as 'contracts' between service supplier or server and its clients.) And in these days of object orientation, the interfaces are those belonging to classes or objects. Note at this level too, that the accent in the interface definition is on syntax; the semantics of the functions are expressed in the documented descriptions of the functions or of the class as a whole.

It is interesting to note in this context, and referring back to the discussion of algorithms, that the idea of the interface in contrast to the internal implementation is, at the level of software components, a very clear one for software engineers. A basic tenet of object orientation is the idea of offering services to other modules via well-defined interfaces with a clear objective of hiding implementation details from the 'user'. No one would disagree with this. Well, this is just another expression of the distinction between functionality and design.

In the foregoing, I have implicitly defined the word "system" to mean an "open system" - 'open' in the sense that it interacts with the surrounding environment. It is surely clear that a computer system that doesn't 'communicate' is not going to be much use to anyone. (The phrase "open system" is also used to mean a system that supports standardised, generic interfaces and hence ease and flexibility of communication, but that is not what I mean here.)

Nevertheless, it is interesting to note that in certain contexts, particularly mathematical, the word 'system' implies a closed system - one which is self-contained and does not interact with anything else (at least, not in any way that is relevant for study). The reason for such a definition is of course in order to set bounds. When mathematically modelling something, it is important to be able to define the components that interact with one another and which constitute a system. Such a system is amenable to study; any further interaction with the 'outside world' is an impermissible complication, undefined or else an extension of the system.

If we were to adopt this definition of a system, we would presumably have to include everything with which the computer interacts within our system - the computer would be just one component in the total system. This would seem a little problematical though, especially for a computer connected to the internet: we would need to include all other computers in the world that are connected to the internet!

It is instructive though to return to the idea of computer software as model of the application domain. Particularly when following an object-oriented approach, as well as  when algorithms play an important role, the idea of software as a model of a part of the surrounding environment becomes rather clear. The model as such is of course an internal thing, residing in the computer's memory. The behaviour of the model is then also internal. It seems, then, that we can talk about the behaviour of an internal model without reference to the outside world (except in initially defining the model). And we can consider calling the description of this total behaviour as the functionality of the system - or at least, the functionality of the model.

This really brings us back to the earlier discussion of algorithms. The degree to which it is feasible or useful to view the program code and data in the computer's memory as a (complete) functional model of the application domain will vary according to the type of application, as well as, possibly, the preferences or adopted approach of the developers. The fact clearly remains that communication with the environment is necessary for the computer system to be effective. But in the case of a system where this modelling concept is strongly developed, the communication with the environment can be seen as the model simply communicating its own behaviour such that it is reflected in external elements (corresponding to elements of the model). In other words, the behaviour of the internal model can be seen to have a certain completeness or wholeness in its own right, irrespective of its communication with the outside world.

Such a view may be useful in clarifying the functional model and separating it from the issue of external interfaces. The clearest context for the application of such a principle is the system whose purpose is primarily to control external hardware elements, especially where a high degree of precision and reliability is required. A clear example is the railway signalling system responsible for setting routes and controlling signals and points. Here, the track layout and signalling elements will be clearly modelled in the system software and the behaviour of the model will very directly reflect the required behaviour of the external elements.

Is the foregoing discussion about external system behaviour irrelevant for or disproved by such a case? Not really. The external view should be used as a check on the scope of the model and the relevance of all its elements - that is, to avoid the temptation of modelling things that are not relevant or necessary. Furthermore, one should be alive to the danger in such an approach of allowing the model to become a law unto itself and thus forgetting to verify that the model is in fact correct. And where complex models arise, verification can form a significant issue.