![]() |
![]() |
![]() |
|
![]() |
|||
| SSD01 - Recording Requirements |
LSE01 - Anforderungen erfassen
1 Allocation to V-Model and Methods Allocation
SD1.2 - Description of Application System
SD1.3 - Definition of Criticality and Quality Requirements
SD1.4 - Definition of Marginal Conditions
SD1.5 - User-Level System Structure
SD1.6 - Threat and Risk Analysis
SD2.1 - Technical System Design
SD2.4 - Allocation of User Requirements
SD3.1 - Definition of General Requirements from SW/HW Unit Point of View
SD3.2 - Specification of Requirements for External Interfaces of SW/HW Unit
SD3.3 - Definition of Requirements for the Functionality
SD3.4 - Definition of Requirements for the Quality of the SW/HS Unit
SD3.5 - Definition of Requirements for the Development and SWMM Environment
SD4.1 - SW Architecture Design
Method
none
2 Brief Characteristics
The requirements for tools supporting one or several methods have been listed in separate service units.
3 Requirements
3.1 Requirements for Interfaces
| SSD01.I.1 | Granularity | The exchange of control parameters with SWFM01 - Workflow Management is possible for individual closed function packages of the tool by means of a disclosed, documented interface. |
3.2 Requirements for the Methods Support
3.3 Requirements for Functions
| SSD01.F.1 | Collection of Requirements | |
| SSD01.F.1.1 | Based on forms | It is possible to collect requirements by means of forms. For each requirement special fields have to be filled out. The fields might also be those intended for free text or graphics. |
| SSD01.F.1.2 | Graphical collection | It is possible to graphically collect the requirements. For example, requirements on courses of functions and requirements with regard to data can be collected with the help of a special graphic system (with symbols of definite meaning). |
| SSD01.F.1.3 | Adaptability | It is possible to adapt the forms applied for the collection of requirements to individual projects. |
| SSD01.F.2 | Requirements allocation | |
| SSD01.F.2.1 | Segments | It is possible to allocate a requirement to DP Segments. |
| SSD01.F.2.2 | SW Unit | It is possible to allocate a requirement to SW Units. |
| SSD01.F.2.3 | Interfaces | It is possible to allocate a requirement to interfaces. |
| SSD01.F.2.4 | Development environment | It is possible to allocate a requirement to the development environment and its components. |
| SSD01.F.2.5 | Target environment | It is possible to allocate a requirement to the target environment. |
| SSD01.F.2.6 | Requirement sets | It is possible to display sets of requirements that are allocated to preset Subsystems, DP Segments, SW Units, Interfaces, Development Environments, and Target Environments. |
| SSD01.F.3 | Identification of requirements | |
| SSD01.F.3.1 | Alphanumeric | An alphanumeric identification, i. e. name is allocated to each requirement. |
| SSD01F.3.2 | Structuring | By means of the requirement identification it is possible to classify and to hierarchically structure the requirements. By means of this structuring a hierarchical refinement of the requirements is representable. |
| SSD01.F.4 | Description of requirements |
The following information is allocated to each requirement: generator (author), date of and comment to the requirement. A comment on the requirement might consist of a reference whether the requirement is part of the contract or it is a derived requirement. |
3.4 Other Requirements
| SSD01.O.1 | Upward compatibility | It must be possible to process objects generated with an older release of the tool with the later release of that tool, without loss of information and functionality. |
| SSD01.O.2 | Procedural command language | The tool has a procedural command language that can be applied by the user to generate and run macros or procedures. |
| SSD01.O.3 | Complexity | There is no limitation of the complexity caused on the tool itself. |
![]() |
![]() |
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
![]() |