8.2 Products of Submodel SD
		8.2.1 User Requirements (UReq)

  Anwenderforderungen

Contents		Introduction Document Index Document Structure Product Flow Links to the V-Model Mailinglist

Introduction

The User Requirements contain the documentation of the recording of actual status and current analysis as well as the threat and risk analysis, the documentation of the IT security objectives and the IT security measures, the definition of user-level requirements, and the marginal conditions.

To mark requirements a formalism is needed which allows each requirement to be identified in a unique way; so a unique reference will be possible from the architecture and design documents (acknowledgment principle).

When stating requirements care must be taken to describe only "WHAT" a task is to accomplish, not "HOW" it is going to be accomplished. Furthermore, what must be taken into consideration is that requirements have to be assessable, unique, consistent, and free of hidden design decisions.

The term "System" also comprises the term "procedure".

Document Index

Document Structure

1. General Information

2. Actual Status and Current Analysis

• a System like this already exists and is to be replaced by a new one (in exceptional cases also for extensive SWMM measures), or
• System to be developed is to be integrated into existing conditions with respect to process organization or conditions of a technical nature.

In detail, the following items are relevant within the scope of the actual status and current analysis, for example:

• recording of the user environment (structure and process organization, official regulations, decrees, laws, rules, and the like)
• integration of existing data stocks, programs
• recording of available IT equipment
• recording of time and quantity listing (present processing times, throughput times, response times, waiting times, amount of data)
• recording of user-level and technical factors that cannot be influenced
• presentation of the threat and equipment gap
• detection of weak points
• finding out what caused the detected weak points

3. IT Security Objective

4. Threat and Risk Analysis

5. IT Security

The total effects expected of all those measures are specified in the requirements for IT security. The threats from the threat analysis and risk analysis must be allocated to the requirements. It must be made clear that IT security measures counteract those threats.

6. User-level Requirements

6. 1. Preliminary System Description

• It is necessary to define which user-level tasks are to be supported by the System. Therefore, the integration of the System into the organization or the integration environment must be described.
• The description must point out which overall functionality is to be covered in the final version, and, in this connection, which priorities are expected in the course of the following development.
• The description must include the application concept in order to derive the technical and organizational application environment and the marginal conditions (within the scope of SD1.4 - Definition of Marginal Conditions).
• The description must include quantitative estimations that can be used to make basic technical decisions with the correct order of magnitude (network organization, computing power, etc.).
• The description must be very exact in order to make it possible in future to decide when this overall horizon should or can be left and technical decisions might be reconsidered accordingly.
• The use of predefined user-level items (standard topics) must be taken into consideration. Possible candidates for the reuse on the level of the User Requirements within the scope of the planned development must be named.

6. 2. Organizational Embedding

6. 3. Utilization

6. 4. Criticality of the System

6. 5. External Interfaces

Requirements with regard to ergonomics must also be taken into consideration. The technical design of the user interface is defined within the scope of the Technical Requirements.

6. 6. Description of the Functionality

• The functionality of the System is described by taking into consideration the tasks to be fulfilled by the System.
• Business processes are defined for the determination of the required System functionality. They have to be considered in its entirety, i. e. completely, even when the required System only supports certain sections of this functionality. The users will become an integral part of the description. The System is seen as a whole, together with its environment (man, connected systems).
• A user-level structure of the functionality into fields is carried out. This structure is used
  • as a basis for the decision about the use of fields already defined earlier (standard topics),
  • as a basis for the separation of system parts to generate and investigate solution proposals,
  • as a criterion for the placing of development orders,
  • as the basis for an incremental development strategy for a fast availability of Systems to be applied operationally (by an early feedback from the application it is possible to minimize the development risk considerably),
  • as the planning basis and as a guideline for the upgrade of the System on a step-by-step basis,
  • as initial information for the setting up or optimizing the organization at the user.
• Examples for standard topics are
  • mailing and communication,
  • storage of data and documents,
  • IT security,
  • man-machine interface (like representation of the actual situation, generation and processing of messages),
  • office functions.
• Classifications of criticality levels are set up within the scope of the functionality description. Criticality levels are allocated to the fields and the structure elements they are based on.
• The information needs of the user have to be defined in a clear and distinct way, but independently of the technical specifications. If necessary, the data will be described here as well, i. e. if they are known on this level already.

Notes:

• The order of the user-level requirements for the functionality is not specified as a regulation element beyond the demanded field structure. However, the user-level order must always be described as independent of the technical architecture.
• The reference to possibly predefined fields is an essential element of the user-level description.
• If structure and process organization for information systems are optimized for the user as a result of the recording of actual status and analysis in parallel to system development, then it is necessary to refer to the results of these optimizations while the planned business processes are specified and the System is structured at user-level into fields.
• Developments in the field of information technology may result in new application fields which always have an impact on the organizational structure. On the other hand, structure and process organization impose primary marginal conditions for IT system support. Therefore, organization development and system generation interact closely. As a result, they have to be closely coordinated with each other.

6. 7. Quality Requirements

• reliability,
• user friendliness,
• efficiency,
• maintainability,
• portability,
• reusability,
• static and dynamic performance data, etc.

7. Marginal Conditions

7. 1. Technical Marginal Conditions

• Technical Requirements for interfaces,
• specifications for the technical realization of interfaces,
• notes and specifications for the technical operation,
• specification of off-the-shelf products,
• adhering to technical standards,
• specifications from the technical development environment, SWMM environment or application environment.

In addition, technical requirements for the environment may also be documented here (e. g. for hardware: required air-conditioning, vibration reducers.).

7. 2. Organizational Marginal Conditions

• Distribution of user-level tasks (functions) within the scope of the organizational structure,
• required communication, cooperation and coordination among instances in the user's process organization,
• information requirements for handling business processes,
• execution rhythm and repetitiveness of business processes,
• geographical distribution of users in application area,
• specifications from organization development for staff size, job plans, job descriptions,
• specifications from personnel laws (Civil Service Act, regulations governing industrial relations, worker participation, tariff contracts),
• cooperation with external instances and authorities (inter-authority cooperation, cooperation between authorities),
• placement of user-level tasks (functions) to external contractors, i. e. by outsourcing.

7. 3. Other Marginal Conditions

Product Flow

Links to the V-Model Mailinglist

This page online  •  GDPA Online  •  Last Updated 04.Mar.2004 by C. Freericks