Chapter 8
User requirement should be written in natural language to be understandable by non-technical people, but during developing process requirements may be expressed in more technical way. One widely used technique is to document the system specification as a set of system models. Models are graphical representation of what system should do and how it should operate, that’s why models are often more easy to understand than even detailed natural language description. Models are also an important bridge between the analysis and design process.
At an early stage of requirement engineering developers should define the boundaries of the system. This involves working with system stakeholders to distinguish what is the system and what is the system’s environment. These decisions should be made early to limit the cost of developing and time for analysis. Once some decisions on the boundaries of the system have been made, part of the analysis activity is the definition of that context and the dependencies that a system has on its environment. Producing a simple architectural model is the first step in this activity. Architectural models describe the environment of a system. However, they don’t show the relationship between the other systems in the environment and the system that is being specified. Therefore, simple architectural models are normally supplemented by other models, such as process models, that show the process activities supported by the system.
Behavioural models are used to describe the overall behaviour of the system. Two types of behavioural models exist:
These types of models can be combined.
Most large software systems make use of a large database of information. In some cases, this database is independent of the software system. In others, it is created for the system being developed. An important part of systems modeling is defining the logical form of the data processed by the system. The most widely used data modeling technique is Entity-Relation-Attribute modeling (ERA modeling), which shows the data entities, their associated attributes and the relations between these entities. These models have been widely used in database design. Like all graphical models, data models lack detail, and you should maintain more detailed descriptions of the entities, relationships and attributes that are included in the model. More detailed descriptions are often stored in a repository or data dictionary. A data dictionary is an alphabetic list of the names included in the system models. As well as the name, the dictionary should include an associated description of the named entity and, if the name represents a composite object, a description of the composition.
An object-oriented approach to the whole software development process is now commonly used. This means expressing the system requirements using an object model, designing using objects and developing the system in an object-oriented programming language. Developing object models during requirements analysis usually simplifies the transition to object-oriented design and programming. However, as author notices, end-users often find object models unnatural and difficult to understand.
Object-oriented modeling involves identifying the classes of object that are important in the domain being studied. These are often organised into taxonomy. A taxonomy is a classification scheme that shows how an object class is related to other classes through common attributes and services. To display this taxonomy, the classes are organised into an inheritance hierarchy with the most general object classes at the top. The design of class hierarchies is not easy, so the analyst need to understand, in detail, the domain in which the system is to be installed. As well as acquiring attributes and services through an inheritance relationship with other objects, some objects are groupings of other objects. The classes representing these objects may be modeled using an object aggregation model.
A structured method is a systematic way of producing models of an existing system or a system that is to be built. Structured methods provide a framework for detailed system modelling as part of requirements elicitation and analysis.
My thoughts
As everything big and important today, such process as software engineering is based on some abstract things. System models are abstract and detailed at the same time. Different types are used, but again, as I said before, my opinion is “mixing is better”, or in this case using different types of models to describe different sides of development have to be done.
Modelling the system is important, because this is the base, most fundamental part of actual work after requirements are defined, or at least part of them. Even for such a small project as our Monopoly game, I cannot imagine starting coding from scratch with no requirements defined and model developed, especially when there are four people in the team. Models are also useful to divide work between developers I guess: when signals are defined and model is created, different components may be implemented by different people, sometimes – in the different parts of Earth (like most of Open Source developers work).