Anforderungen und technisches Design als Einzelaufwand?

Question

Ich habe an einem großen, mehrjährigen Projekt als Webarchitekt gearbeitet.

Bislang war ich dafür verantwortlich, die vom Analysten des Kunden bereitgestellten Anforderungsdokumente zu übernehmen und sie in die technische Dokumentation zu übertragen.

Die "Kräfte, die das sind" legen nahe, dass ich die Anforderungsdokumentation übernehme und sie mit meinen Bemühungen um technisches Design kombiniere.

Gibt es ein spezifisches Problem bei der Kombination von Anforderungen und technischem Design in einem Schritt?

Beachten Sie, dass wir uns bereits gut in der Entwicklung befinden, so dass viele der technischen Optionen (Betriebssystem, App-Framework, Datenbank, Server usw.) bereits in Stein gemeißelt wurden.

Answer 1

"Gibt es ein spezifisches Problem, das Sie bei der Kombination von Anforderungen und technischem Design in einem Schritt sehen?"

Ja.

Anforderungen haben mit technischem Design fast nichts zu tun.

Anforderungen definieren "was" muss passieren. Design erklärt, "wie" es gebaut wird, um dies zu ermöglichen.

Zum Beispiel möchte ich ein Bier - das ist meine Anforderung.

Technisches Design könnte

1. meinen Stuhl Runter und nach unten gehen. Kostengünstig. Hier besteht ein Risiko. Es darf kein Bier geben.

2. Gehen Sie von meinem Stuhl und gehen Sie zum Pub. Höhere Kosten. Hier besteht ein geringes Risiko. Außer sonntags, wenn es geschlossen ist.

3. Frage meine Frau. Großes Risiko hier. Mögliche unbeabsichtigte Folgen. Allerdings habe ich das Problem delegiert und sie muss nun entweder Bier im Haus finden, in den Laden rennen oder mir sagen, dass ich mein eigenes holen soll. Wenn sie sowieso ausgeht, sind wir zurück zu niedrigen Kosten und ohne Risiko.

Eine Anforderung. Mehrere Designs für Lösungen. Sie können nicht in einem Schritt an beiden Dingen arbeiten.

Sie müssen Anforderungen (Akteure, Anwendungsfälle, konzeptionelles Datenmodell, konzeptionelles Verarbeitungsmodell) dokumentieren

Sie müssen dann eine Lösung entwerfen. Die Lösung kann - oder auch nicht - die Erstellung neuer Software beinhalten.

Bei der Untersuchung von Anforderungen finden Sie häufig Situationen, in denen die Benutzer ihre Arbeitsweise ändern müssen. Anforderungen können auf mehrere Arten erfüllt werden.

Eine Person kann sowohl die Anforderungen dokumentieren als auch das Design erstellen. Aber Sie müssen sie separat machen. Sie müssen die Anforderungen so dokumentieren, dass die Benutzer die Art des Problems verstehen und ihm zustimmen, und was erforderlich ist, um das Problem zu lösen.

Dann - getrennt - entscheiden Sie, wie Sie die Kosten, das Risiko, die Lieferzeit, die Fähigkeiten und die verfügbare Technologie am besten optimieren, um einige Lösungen für das Problem anzubieten.

Answer 2

Wenn Sie "in Entwicklung" sind, würde ich hoffen, dass die Mehrheit der Anforderungen ziemlich fest ist. Ich behaupte nicht, dass die Anforderungen in Stein gemeißelt werden müssen, bevor die Entwicklung beginnt (Gott bewahre), aber ich hoffe, dass es ziemlich sicher ist, was Sie bis zu diesem Punkt aufbauen. Wenn der Punkt jetzt nur "Anforderungsdokumentation" ist (anstatt wirklich herauszufinden, wonach der Kunde sucht), kann ich hier kein tiefgreifendes Problem sehen.

Obwohl es einen gewissen Vorteil gibt, die Entwicklung von der Rolle eines Kunden zu trennen, sollte ein professioneller Entwickler keine Schwierigkeiten haben, die Anforderungen zu verfolgen, ohne Interessenkonflikte zu erzeugen. Gibt es ein anderes Problem, um das Sie sich Sorgen gemacht haben? Ist die Anforderungsdokumentation an dieser Stelle noch eine große Aufgabe? Die Reduzierung der Anzahl der Schichten zwischen dem Kunden und dem Entwickler klingt nach einer ziemlich guten Sache.

Answer 3

Ich denke, es ist sehr wertvoll, dass Anforderungen und Design von den gleichen Leuten erledigt werden.

Wenn Sie Anforderungen erhalten, werden Sie tatsächlich mit dem Geschäft sprechen. Es gibt Ihnen eine Chance, das Geschäft zu lernen und zu hören, was sie wirklich brauchen, ungeschminkt und ungefiltert. Sie werden die Möglichkeit haben, sie davon zu überzeugen, dass sie das Problem in geschäftlicher Hinsicht besprechen, anstatt eine technische Lösung anzunehmen und direkt zum Design zu springen (zB "Diese Spalte zu dieser Tabelle hinzufügen und an dieses Textfeld auf dieser Seite binden").) Vielleicht wirst du Wege finden, ein Problem anzugreifen, von dem sie nicht einmal wussten, dass es existiert.

Answer 4

Ich habe nicht die Möglichkeit, in einem agilen Team oder Scrum-Team zu arbeiten, noch habe ich die Möglichkeit, sie anzuwenden. Ich mache viele einmalige Entwicklungsarbeiten für Kunden für 1 ~ 3 Monate. Aber eine Sache, die ich gelernt habe, wenn in dieser Art von Umgebung ist:

Abmelden mit dem Kunden jede Phase des Projekts.

Welches wird Ihre Frage beantworten als: Niemals Anforderungen mit Design-Dokument zu mischen.

Eigentlich geht es darüber hinaus.

1. Als Erstes den Arbeitsumfang (SoW) abzeichnen.
2. Dann die Anforderungen abzeichnen.

Wir haben in vielen Zeiten unvernünftige Kunden gesehen, die sich ständig ändernde Anforderungen haben. Sie erwarten jedoch nicht, dass diese Änderungen bezahlt werden. Wenn die Projektkosten nicht ordnungsgemäß verwaltet werden, werden die Projektkosten überwiegen und das Projekteinkommen übersteigen.

Mit einem abgemeldeten SoW schützen Sie sich vor Out-of-Scope-Anforderungen, z. "Der Anbieter wird die App xxx installieren", und plötzlich möchte der Kunde eine vollständige PKI-Infrastruktur installieren, um die Kommunikation mit der App xxx zu schützen.

Wenn Sie eine abgemeldete Anforderung haben, werden Sie vor plötzlichen und unangemessenen Anforderungen geschützt. Nach einem ähnlichen Fall von oben ist es nicht erforderlich, die Kommunikation mit der App xxx zu schützen und zu verschlüsseln.

Beachten Sie, dass dies ein Rechtsschutz ist. Es liegt immer noch bei Ihnen zu entscheiden, ob eine neue Anforderung von dem Client erfüllt werden soll. Es ist jedoch immer noch gut zu betonen, dass sie nicht in den Anforderungen sind und rein aus gutem Willen gemacht werden.

Das Zusammenführen des Designdokuments mit dem Hauptanforderungsdokument verhindert, dass Sie das Anforderungsdokument abzeichnen. Der Kunde wird sich darüber sehr freuen, aber ich denke, dass Ihr Entwicklungsteam die mögliche Knackzeit hassen wird.

Ich habe einen alternativen Ansatz gesehen, den die Leute haben (aber nicht das Design mit den Anforderungen verschmelzen).

Das Anforderungsdokument in eine Hauptdatei mit separaten Anhangsdateien aufteilen. Halten Sie wichtige und konkrete Dinge im Anforderungsdokument. Auf diese Weise können Sie das Anforderungsdokument abzeichnen und Änderungen im Anhang zu einem späteren Zeitpunkt vornehmen. Wir verwenden diesen Ansatz hauptsächlich für Support-Dokumente als Anhang. Es könnte mit Design-Dokument als Anhang arbeiten, aber ich habe ein Design-Dokument nicht als Anhang gesehen.

Außerdem möchten Sie vielleicht in einigen Projekten das Designdokument vor dem Start der Entwicklung abzeichnen. Oder diese Design/Anforderungen/SoW sind Lieferung oder Meilensteinzahlung.

Wirklich, versuchen Sie zu vermeiden, sie zu verschmelzen.

Answer 5

Anforderungen beziehen sich auf was getan werden muss. Technisches Design bezieht sich auf wie die Anforderungen erfüllt werden können.

Nachteile:

• Ein Nachteil, sie zu kombinieren ist , die, wenn Sie einen technischen Kerl sind, Sie versuchen, finden Sie die Anforderungen beeinflussen die technische Aufgabe zu erleichtern, auf Fokussierung wie. In das Ende, Sie könnten ein System entwickeln, die tatsächlich nicht behandelt (alle) die Probleme des Benutzers (s) dieses System.
• Ein weiterer Nachteil besteht darin, dass, während zur Klarstellung der Anforderungen, die technische Lösung angepasst erfüllen die neuen Funktionen/Details benötigt werden, die oder entdeckt während Anforderungen elicitation geklärt wurden. Das bedeutet die technische Lösung mehrmals während Anforderungserklärungen ändern/überdenken.

Mögliche Vorteile:

• einen Überblick über die technische Lösung, während die Anforderungen zu diskutieren, man könnte „bend“ oder verhandeln die Anforderungen, um spätere Entdeckung der technischen Probleme vermeiden (zB Leistungs Probleme, nicht realisierbare oder kostspielige Merkmale mit einem Mehrwert, der nicht proportional zu den Kosten ihrer Durchführung ist. Aber Sie müssen aufpassen, dass Sie nicht zu viel in das technische Design investieren, bevor die Anforderungen wirklich geklärt sind.

Answer 6

Ja. Die Kombination von Anforderungen und technischem Design lässt Ihr Denken hinter sich - es verhindert, dass Sie später neue Ideen zur Verbesserung des Systems durch eine andere technische Herangehensweise/Optimierung entwickeln.

Besonders in neuen Technologiebereichen können Sie sehr gut mit dem falschen Ansatz beginnen. Die Kombination des technischen Designs und der Anforderungen veranlasst Sie, Ihren technischen Ansatz als eine Anforderung zu betrachten, wenn sie sehr gut verschrottet und anders gemacht werden könnte.

Wenn es an der Zeit ist zu testen (eigentlich sollte die Zeit vor dem Entwurf sein), dann testen Sie vielleicht Ihren technischen Ansatz und nicht das, was das Programm tatsächlich tun muss.

Answer 7

Ein weiterer Unterschied in den beiden ist, dass die Entwicklung der Anforderungen umfassenden Kontakt mit dem Kunden erfordert (externe oder interne Client) und viele gute Techniker haben nicht die Menschen Fähigkeiten, um Kundenbeziehungen gut zu verwalten oder mit actaul Benutzer ohne zu sprechen sie beleidigen. Nur du kannst es sagen, wenn du es tust. Sie werden feststellen, dass es viel schwieriger und komplizierter ist als Sie denken, wenn Sie es nicht getan haben. Außerdem können Sie die falschen Fragen stellen, weil Sie die Sichtweise des Benutzers nicht sehen können, da Ihre Expertise aus der Sicht des Entwicklers und Designers ist.

Persönlich finde ich auch, dass mehrere Personen in den Designprozess einbezogen (Anforderungen sammeln und in ein Design übersetzen) hilfreich in Bezug auf die Ideengenerierung und in Bezug auf das Denken der Dinge die andere Person möglicherweise verpasst haben. Der Wechsel von zwei Leuten zu einem mag keine gute Idee vom Standpunkt der Team-Synergie sein. Wenn dieselbe Person beides tut, ist es einfach, Dinge nur so zu tun, wie Sie es gewohnt sind, und es ist niemand sonst involviert, Ihre Annahmen in Frage zu stellen, bis Sie viel weiter auf dem Weg sind, wo es schwieriger wird, sich zu ändern.