it-swarm.com.de

Sind Drahtgitter für die Anforderungsdokumentation geeignet?

Die Leute für Design, Entwicklung und Test führen derzeit ein Gespräch über die Anforderungen.

Ein Teil des Gesprächs befasst sich mit dem Zweck und der Verwendung von Drahtgittern. Unser Change Analyst ist entschieden dagegen, Wireframes als Teil der Anforderungen für Entwicklung oder Test zu verwenden. Sie dürfen nur bei Bedarf für "zusätzliche Informationen" verwendet werden - "etwas, auf das Bezug genommen werden soll", um die Übersichtlichkeit zu gewährleisten.

Kurz gesagt: Verwenden Sie schriftliche Anforderungen, nicht visuelle.

Sollten Drahtgitter als Teil des Anforderungs- und Dokumentationsprozesses verwendet werden?

Hat einer von Ihnen jemals in einem Team gearbeitet, in dem Wireframes die Hauptanforderungen für die Entwicklung und/oder das Testen waren?

Bearbeiten: Ich habe eine Tendenz zugunsten der Verwendung von Drahtgittern als formale Anforderungsdokumentation. Ich verbrachte ein paar Jahre in einer Umgebung, in der sie die einzige Form der Dokumentation von Anforderungen waren - die Entwicklung begann erst, als die Produktbesitzer (agile Einstellung) die Drahtgitter abzeichneten. Sehr effizient in dieser Einstellung.

13
gef05

Ich denke, Sie riskieren hier die Debatte zwischen Anforderungen und Design. Wireframes sind ziemlich wichtig, aber ich denke, es hängt davon ab, wie Sie sie konzipieren. Das Folgende ist meine eigene Meinung, wird aber meiner Erfahrung nach durch ziemlich übliche Branchenprozesse gestützt.

  • Anforderungen sollten im Allgemeinen nur geschrieben werden, weil Sie beschreiben, was eine Lösung tun muss. Sie sollten ausreichend detailliert sein, um alle erforderlichen Schritte klar zu beschreiben, und sollten je nach Art des Produkts, für das sie bestimmt sind, in logische Bereiche unterteilt werden.
  • Wireframes sind Teil des Entwurfsprozesses, da sie beschreiben, wie sich die Lösung verhalten muss, um die Anforderungen zu erfüllen. Manchmal müssen Sie möglicherweise eine mentale Karte oder ein Knotendiagramm entwickeln oder etwas zeichnen, damit ein Client seine Anforderungen klarer beschreibt, aber das ist nicht der Zweck eines Drahtgitters.
  • In Projekten, in denen jemand herausgefunden hat, wie eine Anwendung fließen soll, und/oder Drahtmodelle (die im Wesentlichen Elemente auf einer Benutzeroberfläche platzieren) direkt im Voraus erstellt werden soll, wird der Entwurfsprozess ausnahmslos verzerrt, und IMHO wird normalerweise erheblich geändert oder ganz verworfen.

Anforderungen werden normalerweise (natürlich nicht immer) von einem Geschäftsanalysten oder PM und nicht von einem benutzerzentrierten Designer) geschrieben. Manchmal überschneiden sich diese Rollen und die Leute können beides gut, aber wo die Rollen sind Differenzierte Wireframes als Teil der Anforderungen funktionieren meiner Erfahrung nach normalerweise nicht. Aus der Notwendigkeit heraus kommen sie später, wenn der Kunde festgelegt hat, was das Produkt tun muss, und nicht, wie es es tun soll.

12
jameswanless

Ich benutze Storyboards in PowerPoint in Semi-High-Fidelity. Ich finde, dass die schriftliche Dokumentation große Mängel aufweist.

  1. Menschen können nicht emotional auf Interaktivität reagieren, indem sie sich diese aus Text vorstellen. Sie können keinen Absatz darüber schreiben, wie etwas funktionieren wird, und die Menschen die Nuance verstehen lassen des Interaktionsdesigns. Es ist wie das Schreiben "Das Grafikdesign wird mit viel Lila schön sein". Was bedeutet das? Wie können Sie es definieren, ohne es zu zeigen?

  2. Sprache ist scheiße . Ich habe viel weniger persönliche Argumente als per E-Mail. E-Mail (Textkommunikation) hat viel zu viele Chancen für Fehlinterpretationen. Wenn Sie zusammen sind und etwas Visuelles betrachten, laufen die Dinge reibungsloser. Außerdem sprechen viele Ingenieure, die ich kenne, nicht Englisch als Muttersprache. Text wird sehr oft falsch interpretiert.

  3. Sie können keinen Text testen . Sie können ein Storyboard testen und vor die Leute stellen, um Reaktionen zu erhalten. Text funktioniert so nicht.

CAVEAT: Alle Unternehmen haben Macken und besondere Umstände. Sie müssen herausfinden, was für Sie funktioniert. Lassen Sie sich nur nicht sagen, dass etwas falsch ist. Wenn Sie müssen, tun Sie beides und geben Sie die Storyboards heimlich an Ingenieure weiter.

6
Glen Lipka

Meine Frustration als BA ist die mangelnde Klarheit zwischen "Anforderungen", die testbare Einheiten sind, und "Design", die, wenn sie als Teil der Anforderungen erstellt werden, tatsächlich Anforderungen werden. Wenn sich das Unternehmen für ein Low-Fi-Kabel oder ein High-Fi-Drahtmodell abmeldet, haben sie dieses visuelle Element zu ihrer Anforderung gemacht. Jetzt schreibe ich Testskripte, um sicherzustellen, dass das Drahtmodell genau wie im Bild gezeigt generiert wird. Sprechen Sie über Granularität! Die Anforderungen sollten sich auf die FUNKTION der Anwendung beziehen, nicht auf das visuelle Design, es sei denn, das Design hat einen legitimen Geschäftsbedarf - wie ADA, Marketingstandards oder identifizierte Produktivitätsverbesserungen.

In den meisten Fällen verlassen sich Unternehmen und Entwickler auf das Visuelle, da sie ihr Endprodukt ohne dieses nicht konzipieren können. Es ist der Unterschied zwischen dem Lesen eines Buches und dem Ansehen des Videos dieser Anforderungen. Es ist eine schlüpfrige Angelegenheit, mit einem Design zu heiraten, und das Unternehmen beginnt zu bestimmen, wie dieses Design funktionieren soll (Schaltflächen speichern, Fehlermeldungen, Datenerfassung, Navigation usw.). So sehr Entwickler UX auch nicht diktieren sollten das Geschäft, es sei denn, sie sind im Geschäft von UX und Design und dann würde ich mich fragen, warum sie nicht selbst Code schreiben.

Das große Stöhnen wird oft schneller erfasst und dokumentiert, sodass die Entwicklung beginnen kann, was die Frage aufwirft, warum sie überhaupt ausgeschrieben werden. Wenn Entwickler die Anforderungen nicht lesen und mit der Strukturierung der Entwicklung ohne Design beginnen können, ist es wahrscheinlich, dass sie sich nicht für die Überarbeitung von Daten interessieren und die Überarbeitung des Designs weitaus unangenehmer zu ändern ist. Agnostisch gegenüber dem Sammeln von Anforderungen zu sein, bedeutet eine offene Möglichkeit für agnostisches Design - Design, das nicht an eine Plattform und deren Einschränkungen gebunden ist. Wenn Sie den Prozess der Abmeldung bei Wireframes erstellen, richten Sie das Unternehmen so ein, dass es akzeptiert, was Sie bereit sind, ihnen zu geben, anstatt ihnen zu geben, was sie benötigen. Dann geht es bei dem Prozess um die schönen Bilder und nicht um die Funktion der Anwendung.

Auf jeden Fall ... Ich denke, es ist wichtig, dass Ihr UI-Team über ein Drahtmodell verfügt, um alle verschiedenen Interaktionen zu sehen, die Sie im Projekt anzeigen müssen.

Einige Leute sagen, dass es ausreichen sollte, eine schriftliche Beschreibung des Projekts zu haben, aber manchmal kann man nicht das ganze Bild eines Projekts mit nur Worten bekommen.

Insbesondere bei dynamischen Drahtgittern ist es für Designer beispielsweise einfacher, eine Vorstellung davon zu haben, was ein Menü tun soll.

Es ist auch großartig, mit Kunden zusammenzuarbeiten, da diese ein klares Bild davon haben, was Ihr Team für ihr Projekt programmieren möchte.

Dies spart Ihnen eine Menge Zeit bei der Programmierung und bei der Interaktion mit der Benutzeroberfläche. Für mich ist ein gutes Drahtmodell die grafische Darstellung eines guten schriftlichen Dokuments.

Ich habe keinen Zweifel daran, wie wichtig ein gutes, detailliertes und interaktives Drahtmodell ist.

1

Wireframes sind keine Anforderungsdokumentation. Anforderungsdokumente sind keine Drahtmodelle. Sie sind jedoch beide voneinander abhängig und beeinflussen sich gegenseitig.

Ich finde, dass sie am besten parallel zusammenarbeiten. Mit anderen Worten, beide entwickeln sich zusammen (im Gegensatz dazu, dass einer fertig ist, bevor der andere beginnt).

Sie erwähnen, dass Sie Drahtgitter als Anforderungen in einer agilen Umgebung verwenden. Ich denke, das ist wahrscheinlich die Ausnahme. Im Idealfall würde alles in einer agilen Umgebung erledigt.

In diesem Szenario sind Drahtgitter wirklich Serviettenskizzen. Sie sind ein internes Dokument, um eine Idee zu kommunizieren, damit sie sofort erstellt werden kann.

Das Tolle an Agile ist, dass (IMHO), wenn es richtig gemacht wird, der Dokumentationsbedarf im Allgemeinen erheblich reduziert wird und diese spezielle Frage in gewisser Weise weniger relevant wird.

1
DA01

Ich fand die Ideen im Buch "Prototyping: A Practitioners Guide" ein gutes Beispiel dafür, wie manchmal eine schriftliche MRD nicht mehr so ​​nützlich ist wie früher, basierend auf der Idee, dass manchmal Zeigen besser ist als Erzählen. Zugegeben, in den Buchspezifikationen geht es um Prototyping. Ich bin der Meinung, dass die gleichen Ideen auch auf Wireframing übertragen werden können.

  • Prototyping ist generativ: Das heißt, wenn Sie Ihren Prototyping-Prozess (oder unser Wireframing) durchlaufen, durchlaufen Sie Hunderte von Ideen. Einige brillant und andere nicht so brillant. Die weniger brillanten Ideen können jedoch ein Katalysator für brillante Lösungen sein.
  • Prototyping kommuniziert durch Show and Tell.
  • Prototyping reduziert Fehlinterpretationen. Nehmen Sie ein 60-seitiges Anforderungsdokument. Bringen Sie 15 Personen in einen Raum. Gib es aus. Lass sie alle es lesen. Fragen Sie sie jetzt, was Sie bauen. Sie werden 15 verschiedene Antworten erhalten. Stellen Sie sich nun vor, Sie versuchen dasselbe mit einer 200-Seiten-MRD - es wird noch schlimmer ...
  • Das Prototyping schafft eine schnelle Rückkopplungsschleife, die letztendlich Zeit, Mühe und Geld spart und das Risiko reduziert.

Vor diesem Hintergrund wäre das Argument dagegen, dass Prototyping/Wireframing manchmal auch für bestimmte Projekte übertrieben sein kann. Es hängt also wirklich alles vom Projekt ab.

1
Armando

Absolut nicht - Drahtgitter gehören nicht zu den Anforderungen.

Wireframes sind eine großartige Möglichkeit, um:

  • Anforderungen generieren
  • Entwerfen Sie Lösungen für Anforderungen

Aber sie in die Anforderungen zu stellen, ist ein Albtraum, der zu verwirrtem, durcheinandergebrachtem Denken und Dokumentieren führt (oft in Form und Funktion).

Dies ist insbesondere in regulierten Umgebungen oder Verträgen ein Problem. Sehen Sie sich das so an, wenn die Benutzeroberfläche eine Drop-Drop-Liste in eine Listenansicht ändert:

  1. Die Anforderung wird nicht mehr erfüllt und ist standardmäßig ein regulatorischer oder vertraglicher Fehler. Das Produkt funktioniert immer noch einwandfrei, aber der Papierkram ist jetzt eine rechtliche Haftung.
  2. Die Dokumentation muss jedes Mal überarbeitet werden, wenn sich die Benutzeroberfläche ändert - das ist verrückt.
  3. Ich habe vorher für eine Firma gearbeitet, die verrückt genug war, nicht nur Drahtgitter in die Anforderungen zu stellen, sondern auch in die entsprechenden Tests! Dieser Wahnsinn bedeutete, dass bei der Überarbeitung der Benutzeroberfläche mit neuen Designs und Toolkits die gesamte Dokumentation überarbeitet werden musste (was sie in ihren Projektschätzungen nicht berücksichtigt hatten).

Ich gehe davon aus, dass Sie nur Wireframes für die Benutzeroberfläche meinen. Blockdiagramme, Flussdiagramme usw. sind unerlässlich.

0
Mr Blah

Das Endprodukt, das Sie erstellen, ist eine Webanwendung.

Drahtgitter können Sie mit geringem Aufwand auf halbem Weg dorthin bringen. Daher ist es sinnvoll, Drahtgitter als Anforderungen zu verwenden, sofern sie eine ausreichende Granularität zwischen den Schritten aufweisen.

Ansonsten habe ich festgestellt, dass schlecht gemachte Drahtgitter fast so leicht falsch interpretiert werden können wie schriftliche Anforderungen.

Für die Dokumentation aller Abläufe sind jedoch weiterhin schriftliche Anforderungen erforderlich. Ohne sie wird es schwierig, strukturierte Benutzerakzeptanztests und QS-Tests durchzuführen.

0
Jung Lee

Hier können Ihre Anforderungen meiner Meinung nach einfallsreich werden - Bausteindiagramme und Flussdiagramme.

http://www.leacock.com/deliverables/block_diagram_ex2.pdf

Hier wird der Prozess in einem Flussdiagramm erläutert, das wiederum besser ist als nur die Dokumentation. Die Verwendung von Wireframes erfordert Zeit und Budget, um sie zu umgehen. Die Verwendung von Blockdiagrammen und Flussdiagrammen ist jedoch aussagekräftiger und hilft anderen Entwicklern und Teammitgliedern, sich mit der Dokumentation zu beschäftigen.

Meistens mögen es die Leute nicht, Textinformationen zu betrachten, die meiner Erfahrung nach niemanden dazu verleiten, sie länger als 10 Minuten anzusehen. Wir haben ein Projekt für den Kunden durchgeführt, bei dem es vor allem davon profitiert hat, dass Drahtgitter parallel zu Textdaten angezeigt werden. Die Leute begannen zu verstehen, was wir zu dokumentieren versuchen. Aber es erfordert viel Mühe. Der ideale Weg, um Ressourcen intakt zu halten, besteht darin, Flussdiagramme und Blockdiagramme zu verwenden, um sie interessant zu machen.

0
inkmarble