Erheben von Anforderungen als Kunde

Hintergrund: Ich bin Informatikstudent und arbeite derzeit als Programmierer für eine Gesundheitseinrichtung. Kürzlich entdeckten wir die Notwendigkeit für ein Projekt, das über einen 1-Mann-Job hinausgeht (ich bin ihr einziger Programmierer), also bat mich mein Chef, seine Arbeitsgruppe zu unterstützen, um ein klares Verständnis unserer Anforderungen zu bekommen, die wir dann in eine Software umsetzen würden Unternehmen.

Wir sind jetzt in einer Phase, in der wir einige Angebote von 2-3 Softwarefirmen einholen möchten, um abzuschätzen, wie viel Funktionalität wir für wie viel Geld bekommen können (was beides innerhalb einer gewissen Marge flexibel ist), und ich fange an zu fragen wie detailliert wir wissen müssen, was wir wollen, bevor wir dies tun.

Um das maßstabsgetreu darzustellen: Wir begannen mit der Idee, dass „wir diesen Papierstapel loswerden und Dinge direkt in einen Computer eingeben müssen, um den Prozess zu beschleunigen“, und haben jetzt ein 11-seitiges Anforderungserhebungsdokument mit einer ziemlich genauen Beschreibung dessen, was wir betriebswirtschaftlich erreichen möchten, plus einige nicht-funktionale Anforderungen, aber keine Use-Case-Spezifikationen oder GUI-Mock-ups, die den geänderten Geschäftsprozess zeigen.

Da das Anforderungserhebungsdokument normalerweise einen ziemlich großen Teil eines jeden Softwareprojekts ausmacht, frage ich mich, wo ich aufhören soll. Würden Sie mir empfehlen, einige Anwendungsfälle zu entwerfen, um eine noch bessere Vorstellung zu bekommen, oder würde ich nur die Arbeit des Auftragnehmers machen?

Antworten (4)

Es hört sich so an, als hätten Sie bei der Beschreibung der Anforderungen großartige Arbeit geleistet. Mein Vorschlag ist, zu beurteilen, warum Sie die externe Firma einstellen. Wenn Sie nach neuen Ideen und Innovationen suchen, achten Sie darauf, dem Unternehmen nicht zu „sagen“, was es in den Anforderungen zu tun hat. Wenn Sie jemanden suchen, der die Arbeit erledigt, müssen Sie alle Funktionen und Prozesse detailliert beschreiben.

Wenn Sie sich nicht sicher sind, warum, dann gehen Sie zu Ihrem Chef und klären Sie das ab. Wenn Sie ein Unternehmen mit dem Schleifen beauftragen und es sich um eine innovative Designgruppe handelt (oder umgekehrt), werden Sie Schwierigkeiten haben, erfolgreich zu sein.

+1 Hervorragende Auszeichnung; Stellen Sie Arbeiter ein oder Menschen mit Kreativität und einer kostenlosen Lizenz?

Ziehen Sie keine Grenze zwischen sich und Ihren Auftragnehmern. Versuchen Sie stattdessen, eine offene Umgebung einzurichten, in der Informationen über Anforderungen effektiv zwischen allen Parteien fließen. Das Dokument über die Anforderungen (entweder eine Reihe von UML-Diagrammen oder MS-Word-Dateien oder was auch immer) muss zu einer Live-Plattform für die gesamte Kommunikation zwischen allen Projektbeteiligten werden.

Und auch hier sollten Sie nie aufhören, Anforderungen zu ermitteln und das Dokument zu entwickeln. Lesen Sie mehr über iterative und inkrementelle Paradigmen der Softwareentwicklung . Außerdem würde ich empfehlen, das Prozessgebiet Anforderungsentwicklung von CMMI for Development 1.3 zu lesen .

Grundsätzlich gibt es zwei Ansätze, die Sie hier verwenden können:

  1. Versuchen Sie, ziemlich genau zu sagen, was Sie brauchen. Wenn Sie Ihre Anforderungen gut kennen, versuchen Sie einfach, alles aufzuschreiben, was Sie wissen oder zu wissen glauben. Es ist wichtiger, Ihr Wissen auf irgendeine Weise zu Papier zu bringen und nicht die genaue Art und Weise, wie Sie es zu Papier bringen. Fügen Sie also einige Anwendungsfälle hinzu, aber nur solange Sie glauben, dass es einen gewissen Wert hat, was im Grunde bedeutet, dass sowohl Sie als auch ein Anbieter besser wissen, was Sie bauen.

    Beachten Sie auch, dass eines der großen Probleme bei Projekten oft darin besteht, den Umfang von einer Seite misszuverstehen oder falsch zu interpretieren oder mit anderen Worten falsche Annahmen zu treffen. Das bedeutet, je detaillierter der Umfang ist, desto besser.

  2. Alternativ können Sie einfach die Tatsache akzeptieren, dass der Zeitpunkt, an dem Sie am wenigsten über das Projekt wissen, am Anfang steht (in Ihrem Fall jetzt), und planen, dass sich der Umfang bis zu einem gewissen Punkt ändern kann. Dann möchten Sie einen Anbieter finden, der das Projekt agil aufbauen möchte. Kurz gesagt, sie bauen das Projekt iterativ auf und Sie entscheiden, was als nächstes hinzugefügt werden soll, basierend auf dem, was Sie bereits haben, und nicht nur auf der Idee, die Sie ganz am Anfang hatten.

    Auf diese Weise erhalten Sie wahrscheinlich das, was Sie wollen, aber Sie teilen auch die Folgen häufiger Änderungen des Umfangs, da Sie im Grunde dafür bezahlen würden. Dies liegt daran, dass diese Art von Verträgen zumindest bis zu einem gewissen Punkt auf Zeit- und Materialregeln basieren.

Als Faustregel gilt: Je sicherer Sie sich darüber sind, was Sie erreichen möchten, desto mehr sollten Sie sich zum ersten Szenario neigen und umgekehrt: Wenn Sie sich nicht genau sicher sind, was Sie bauen möchten, sollten Sie das zweite Szenario als Möglichkeit in Betracht ziehen gehen.

Um Perrys ausgezeichnete Antwort zu ergänzen, möchte ich sagen, dass der Detaillierungsgrad, den Sie in den Anforderungen benötigen, in vielerlei Hinsicht vollständig von den Kenntnissen der Auftragnehmer abhängt. Um nur einige zu zitieren:

  1. Kennen sie das Fachgebiet?
  2. Arbeiten sie normalerweise in diesem Maßstab (unterschreitet es ihr 08/15-Projekt, genau das, was sie tun, oder ist es weit hergeholt)?
  3. Wie arbeiten sie am liebsten? Einige Jungs sind gut darin, ihre eigenen Anforderungen zu bekommen, andere müssen sie buchstabieren.

Die andere Möglichkeit, es vollständig zu betrachten, ist ein risikobasierter Ansatz. Welche Risiken bestehen, wenn bei einem bestimmten Anforderungsprofil etwas schief geht, was steht auf dem Spiel? Ein Kapitel, das für Ihren Betrieb kritischer ist (höhere Kosten, wenn etwas schief geht), muss detaillierter sein. Ein weniger kritisches Kapitel benötigt weniger Details.

In einem besonders wichtigen Teil Ihrer Anforderungen könnte die Beschreibung dessen, was der Benutzer erwartet (oder zumindest welche Vorteile der Benutzer erwartet), eine gute Möglichkeit sein, die Absicht zu vermitteln. Nennen Sie es einen Anwendungsfall, wenn Sie so darüber nachdenken, aber es muss nicht unbedingt so formell sein.


In Bezug auf die Arbeit des Auftragnehmers gibt es keine Regel, die besagt, dass Sie Ihren Teil nicht leisten können, wenn Sie das Wissen haben. Denken Sie jedoch daran, dass einige Auftragnehmer ihre Ideen vorbringen möchten, sodass Sie möglicherweise Arbeit leisten, die verschwendet wird. Oder es kann der Fall sein, dass es Ihnen Zeit und Mühe erspart, wenn ihnen gefällt, was Sie getan haben. Das hängt von der Beziehung ab, die Sie mit dem ausgewählten Auftragnehmer aufbauen werden, davon, wie gut Ihre Arbeit für sich steht und wie gut Sie oder Ihr Chef den Vertrag aushandeln werden.

Ich habe einem ehemaligen Arbeitgeber von mir das 8-fache meines Jahresgehalts gespart, indem ich 3-monatige Tests durchgeführt habe, die daher von unserem Hauptlieferanten nicht wiederholt werden mussten. Bei unserem Lieferanten lief es nicht so gut, aber 1/ sie akzeptierten schließlich die Tatsachen und bekamen danach trotzdem mehr Aufträge; 2/ Meine Chefs waren glücklich.

Diese kleine persönliche Geschichte, um nur zu sagen, dass die Umstände auf Ihrer Seite sein können oder nicht, und dass es sich immer auszahlen sollte, Ihrem Chef Geld zu sparen, auch wenn es auf Kosten etwas schwierigerer Beziehungen zu Ihrem Lieferanten geht.