LF3 · Informieren

LF3.1 – Anforderungen an die Client-Integration erfassen

Kundenwünsche präzisieren, Soft- und Hardwareanforderungen strukturieren und überprüfbare Leistungskriterien für die spätere Netzwerkintegration formulieren.

Lernfeld 3 · Clients in Netzwerke einbinden

Curriculum-Faden

Diese Teilkompetenz bauen Sie hier auf

Handlungsphase: Informieren

Im Kundengespräch Anforderungen an die Integration von Client-Hardware und Client-Software erfassen und daraus überprüfbare Leistungskriterien ableiten.

Baut auf

LF2.14 hat den bereitgestellten Arbeitsplatz bewertet und die Netzwerkperspektive als nächsten Kompetenzschritt vorbereitet.

Bereitet vor

LF3.2 erfasst die bestehende Netzwerkinfrastruktur, in die der Client integriert werden soll.

Bewusste Abgrenzung dieser Lektion

Noch keine IP-Konfiguration, kein Subnetting und keine Komponentenauswahl.

Curriculumquelle: KMK-Rahmenlehrplan Fachinformatiker, Lernfeld 3

Berufliche Ausgangssituation

Im fiktiven K-27 Medienbüro stehen nun zwölf funktionsgeprüfte Arbeitsplätze aus Lernfeld 2 bereit.

Die Geräte funktionieren als einzelne Arbeitsplätze. Jetzt sollen sie in die bereits vorhandene Netzwerkinfrastruktur des Unternehmens eingebunden werden.

Der Kunde formuliert zunächst:

„Die neuen Arbeitsplätze sollen einfach zuverlässig im vorhandenen Netzwerk funktionieren.“

Für eine technische Integration reicht diese Aussage noch nicht aus.

Zuerst muss geklärt werden, was genau funktionieren soll und woran die erfolgreiche Integration später erkannt werden kann.

Was verlangt das Lernfeld?

Lernfeld 3 beginnt mit dem Kundengespräch.

Dabei werden die Anforderungen an die Integration von Clients mit ihrer Software und Hardware in eine bestehende Netzwerkinfrastruktur erfasst.

Aus diesen Anforderungen werden Leistungskriterien abgeleitet.

LF3.1 beantwortet deshalb: Was soll der Client im vorhandenen Netzwerk leisten?

LF3.2 beantwortet anschließend: Welche Infrastruktur ist tatsächlich vorhanden?

Konkrete IP-Konfiguration, Subnetzplanung oder Komponentenauswahl gehören noch nicht in diese Lernetappe.

Was ist in LF3 ein Client?

Ein Client ist im Kontext dieser Lernsituation ein IT-System, das Netzwerkfunktionen oder Netzwerkressourcen nutzt.

Im K-27-Projekt sind die in LF2 aufgebauten Arbeitsplatzrechner die zentralen Clients.

Für ihre Integration sind jedoch nicht nur die Rechner selbst relevant.

Je nach Anforderung können beispielsweise auch folgende Aspekte eine Rolle spielen:

Netzwerkschnittstellen des Clients,
benötigte Anwendungen,
vorhandene Netzwerkressourcen,
Netzwerkdrucker oder andere vorgesehene Dienste,
betriebliche Vorgaben für den Netzwerkzugang,
Arbeitsplatz- und Nutzungssituation.

Integration ist mehr als „Kabel einstecken“

Eine erfolgreiche Client-Integration bedeutet nicht nur, dass eine physische Verbindung vorhanden ist.

Der Client muss die für seine Arbeitsaufgabe vorgesehenen Netzwerkfunktionen nutzen können.

Beispiel: Ein angeschlossener Client ist nicht automatisch erfolgreich integriert, wenn die benötigte Geschäftsanwendung ihre vorgesehene Netzwerkressource nicht erreichen kann.

Deshalb beginnt die Integration mit der Anforderungsklärung und nicht mit einer zufälligen Konfiguration.

Kundenäußerung, Anforderung und Leistungskriterium trennen

Ebene	Beispiel
Kundenäußerung	„Die Arbeitsplätze sollen auf unsere gemeinsamen Dateien zugreifen können.“
geklärte Anforderung	Die zwölf neuen Clients müssen die vorgesehene bestehende Dateifreigabe für ihre Arbeitsaufgaben nutzen können.
Leistungskriterium	Im definierten Funktionstest kann jeder freigegebene Client auf die vorgesehene Dateifreigabe zugreifen.

Merksatz: Eine Kundenäußerung beschreibt häufig einen Wunsch. Eine Anforderung präzisiert, was benötigt wird. Ein Leistungskriterium macht die Erfüllung überprüfbar.

Leistungskriterium ist nicht dasselbe wie technische Lösung

Ein häufiger Fehler besteht darin, bereits während der Anforderungsklärung eine konkrete Lösung festzulegen.

Zu früher Lösungssprung	Sauberer Anforderungsbezug
„Wir brauchen auf jeden Fall einen neuen Switch.“	„Für zwölf zusätzliche Clients müssen geeignete Netzwerkanschlüsse beziehungsweise Zugangsmöglichkeiten vorhanden sein.“
„Alle Clients bekommen statische IP-Adressen.“	„Die Clients benötigen eine zum vorhandenen Netz passende IP-Konfiguration.“
„Wir verwenden WLAN.“	„Es muss geklärt werden, welche Art des Netzwerkzugangs am jeweiligen Arbeitsplatz vorgesehen und verfügbar ist.“

Welche technische Lösung tatsächlich passt, wird erst nach der Analyse der bestehenden Infrastruktur entschieden.

Welche Anforderungen sollten geklärt werden?

Für LF3.1 ist eine strukturierte Betrachtung sinnvoll.

Arbeitsaufgabe

Welche Tätigkeiten soll der Benutzer mit dem Client im Netzwerk durchführen?

Client-Software

Welche Anwendungen benötigen Netzwerkzugriff oder vorhandene Netzwerkressourcen?

Client-Hardware

Welche vorhandenen oder benötigten Schnittstellen sind für die Integration relevant?

Netzwerkressourcen

Welche bereits vorhandenen Ressourcen sollen aus Sicht des Clients erreichbar sein?

Nutzung

Wo und in welchem betrieblichen Kontext wird der Client eingesetzt?

Rahmenbedingungen

Welche betrieblichen Vorgaben, Termine oder Einschränkungen sind bereits bekannt?

Funktionale Anforderungen formulieren

Funktionale Anforderungen beschreiben, was der Client im vorgesehenen Nutzungskontext leisten soll.

Beispiele für den fiktiven K-27-Fall:

Die vorgesehene Geschäftsanwendung muss ihre benötigte Netzwerkfunktion nutzen können.
Die Mitarbeiter sollen die freigegebene vorhandene Dateifreigabe nutzen können.
Der vorgesehene Netzwerkdrucker soll aus der Arbeitsumgebung erreichbar sein.
Die Videokonferenzanwendung benötigt den vorgesehenen Netzwerkzugang.

Diese Aussagen beschreiben Ergebnisse, noch keine konkrete Netzwerkkonfiguration.

Softwareanforderungen erfassen

Nicht jede Anwendung benötigt dieselben Netzwerkfunktionen.

Deshalb wird für relevante Software geklärt:

Benötigt sie Netzwerkzugriff?
Welche vorhandene Ressource oder Funktion muss erreichbar sein?
Ist die Nutzung betriebsintern, extern oder beides?
Gibt es bereits bekannte betriebliche Vorgaben?
Wie kann später geprüft werden, ob die benötigte Funktion verfügbar ist?

Wichtig: LF3.1 inventarisiert keine Serverdienste und konfiguriert sie nicht. Es wird nur geklärt, welche Funktionen der Client benötigt.

Hardwareanforderungen erfassen

Auch auf der Clientseite können technische Voraussetzungen relevant sein.

Beispielsweise:

vorhandene Netzwerkschnittstellen,
benötigte Anschlussmöglichkeiten,
gegebenenfalls drahtlose Netzwerkfähigkeit,
Kompatibilität mit vorhandenen Arbeitsplatzgeräten,
betriebliche Vorgaben für verwendbare Hardware.

Welche Medien, Netzwerkkomponenten und Topologien tatsächlich vorhanden sind, wird erst in LF3.2 und LF3.3 genauer untersucht.

Bestehende Infrastruktur nicht erfinden

Der Kunde weiß im Gespräch möglicherweise nicht, welcher Switch, welches Adressierungskonzept oder welche konkrete Netzwerkstruktur verwendet wird.

Das ist kein Grund, fehlende Informationen durch Vermutungen zu ersetzen.

Status: bekannt → dokumentieren

ungeklärt → als offene Frage kennzeichnen

später zu analysieren → LF3.2 zuordnen

So bleibt die Grenze zwischen Kundenanforderung und technischem Ist-Zustand sauber.

Mit offenen Fragen arbeiten

Aus einer allgemeinen Aussage entstehen häufig gezielte Rückfragen.

Kundenaussage	Sinnvolle Rückfrage
„Die Rechner brauchen Netzwerk.“	Welche Arbeitsaufgaben oder Ressourcen sollen über das Netzwerk genutzt werden?
„Die Drucker müssen funktionieren.“	Welche vorhandenen Drucker sollen von welchen Arbeitsplätzen genutzt werden?
„Wir brauchen Internet.“	Für welche Anwendungen oder Arbeitsprozesse wird der externe Netzwerkzugang benötigt?
„Die neuen PCs sollen genauso funktionieren wie die bisherigen.“	Welche konkreten Netzwerkfunktionen der bisherigen Arbeitsplätze sind für die Arbeit erforderlich?

Priorität sichtbar machen

Nicht jeder Wunsch hat dieselbe Bedeutung.

Für ein einfaches Lernmodell verwenden wir:

Priorität	Bedeutung
Muss	Ohne diese Anforderung erfüllt die Client-Integration ihren vorgesehenen Zweck nicht.
Soll	Die Anforderung ist wichtig, eine begründete Abweichung wäre aber grundsätzlich diskutierbar.
Kann	Zusätzlicher Nutzen, aber nicht Voraussetzung für die Kernfunktion.
ungeklärt	Die Bedeutung oder technische Voraussetzung muss noch geklärt werden.

Dieses Prioritätsmodell dient hier als SemaTrain-Lernmodell.

Leistungskriterien müssen überprüfbar sein

Ein Leistungskriterium sollte später eine klare Prüfung ermöglichen.

Unklar	Überprüfbarer
„Der Netzwerkzugriff muss gut funktionieren.“	„Der Client erreicht im definierten Funktionstest die für seine Arbeitsaufgabe vorgesehene Dateifreigabe.“
„Der Drucker muss verfügbar sein.“	„Vom vorgesehenen Client kann ein definierter Testdruck an den freigegebenen Netzwerkdrucker übergeben werden.“
„Videokonferenz soll gehen.“	„Die freigegebene Videokonferenzanwendung kann im definierten Test die benötigte Netzwerkverbindung aufbauen.“

Wichtig: Keine technischen Zahlen erfinden. Wenn beispielsweise eine konkrete Datenrate oder Latenz nicht begründet vorgegeben ist, wird sie nicht nur deshalb eingefügt, damit ein Kriterium numerisch aussieht.

Das SemaTrain-Anforderungsraster

Feld	Beispiel
Quelle	Kundengespräch
Kundenaussage	„Die Arbeitsplätze brauchen unsere gemeinsamen Dateien.“
geklärte Anforderung	Die zwölf Clients müssen die vorgesehene vorhandene Dateifreigabe für die Arbeitsaufgabe nutzen können.
Leistungskriterium	Zugriff im definierten Funktionstest erfolgreich.
Priorität	Muss
Status	Anforderung geklärt
offene Infrastrukturfrage	Technischer Zugangsweg und vorhandene Netzstruktur noch zu analysieren.

Die Rasterstruktur und alle Beispieldaten wurden eigenständig für SemaTrain entwickelt.

Der K-27-Anforderungssatz

Nach dem fiktiven Kundengespräch werden zunächst folgende Anforderungen dokumentiert:

Anforderung	Priorität	Leistungskriterium
Alle zwölf Clients benötigen den vorgesehenen Netzwerkzugang.	Muss	Netzwerkfunktion ist am Client im definierten Test nutzbar.
Vorgesehene Dateifreigabe muss nutzbar sein.	Muss	Definierter Zugriffstest erfolgreich.
Freigegebener Netzwerkdrucker soll nutzbar sein.	Muss	Definierter Testdruck kann übergeben werden.
Geschäftsanwendung benötigt ihre vorgesehene Netzwerkfunktion.	Muss	Anwendung besteht den definierten Funktionstest.
Videokonferenzfunktion muss im vorgesehenen Nutzungskontext arbeiten.	Muss	Freigegebene Anwendung kann den vorgesehenen Verbindungstest durchführen.

Noch nicht geklärt sind beispielsweise:

die konkrete vorhandene Netzwerkstruktur,
die verwendeten Netzwerkkomponenten,
der technische Zugangsweg an jedem Arbeitsplatz,
das vorhandene IP-Adressierungskonzept,
weitere technische Standards und Eigenschaften.

Genau diese Punkte führen in LF3.2 weiter.

Keine IP-Adressen aus dem Kundengespräch erfinden

Zu diesem Zeitpunkt ist beispielsweise noch nicht bekannt, welche IP-Adressen, Präfixe oder sonstigen Netzparameter verwendet werden.

Deshalb falsch: „Wir tragen einfach 192.168.1.x ein, das wird schon passen.“

Der tatsächliche technische Ist-Zustand wird zunächst analysiert.

IPv4 und IPv6 werden später in LF3.7 systematisch eingeordnet; IPv4-Subnetzplanung folgt in LF3.8.

Noch keine Netzwerkkomponenten auswählen

Auch die Frage, ob zusätzliche Switch-Ports, Adapter, Access Points oder andere Komponenten benötigt werden, kann erst nach der Bestandsanalyse belastbar beantwortet werden.

LF3.1: Was wird benötigt?

LF3.2 bis LF3.10: Was ist vorhanden und welches Konzept passt?

LF3.11: Welche Komponenten werden daraus begründet ausgewählt?

Typischer Denkfehler

„Der Kunde sagt Netzwerk. Also können wir sofort konfigurieren.“

Nein.

Vor der Konfiguration müssen mindestens zwei Dinge geklärt sein:

Welche Funktionen und Anforderungen soll die Integration erfüllen?
Welche Infrastruktur ist tatsächlich vorhanden?

LF3.1 beantwortet die erste Frage. LF3.2 beginnt mit der zweiten.

Praxisfall: Anforderungen für K-27 klären

Der fiktive Kunde äußert:

„Alle neuen Rechner brauchen natürlich Netzwerk.“
„Die gemeinsamen Dateien müssen erreichbar sein.“
„Der Netzwerkdrucker soll weiter genutzt werden.“
„Videokonferenzen müssen funktionieren.“
„Die Geschäftsanwendung darf keine Probleme machen.“
„Wie das Netzwerk technisch aufgebaut ist, weiß ich nicht genau.“

Ihre Aufgabe:

Trennen Sie Kundenäußerungen von bereits geklärten Anforderungen.
Formulieren Sie zu jeder Aussage mindestens eine gezielte Rückfrage.
Leiten Sie überprüfbare Leistungskriterien ab, soweit die Informationen dafür ausreichen.
Kennzeichnen Sie fehlende technische Informationen als ungeklärt.
Trennen Sie Muss-, Soll- und Kann-Anforderungen.
Notieren Sie, welche Informationen erst durch die Bestandsanalyse in LF3.2 ermittelt werden können.

TRANSFER

Transfer: Der Kunde nennt bereits eine Lösung

Ein anderer Kunde sagt:

„Wir brauchen für die neuen Clients auf jeden Fall WLAN.“

Prüfen Sie diese Aussage zunächst als Anforderungsanalyst:

Welche eigentliche Arbeitsanforderung steckt dahinter?
Ist Mobilität erforderlich?
Sind feste Arbeitsplätze vorgesehen?
Welche vorhandenen Zugangsmöglichkeiten existieren?
Ist WLAN eine Anforderung oder bereits ein Lösungsvorschlag?

Formulieren Sie anschließend die zugrunde liegende Anforderung lösungsneutral.

PRAXISAUFGABE

Praktische Lernaufgabe

Selbsttraining – keine Abgabe erforderlich.
Ihre Bearbeitung wird von SemaTrain derzeit weder hochgeladen noch an einen Trainer übermittelt.

Erstellen Sie ein Anforderungsprofil für die Integration von vier vollständig fiktiven Büro-Clients in ein bestehendes Netzwerk.

Das Profil soll enthalten:

mindestens fünf Kundenäußerungen,
zu jeder Aussage eine geklärte Anforderung,
mindestens fünf überprüfbare Leistungskriterien,
eine Kennzeichnung mit Muss, Soll, Kann oder ungeklärt,
mindestens vier offene Infrastrukturfragen,
eine klare Trennung zwischen Anforderung und technischer Lösungsidee.

Vergeben Sie noch keine IP-Adressen, berechnen Sie noch keine Subnetze und wählen Sie noch keine konkrete Netzwerkhardware aus.

SELBSTKONTROLLE

Selbstkontrolle

Habe ich den tatsächlichen Nutzungskontext verstanden?
Trenne ich Kundenaussage und geklärte Anforderung?
Berücksichtige ich Client-Software und Client-Hardware?
Formuliere ich Leistungskriterien überprüfbar?
Vermeide ich erfundene technische Zahlen?
Kennzeichne ich fehlende Informationen als ungeklärt?
Trenne ich Anforderungen und Lösungsideen?
Treffe ich noch keine unbegründete Produktauswahl?
Habe ich die Analyse der vorhandenen Infrastruktur für LF3.2 offengelassen?
Habe ich IP-Adressierung und Subnetting für die späteren Lernetappen offengelassen?

REFLEXION

Reflexion

Können Sie jetzt erklären:

warum eine allgemeine Aussage wie „Der Rechner braucht Netzwerk“ für eine Integration noch nicht ausreicht,
warum ein Leistungskriterium überprüfbar sein muss,
warum Anforderung und technische Lösung nicht dasselbe sind,
warum unbekannte Infrastrukturinformationen nicht erfunden werden dürfen,
welches Arbeitsergebnis LF3.1 an LF3.2 übergibt?

Quellen & Einordnung

Curriculum-Grundlage:
KMK-Rahmenlehrplan für Fachinformatikerinnen und Fachinformatiker, Lernfeld 3.

KMK-Rahmenlehrplan öffnen

Curriculare Einordnung:
LF3 beginnt mit dem Erfassen der Anforderungen an die Integration von Client-Soft- und -Hardware in eine bestehende Netzwerkinfrastruktur und der Ableitung von Leistungskriterien.

Methodische Einordnung:
Das Anforderungsraster, das Prioritätsmodell, alle Kundenäußerungen, Leistungskriterien, Praxisfälle, MC-Fragen, Antwortoptionen und Lösungen wurden eigenständig für SemaTrain entwickelt.

Für diese Lernetappe ist keine zusätzliche Rechtsquelle erforderlich.

Curriculare Abgrenzung:
Die konkrete vorhandene Netzwerkinfrastruktur wird erst in LF3.2 untersucht. Netzwerkkomponenten, Adressierung, Subnetting und Konfiguration werden in späteren Lernetappen aufgebaut.

Nächster Lernschritt

Die Anforderungen und Leistungskriterien sind nun dokumentiert.

Als Nächstes wird untersucht, welche Netzwerkinfrastruktur bei K-27 tatsächlich vorhanden ist.

LF3.2 – Bestehende Netzwerkinfrastruktur erfassen öffnen