RE.3.3.1 User Requirements (UReq)

  Anwenderforderungen

Contents		Introduction Document Index Document Structure

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. User-level Requirements

2. 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.
• 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.

2. 2. Organizational Embedding

2. 3. Utilization

2. 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.

2. 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.

GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster