This site uses cookies.
Some of these cookies are essential to the operation of the site,
while others help to improve your experience by providing insights into how the site is being used.
For more information, please see the ProZ.com privacy policy.
Available for German to English translations. Technical Translations. SDL TRADOS.
Account type
Freelance translator and/or interpreter
Data security
This person has a SecurePRO™ card. Because this person is not a ProZ.com Plus subscriber, to view his or her SecurePRO™ card you must be a ProZ.com Business member or Plus subscriber.
Affiliations
This person is not affiliated with any business or Blue Board record at ProZ.com.
Minimum charge(s): Minimum charge for translation in EUR: 20.00
All accepted currencies
Euro (eur)
Blue Board entries made by this user
2 entries
Access to Blue Board comments is restricted for non-members. Click the outsourcer name to view the Blue Board record and see options for gaining access to this information.
German to English: Requirements specification General field: Tech/Engineering Detailed field: IT (Information Technology)
Source text - German Lastenheft
Vorbemerkung/ Einleitung
Ausgehend von der Beschreibung des Ist-Zustands enthält das Lastenheft alle an das zukünftige System verbindlich gestellten Anforderungen, die das Gesamtprojekt vollständig und konsistent beschreiben.
Es ist Basis für die Aufteilung in Teilprojekte.
Alle relevanten Anforderungen an das System werden vom Auftraggeber ermittelt und dokumentiert.
Kern des Lastenhefts sind die funktionalen und nicht-funktionalen Anforderungen an das System, sowie eine Skizze des Gesamtsystementwurfs.
Hintergrund
In diesem Abschnitt werden die Hintergründe und der Anlass zur Durchführung des Projektes anschaulich dargestellt.
Es wird beschrieben, welche Defizite bzw. Probleme existierender Systeme oder auch der aktuellen Situation zur Entscheidung geführt haben, das Projekt durchzuführen, und welche Vorteile durch den Einsatz des neuen Systems erwartet werden.
Ausgangssituation und Zielsetzung
In diesem Abschnitt werden alle relevanten Stakeholder des Projektes benannt und die technische und fachliche Einbettung des zukünftigen Systems in seine Umgebung skizziert.
Zusätzlich werden erste Rahmenbedingungen für die Entwicklung identifiziert und beschrieben.
Rahmenbedingungen können beispielsweise technische Vorgaben oder Vorgaben zur Sicherheit sein.
Funktionale Anforderungen
Funktionale Anforderungen beschreiben die Fähigkeiten eines Systems, die ein Anwender erwartet, um mit Hilfe des Systems ein (fachliches) Problem zu lösen.
Die Anforderungen werden aus den zu unterstützenden Geschäftsprozessen und den Ablaufbeschreibungen zur Nutzung des Systems abgeleitet.
Die Beschreibung der funktionalen Anforderungen erfolgt beispielsweise in Form von Anwendungsfällen (Use Cases).
Ein Anwendungsfall beschreibt dabei einen konkreten, fachlich in sich geschlossenen Teilvorgang.
Die Gesamtheit der Anwendungsfälle definiert das Systemverhalten.
Die funktionalen Anforderungen sind die zentralen Vorgaben für eine Systementwicklung.
Sie werden in der Gesamtsystemspezifikation (Pflichtenheft) übernommen und bei Bedarf konkretisiert.
Nicht-Funktionale Anforderungen
Nicht-funktionale Anforderungen beschreiben Anforderungen an das System, die nicht-fachlicher Natur sind, jedoch entscheidend zur Anwendbarkeit des Systems beitragen.
Sie definieren beispielsweise Qualitätsanforderungen, Sicherheitsanforderungen oder Performanceanforderungen.
Nicht-funktionale Anforderungen definieren grundlegende Eigenschaften eines Systems, die im Architekturentwurf berücksichtigt werden müssen.
Sie können zur Abschätzung der Entwicklungskosten herangezogen werden und sollten, soweit möglich, messbar beschrieben sein.
Zur einfachen Strukturierung der Anforderungen werden diejenigen Anforderungen, die nicht eindeutig zu den funktionalen Anforderungen gehören, den nicht-funktionalen Anforderungen zugeordnet.
Abnahmekriterien
Abnahmekriterien legen fest, welche Kriterien die Lieferung erfüllen muss, um den Anforderungen zu entsprechen.
Sie sollen messbar dargestellt werden.
Aus vertraglicher Sicht beschreiben die Abnahmekriterien die Bedingungen für die Entscheidung, ob das Endprodukt die gestellten Anforderungen erfüllt oder nicht.
Abnahmekriterien beziehen sich sowohl auf funktionale als auch auf nicht-funktionale Anforderungen.
In der Phase bis zur Auftragsvergabe können die Abnahmekriterien nur in einer allgemeinen Form, zum Beispiel als K.-o.-Kriterien, angegeben werden.
Darin wird beispielsweise definiert, dass mindestens 90% aller Prüffälle für eine erfolgreiche Abnahme erfüllt sein müssen.
Diese allgemeinen Abnahmekriterien sollten auch die Forderung nach einer Erstellung von Abnahmekriterien durch den Auftragnehmer enthalten.
Dabei sind der Aufbau und die Anzahl der Abnahmekriterien durch den Auftraggeber zu skizzieren.
Eine Strukturierung der Abnahmekriterien nach ihren drei wesentlichen Bestandteilen – Ausgangssituation, Aktion(en) und erwartetes Ergebnis – ist anzustreben.
In jedem Fall müssen die erwarteten Ergebnisse der Abnahme pro Abnahmekriterium festgelegt werden.
Die Abnahmekriterien sind Grundlage der Abnahmeprüfung und gehen als Anforderungen in die Prüfspezifikation Lieferung ein.
Translation - English Requirements specification
Preliminary remarks/ introduction
Based on the description of the actual status, the requirements specification contains all the binding requirements to be met by the planned system, which describe the overall project completely and consistently.
It is the basis for the division into sub-projects.
All relevant requirements for the system are determined and documented by the customer.
The core of the requirements specification comprises the functional and non-functional requirements for the system, as well as a diagram of the overall system design.
Background
This section clearly illustrates the background and the reason for carrying out the project.
It describes the shortcomings and problems of existing systems or the current situation that led to the decision to carry out the project and the expected benefits of using the new system.
Initial situation and objective
This section includes the names of all relevant stakeholders of the project and outlines the technical and functional integration of the planned system into its environment.
In addition, initial framework conditions for the development are identified and described.
Framework conditions can be, for example, technical specifications or specifications for safety.
Functional requirements
Functional requirements describe the capabilities of a system that a user expects in order to solve a (technical) problem with the help of the system.
The requirements are derived from the business processes to be supported and the process descriptions for using the system.
The functional requirements are described, for example, in the form of use cases.
A use case describes a concrete, technically coherent sub-process.
Overall, the use cases define the system behaviour.
The functional requirements are the key specifications for a system development.
They are included in the overall system specification (functional specification) and concretised as required.
Non-functional requirements
Non-functional requirements describe requirements for the system that are of a non-technical nature but contribute decisively to the applicability of the system.
For example, they define quality requirements, safety requirements or performance requirements.
Non-functional requirements define basic properties of a system that must be taken into account in the architectural design.
They can be used to estimate development costs and if possible, should be described in a measurable way.
For easy structuring of the requirements, those requirements that do not clearly belong to the functional requirements are assigned to the non-functional requirements.
Acceptance criteria
Acceptance criteria define which criteria the delivery must fulfil in order to meet the requirements.
They should be presented in a measurable way.
From a contractual perspective, the acceptance criteria describe the conditions for deciding if the final product meets the set requirements.
Acceptance criteria refer to both functional and non-functional requirements.
In the phase up to the contract award process, the acceptance criteria can only be specified in a general form, for example as knockout criteria.
This defines, for example, that at least 90% of all test cases must be fulfilled for successful acceptance.
These general acceptance criteria should also include the requirement for the contractor to draft acceptance criteria.
The structure and number of acceptance criteria shall be outlined by the customer.
A structuring of the acceptance criteria according to the three essential components - initial situation, action(s) and expected result - should be aimed for.
In any case, the expected results of the acceptance must be defined for each acceptance criterion.
The acceptance criteria are the basis of the acceptance test and are included as requirements in the test specification delivery.
More
Less
Translation education
Other - Goethe Institute, Pune
Experience
Years of experience: 10. Registered at ProZ.com: Jun 2015. Became a member: May 2016.
I am a German-English translator with experience in technical translations. Services offered: Translation, proofreading, MTPE. Very well versed in working with the CAT tool SDL TRADOS. Domains: Telecommunication, Finance, SAP, IT, Software, Hardware, e-commerce, Engineering.
Keywords: High quality translations, SDL Trados, Technical translations
Member since May '16
