Understanding the requirements

The first activity during the development process is the establishment of the requirements. Here is a joke. It consists of the following phases:

• Problem Domain Analysis
  • The aim of domain analysis is to understand the problem domain independently of the particular system we intend to develop. Here, we do not try to draw the borderline between the system and the environment.
  • We focus on the concepts and the terminology of the application domain with a wider scope than future system.
• External design: Establishing the borderline between the system and the environment.
• Requirements analysis, modeling and specification. The deliverable is the specification of the system requirements.

Activities and Results of Domain Analysis

First activity: Analysis of the domain-as-it-is:

• Establish a dictionary of terms defining the common terminology and concepts of the problem domain;
• Description of the problem domain from a conceptual modeling viewpoint, including inheritance hierarchies.The concepts used for this purpose are usually Entity-Relationship modeling (originally proposed by Peter Chen in 1976). Nowadays, one usually adopts the notation of UML Class diagrams.
  • Entity: represents a type of entity instances, defines the properties that hold for all such instances.  
  • Relationship: represents relationship instances that hold between certain pairs of entity instances
    • The related entity types are also called roles.
    • Multiplicity information indicate how many instances of the “other” side may be related to a given instance of “this” side.
  • Attribute: An entity or a relationship may have one or several attributes. Each attribute is identified by a name and its type, where such a type is usually some simple data type such as integer or character string. Note: An entity type is normally not used as the type of an attribute, because such a situation is rather represented by a relationship between the given entity and the attribute type
• Methodology: Normally, a textual description of the problem domain and requirements is given in some form. Establish a dictionary of terms, which includes the most important words in the textual description. Each noun indicates an object, or object class that may be important to be represented in the model. These are the so-called "entities" in the entity-relationship modeling approach. Each verb indicates a relationship between objects that may be important to be represented in the model. Distinguish between active objects (so-called actors) and passive objects that have no own initiatives (they are usually "called").
• Note: Later, one also wants a clear statement of purpose, i.e., objectives and goals for the new system to be built and its border with the other entities within the domain. (This system to be built is part of the future version of the domain)

Second activity: External Design - Designing the domain-to-be, including the system-to-be-built

• During Requirements Analysis, one finds the existing properties of the problem domain, as well as the requirements that should be satisfied in the domain-to-be. We assume that the domain-to-be will include a new system-to-be-built and other aspects of the domain may also be changed.
• The determination of this domain-to-be, including the system-to-be, is a typical design process. It is called external design because the system-to-be is considered during this process as a black-box and the external environment of it is designed (in a white-box manner) – the domain-to-be.
  • Somebody said: Requirements Specification is «The invention and definition of the behavior of a new system (solution domain) such that it will produce the required effects in the problem domain »
• Note: During this process, the boundary (and interfaces) of the system-to-be will be established

Here is an example of problem domain analysis (the Access Control System), also including the first phase of requirement analysis

Requirements analysis, modeling and specification: General considerations

What is a system ?

• A system is part of real world that a person or group of persons during some time interval and for some purpose choose to regard as a whole, consisting of interrelated components, each component characterized by properties that are selected as being relevant to the purpose.
• A system is a purposeful collection of interrelated components that work together to achieve some objective.
• A system is part of the real world.
• What constitutes a system is a matter of definition.
• Each component of a system may also be regarded as a system.
• A system is not just any unordered collection of components.
• A system has purpose.

A system description has two purposes:

1. To describe the functional behavior so that it can be fully understood
2. To describe the realization so that the system may be produced

. . . and it has two aspects:

1. The structure (static)
   • The structure of a system is the aspects of the system which stay invariant during the time interval in which it is studied.
   • Structure is the way things hold together for some time.
2. The (dynamic) behavior
   • The behavior of a system is the development of states and state transitions generated by actions of the system during the time interval in which it is studied.
   • Behavior is a dynamic development over time.
   • Actually occurring in real world.
   • Approximation: behavior consists of actions that change the state (value) of variables.
   • Behavior is the most difficult system aspect to describe, due to its dynamic and transient nature. In most cases, the possible sequences of interactions include looping behavior which means that these sequences are not bounded in their length and there is an infinite set of valid behavior sequences. How can one describe such infinite behavior in a finite-size behavior specification ??

Methods for dealing with complexity

• Abstraction:
  • To ignore some aspects of a phenomenon in order to describe (and understand) others more clearly.
  • Opposite of concrete or physical.
  • The abstractions should be clear and precise, lead to efficient implementation, and support the continuing development and reuse.
• Aggregation and partitioning:
  • All non-trivial systems are composed from components.
  • The process of lumping components together to form a whole is called aggregation.
  • The opposite process of decomposing a whole into parts is called partitioning.
• Projection:
  • In projections we look at the system from different angles.
  • A projection is a description of a system as it is observed at subset of its interfaces.
  • Only the observable interfaces are visible, while the others are hidden
• Generalization - specialization:
  • In the real world there are huge amounts of similar subjects.
  • Rather than describing and understanding all individuals in full detail, we may describe and understand them in terms of similarity.
  • Types are conceptual entities that we use to structure our descriptions and thoughts. Types are called “Classes “ in UML
  • An example

A system specification includes assumptions and guarantees

In general, a system specification has the following form: 

• If certain assumptions about the environment are satisfied, then the system will provide certain guarantees to the environment
  • Example of a sorting program – Specification A: If the input list of integer numbers has less than 1000 entries, then the output list will contain the same integer numbers in ascending order, however, the list may be shorter if some number occurred several times in the input list. – Note: no guarantee is given for the case that the input list contains 1000 entries or more.

Theorem for component-based development: Given a specification S = AS implies GS (assumption implies guarantee) for a component within a given system structure and an implementation satisfying the specification I = AI implies GI . The implementation can be used for realizing this component iff AI is weaker than AS and GI is stronger than GS . - - One sometimes says that I “conforms“ to S.

Example: Given an implementation of a sorting program which satisfies the following Specification B: If the input list of integer numbers has less than 2000 entries, then the output list will contain the same integer numbers in ascending order, each number only once, even if the input list contains some number multiple times. This means:

• Assumption (B): there is an input list of less than 2000 integers.
  • Assumption (B) of less than 2000 is weaker than less than the assumption (less than 1000) of Specification A.
• Guarantee (B): the output list contains the same integer numbers in ascending order, each number only once.
  • Guarantee (B) of having each number only once is stronger than the guarantee of Specification A.
• Note: The guarantee of Specification A is non-deterministic: it allows for different multiplicities of numbers in the output list.

Question: Can this implementation be used for the component specified to satisfy Specification A ?

Examples of specializations:

• If an OO class I inherits from a class S, this means that all methods provided by S (guarantees) are also provided by I, that is, the guarantees of I are stronger than the guarantees of S. This is a special kind of conforming specialization.
• An implemention of the sorting function that is specialized (and optimized) for numbers between 0 and 255 can be called a “specialization” of the implementation considered above. However, it is not a conforming specification, because it has a stronger assumption (namely, the the sorted values are smaller than 255).

Requirements analysis, modeling and specification: Methodology

• Identify system interfaces and external actors: Based on the relationships between object classes in the conceptual model of the environment, identify the interfaces between the system and the other entities in the environment. Identify the different interactions that may occur at these interfaces. There may be different kinds of interactions identified at an abstract level (see below for more detail), such as: operation (method) calls, rendezvous interactions, and message exchanges.
• Define use cases: Each use case defines a certain possible sequence of interactions. These interaction sequences may be represented by UML Interaction diagrams.
  • They capture the intended behavior of the system. May be expressed as services, tasks or functions the system performs.
  • Use cases have quickly become a widespread practice for capturing functional requirements.
    • This is especially true in the object-oriented community where they originated
    • Their applicability is not limited to object-oriented system
  • A use case defines a goal-oriented set of interactions between external actors and the system under consideration. (Actors are parties outside the system that interact with the system: users, or other entities outside the system)
    • A use case is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied.
    • It describes the sequence of interactions between actors and the system necessary to deliver the service that satisfies the goal.
• Sometimes, during the establishment of the requirements, the structure of the system is modeled in terms of several components. See example of alarm system.
• The system, or the components, may exist in different states, and their dynamic behavior may be different in these different states. Identify these states by constructing a state machine model for each component (or the system as a whole).

Example Access Control System (last section)

Example ATM

Distinction between functional and non-functional requirements

• Functional requirements define what a system is supposed to do 
• Non-functional requirements define how a system is supposed to be: Usually describe system attributes such as response time, throughput, security, reliability, maintainability, scalability, usability…