The goal of this step in the MASSIVE method is to identify what the target system should do. We should therefore try not think in terms of "agents" or "goals" because this could too easily restrict our view for other possible solutions. Ideally, the result of this step in the method should be the basis for the decision of the designer whether a multiagent approach is the best solution for the given problem or not.
Agents are kinds of abstractions that should be viewed in a broader context then just under a functional point-of-view. The functional abstractions that are modeled in this step can spread over several agents and multiple functional abstractions can be encapsulated in a single agent. These decisions, however, are not the subject of this view that only models the basic requirements of the target system.
Requirements analysis is a difficult task, mainly because of the communication gap between developers and users. In the next section, I will therefore introduce a technique that was developed to bridge this gap.
topUse Case Analysis or Use Case Modeling is a powerful tool to capture the system requirements from the point of view of the people that will use the system after or during it is developed. But even for systems with limited user interaction, use case analysis can be a valuable means to describe the intended behavior of the system. In the latter case, however, the name "use case" is somewhat misleading and can be replaced by a more neutral term such as "scenario".
Basically, each use case is a very high-level description of what the system is supposed to do. It is never a means of describing how the intended behavior can be achieved! Therefore, use cases are not a functional decomposition of the system but rather a decomposition of system behavior from the users perspective that can subsequently be refined into a functional specification of the system behavior
In the first step of the above Process model, the end-users of the system to be developed are identified and separated into user groups. Then, the interaction patterns with the system are described for each of these user groups, leading to an initial set of use cases. Each of these initial use case is then informally described first in its normal course of operation and second in alternative paths according to exceptional situations that may occur. The informal description should ideally follow and easy scheme such as "The user does X, the system does Y. Then the user does Z, the system does ...". Again, the designer must be careful in order not to specify how a particular system reaction should be provided. After the use cases have been specified in an initial description, the designer should try to identify commonalities between case and eliminate them by generating an extra case that is jointly used by the others. Similarly, the designer should try to identify <<extends>> relation between two cases where one of them is an extension of the other. The entire process is then iterated several times until the collection of use cases becomes sufficiently stable. In can also be repeated in the course of the development process as soon as new requirements are identified or when the details of previously unspecified use cases become obvious.
Functional requirements are a specification of what the system should do. To obtain a first sketch of the functional requirements, it is often useful to analyze the intended workflow in the broadest sense. To this end, he designer can use the specification of the organizational context that was discussed in Society view. The result of this analysis should be an abstract definition of the input and output of the system and allow for a precise description of the system task(s). A potential problem that arises in this context is that many multiagent system as continuous systems, i.e. systems that doe not simply transform input data to output data but that continously act upon their environment. A solution of this problem is to break down the continuous operation into episodes that are defined in terms of the state of the environment before and after a particular operation. Therefore, even continuous systems can be described by a functional approach.
A tool for the functional decomposition of the problem to be solved are task trees that capture the fundamental functional aspects of the problem domain. A task tree for a given problem is constructed by decomposing the overall system task into several sub-tasks that are themselves decomposed until a sufficiently low level of detail. Note that I avoid to talk of "goals" in this respect for the reasons explained above. The concept of a goal implies the existence of some entity that pursues the goal and thus leads to an "agent-oriented view" that I wish to avoid in this early phase through the back-door.
The construction of the task tree follows the general idea of a hierarchical decomposition according to functional aspects of the problem domain. The granularity of the decomposition process depends on the specific problem but it should not become a specification of a particular algorithm. The task tree only provides a general picture of the activities that will be present in the target system, individual algorithms are designed later. The functional decomposition of tasks can be supported by the use of Structured Analysis introduced by Tom DeMarco in the late 1970's or related methods.
From the task decomposition captured by the task tree, the next step is to derive a mathematical formalizationof the problem domain. Mathematical formalizations are an extremely valuable tool in studying and describing the transformations performed by any software system and should be used whenever possible. To obtain an initial formalization of the problem domain, the entities of the domain are defined as precisely as possible while abstracting away from unnecessary details. Then, the functional transformations (tasks) are expressed in terms of these basic entities. However, this initial formalization of the desired functional behavior is usually not complete nor is it detailed enough to allow for an immediate implementation of the system. Therefore, the model will go through a refinement process. To achieve a complete model of the desired behavior, several iterations of the entire modeling process are likely to be necessary because the complete model needs input from the other views as well as user feedback.
Besides the functional modeling of the behavior of the target system, it is also important to quantify functional properties of the output (in the most general sense) of the system. Quantification means that the designer -- ideally together with the user -- must identify qualitative features of the solution that can be quantified by defining appropriate measures to decide that a solution generated by the systems satisfies particular requirements. Identifying the features that determine the quality of a solution and defined measures for these features is sometimes very difficult and should be done in close collaboration with the user to avoid the risk of designing a system that does not capture the users intention. This holds especially true in the case of optimization problems.
One of the most important rules for the functional modeling of the target system is to avoid any kind of control flow specifications. In this view, it is not important -- sometimes even harmful -- to think about how something has to be done. The goal of this view is solely to specify what is to be done. Furthermore, it should always be kept in mind that a complete functional specification is not possible in the first iteration and consequently, the initial design should not be overloaded by modeling features that show to be of less importance during the course of modeling the other views onto the system. However, although the functional requirements of a software system are usually predominant in the system specification, some other aspects need attention as well.
The nonfunctional requirements define meta-level properties of the target system, i.e. properties that usually specify additional constraints that cannot be modeled in the solely functional context. Typical examples for nonfunctional requirements are the stability of the system, security aspects, portability, extensibility etc. Nonfunctional requirements often affect a system as a whole. Because of their global nature, they should be specified only if it is absolutely necessary as they usually impose severe limits on the system design.