User Modules

Die Anfragen sind Teil des Projektmanagements. Für mehr darüber, was in die Projektmanagementagenda einfließt, siehe hier. Anfragen sind so konzipiert, dass Sie damit die Eingabe dokumentieren, die Analyse verarbeiten und die Bearbeitung des gesamten Projekts steuern können.

Eingabe und abgeleitete Anfragen

Eingabeaufforderungen eines Projekts sind Anfragen, die von einer externen Umgebung kommen, typischerweise vom Kunden, dem Projektsponsor oder dem Team, das das Projekt erfunden hat. Sie werden allgemein Benutzeranfragen genannt.

Im Gegensatz zu Eingabeanforderungen werden die requests abgeleitet, d.h. diejenigen, die in einem Projekt aufgrund einer Analyse der Projektausführung entstanden sind. Abgeleitet werden alle Anfragen, die aus Eingabeanfragen oder anderen Eingaben an das Projekt entstanden sind. Ein typischer Input, der Anforderungen generiert, ist eine Verpflichtung, eine Methodik, nur selten etwas anderes.

Arten von Anforderungen

Die Einteilung in Input-abgeleitete Anforderungen resultiert daraus, wie die Anforderungen entstanden sind. Eine ausführlichere Einteilung, die unten beschrieben wird, wird meistens für abgeleitete Anforderungen verwendet. Natürlich machen nur einige Arten von Anforderungen Sinn in einem Projekt, je nachdem, was der Zweck (Produkt) des Projekts ist.

User – wir haben es schon beschrieben. Sie sind immer Input-Anforderungen
System – Anforderungen, die für die gesamte Lösung, das System, gelten (natürlich nur, wenn ein System in einem Projekt entsteht, bleibt dies auch weiterhin der Fall)
Software – Anforderungen, die die in einem Projekt erstellte Software erfüllen muss/muss. Sie sind keine Anforderungen an die Software, die zum Ausführen eines Projekts verwendet wird, sondern die
_ Hardware – Anforderungen, die der elektronische Teil eines Projekts, in der Regel die Hardware, erfüllen muss
Engineering – Anforderungen an das im Projekt erstellte oder entwickelte Design. Abhängig von der Art des Projekts, kann dies ein mechanischer Teil in der Entwicklung sein, oder vielleicht eine bevorstehende Bauausführung.
Prozess – Anforderungen an den Prozess der Umsetzung der Anforderung. Dies sind spezifische Anforderungen, wie eine bestimmte Aktivität oder Stufe umgesetzt werden soll, wer daran teilnehmen soll usw. Beachten Sie, dass sie die Methodik, nach der das Projekt implementiert wird, nicht wiederholen sollten. Wenn die Methodik also ein Erfordernis für eine Verfahrenshandlung, z. B. eine Revision, vorsieht, sollte es nicht erforderlich sein, diese als verfahrensrechtliche Anforderung umzuschreiben (dies kann als Verpflichtung oder Modellaufgabe in der Methodik aufgefasst werden).
_ Tests / Tests – Anforderungen an Tests, Verifikation und Prüfung der Ergebnisse eines Projekts. Die Anforderungen sollten gemeinsam definieren alles, was getan werden, um die Qualität der Arbeit zu überprüfen. (Entsprechend der Methodik kann sie auch Tests von Eingabegeräten umfassen, z.B. Kalibrierung von Messgeräten. Meistens sind diese Anforderungen an die Eingabekontrolle jedoch direkt Teil der Methodik oder sollten prozedurale Anforderungen sein, da sie eine Prozesskontrolle und keine Ausgabekontrolle sind.)
Business / Business – Anforderungen, die sich aus dem geschäftlichen Aspekt des Projekts ergeben. Typischerweise sind dies Anforderungen, die sich aus geschäftlichen Bedürfnissen ergeben (sie können sich auf Design, Produktionskosten usw. beziehen). Hüten Sie sich vor der Unterscheidung zwischen Anforderungen und Pflichten. Wenn zum Beispiel die geschäftliche Aufgabe darin besteht, dass das entwickelte Produkt Produktionskosten von weniger als 10 EUR verursacht, ist es gut, dies als Verpflichtung zu verstehen, die das Projekt erfüllen muss. Diese Verpflichtung spiegelt sich in allen Aktivitäten von der Projektplanung bis zur Auswahl der Auftragnehmer wider, und man kann nicht eindeutig sagen, dass sie durch etwas erfüllt wird.

Anforderungsanalyse

Sind die Anforderungen und insbesondere das zu entwickelnde System komplexer, ist es nicht möglich, ein Projekt direkt auf Basis der Nutzeranforderungen zu entwickeln/umzusetzen. Diese Anforderungen müssen durchdacht, nach Ort, Art und Weise sowie durch wen sie umgesetzt werden, und oftmals detailliert aufgeschlüsselt werden. Diese Schritte nennt man Analyse. Innerhalb der Analyse ergeben sich daraus abgeleitete Anforderungen.

Analytische Beziehungen

Systemanforderungen ergeben sich aus Nutzeranforderungen (System)
Systemanforderungen ergeben sich aus einzelnen Teilen des Systems, die oft bereits nach der Art der einzelnen Teile des Systems (Engineering Design – Technologie Teil, Software, Hardware) aufgeteilt.
Die Anforderungen an Systemteile können weiter in Unterteile zerlegt werden, aber es ist besser, dies zu vermeiden und keine weitere Schicht zu erzeugen. Allerdings, wenn es ein großes System ist, kann es erforderlich sein,
Testanforderungen können sowohl Input-und abgeleiteten Anforderungen sein. Wenn sie abgeleitet werden, sind sie das Ergebnis einer Analyse, was verifiziert werden muss, um typisch qualitative Kriterien zu erfüllen.

Wie werden Beziehungen dokumentiert

Beziehungen werden durch eine trace / trace Bindung dokumentiert. Eine Bindung ergibt sich immer aus einer Anforderung, die zu einer neuen, abgeleiteten Anforderung führt. Links werden einfach über die Befehlstasten in der Anfragedatei erstellt.

Status anfordern

Die Verarbeitung einer Anfrage wird durch den Status gesteuert. Die Status der Anfragen sind:

Neu – noch nicht analysiert und noch nicht verarbeitet
In Analyse – Analyse in Arbeit, aber noch nicht abgeschlossen
Analyzed – Eine Analyse wurde durchgeführt, sollte aber verifiziert werden.
Verified (verified) – Eine Prüfung wurde durchgeführt, wie es analysiert wurde. Eine Anfrage kommt nur dann in einen Schritt, wenn sie von einer anderen Person als der zuständigen Person analysiert wird (die verantwortliche Person ist in der Anfrage angegeben). Wird er direkt von der verantwortlichen Person analysiert, wird der Verifikationsschritt übersprungen.
Fertiggestellt – Analyse abgeschlossen. Beendeter Status bedeutet nicht, dass die analysierte Lösung implementiert ist, sondern dass die Analyse der Implementierung abgeschlossen ist
In disarray – Die Anfrage kann nicht analysiert werden, weil etwas sie verhindert. Typische Gründe, warum die Anfrage ist in Unordnung sind
Die Anfrage steht im Gegensatz zu anderen Anforderungen und kann daher nicht alles erfüllt werden
Die Anfrage steht im Widerspruch zu Einschränkungen, die nicht geändert werden können. Sie verstößt zum Beispiel gegen allgemein geltende Vorschriften oder kann nicht im Preis des Werkes umgesetzt werden.
Zurückgewiesen – die Anfrage wurde von der Verarbeitung ausgeschlossen. Der Ausschlussgrund sollte immer angegeben werden. Typische Gründe für den Ausschluss sind:
Die Anfrage wird mit einer anderen Anfrage dupliziert, die adressiert wird
Der Antrag wurde von einer Person gestellt, die nicht berechtigt ist, den Antrag zu stellen
Storniert – die Anfrage wurde durch die Entscheidung des Sponsors storniert

Synchronisation von Anfragen an Enterprise Architect

Die Requests und andere Elemente der Analyse können automatisch [mit dem Modell in Enterprise Architect synchronisiert] werden (/doc/en/eacon/eaconAbout). Mit der Synchronisierung können Sie die Vorteile eines webbasierten Input-Zugriffs für das gesamte Projektteam sowie die vollen Analysemöglichkeiten Ihres bevorzugten Tools kombinieren.