Besseres Wort für optionale Anforderungen? [geschlossen]

Was ist ein besseres Wort für eine optionale Anforderung in der Softwareentwicklung? Der Satz ist widersprüchlich. Ich habe in früheren Projekten "Nicht-Kern-Anforderungen" verwendet.

Der Begriff "außerhalb des Geltungsbereichs" kann möglicherweise verwendet werden. Dies bedeutet, dass die Anforderung in Ihrem Prozess erfasst wurde und nachverfolgt werden kann. Es wurde jedoch festgestellt, dass die Anforderung aus einer Reihe von Gründen, z. B. Budget, Zeitplan, oder Machbarkeit.

Der Ausdruck "optionale Anforderung" wird jedoch häufig verwendet, um etwas zu bezeichnen, das in den Geltungsbereich fällt, aber vom System nicht unbedingt benötigt wird. Es ist ein Maß für die Priorität der Anforderung. Nach meinen Erfahrungen werden Anforderungen häufig als obligatorisch, wünschenswert oder optional priorisiert (obwohl es auch andere Schemata gibt). Damit ein Projekt als vollständig und voll funktionsfähig angesehen werden kann, müssen alle verbindlichen Anforderungen erfüllt sein. Bei ausreichenden Ressourcen würden als nächstes wünschenswerte Anforderungen umgesetzt. Schließlich wäre alles, was als optional angesehen wird, enthalten.

Ich glaube, die Verwirrung ergibt sich aus dem Begriff "Anforderung". In der englischen Sprache ist eine Anforderung "eine Sache, die benötigt wird" oder "eine obligatorische, obligatorische oder notwendige Bedingung". In der Softwareentwicklung ist der Begriff Anforderung lediglich ein dokumentiertes Merkmal eines Softwaresystems. Das Konzept optional und obligatorisch beschreibt die Priorität des dokumentierten Merkmals des Softwaresystems.

Wir bezeichnen sie als "nice to have" -Funktionen im Gegensatz zu Anforderungen.

Für die Dokumentation der Softwareanforderungen ist die Formulierung " Optionale Anforderungen" vollkommen in Ordnung, solange Sie diesen Begriff in Übereinstimmung mit RFC 2119 verwenden .

Wenn Ihr Spezifikationstext Verb anstelle von Adjektiv impliziert, verwenden Sie "MAI" anstelle von "WAHLWEISE".

Da es klein und leicht zu lesen ist, wird der RFC-Text im Folgenden vollständig zitiert:

    Netzwerkarbeitsgruppe S. Bradner
    Anfrage für Kommentare: 2119 Harvard University
    BCP: 14. März 1997
    Kategorie: Best Current Practice


            Schlüsselwörter zur Verwendung in RFCs zur Angabe von Anforderungsstufen

    Status dieser Notiz

       In diesem Dokument werden die Internet-Best-Current-Practices für das Internet festgelegt
       Internet Community und bittet um Diskussion und Vorschläge für
       Verbesserungen. Die Verbreitung dieses Memos ist unbegrenzt.

    Abstrakt

       In vielen Standards werden Track-Dokumente mit mehreren Wörtern bezeichnet
       die Anforderungen in der Spezifikation. Diese Wörter sind häufig
       aktiviert. In diesem Dokument werden diese Wörter so definiert, wie sie sein sollten
       in IETF-Dokumenten interpretiert. Autoren, die diese Richtlinien befolgen
       sollten diesen Satz am Anfang ihres Dokuments einfügen:

          Die Schlüsselwörter "MUSS", "MUSS NICHT", "ERFORDERLICH", "SIND", "SIND"
          NICHT "," SOLLTE "," SOLLTE NICHT "," EMPFOHLEN "," MAI "und
          "OPTIONAL" in diesem Dokument ist wie in beschrieben auszulegen
          RFC 2119.

       Beachten Sie, dass die Kraft dieser Wörter durch die Anforderung geändert wird
       Ebene des Dokuments, in dem sie verwendet werden.

    1. MUSS Dieses Wort oder die Ausdrücke "ERFORDERLICH" oder "MUSS" bedeuten, dass das
       Definition ist eine absolute Anforderung der Spezifikation.

    2. DÜRFEN NICHT Diese Phrase oder die Phrase "DÜRFEN NICHT" bedeuten, dass die
       Definition ist ein absolutes Verbot der Spezifikation.

    3. SOLLTE dieses Wort oder das Adjektiv "EMPFOHLEN" das dort bedeuten
       Es kann unter bestimmten Umständen triftige Gründe geben, a. zu ignorieren
       bestimmter Punkt, aber die vollständigen Auswirkungen müssen verstanden werden und
       sorgfältig abgewogen, bevor Sie einen anderen Kurs wählen.

    4. SOLLTE NICHT heißen, dass dieser Ausdruck oder der Ausdruck "NICHT EMPFOHLEN"
       Unter bestimmten Umständen kann es triftige Gründe geben, wenn
       bestimmtes Verhalten ist akzeptabel oder sogar nützlich, aber die volle
       Implikationen sollten verstanden und der Fall sorgfältig abgewogen werden
       bevor Sie ein mit diesem Etikett beschriebenes Verhalten implementieren.

    5. MAI Dieses Wort oder das Adjektiv "OPTIONAL" bedeutet, dass ein Gegenstand ist
       wirklich optional. Ein Anbieter kann den Artikel einschließen, weil a
       Ein bestimmter Markt erfordert dies oder weil der Anbieter dies fühlt
       Es verbessert das Produkt, während ein anderer Anbieter möglicherweise denselben Artikel weglässt.
       Eine Implementierung, die keine bestimmte Option enthält, MUSS sein
       bereit, mit einer anderen Implementierung zusammenzuarbeiten, die dies tut
       Fügen Sie die Option hinzu, jedoch möglicherweise mit eingeschränkter Funktionalität. In dem
       Das gleiche gilt für eine Implementierung, die eine bestimmte Option enthält
       MUSS bereit sein, mit einer anderen Implementierung zusammenzuarbeiten, die
       beinhaltet nicht die Option (außer natürlich für die Funktion
       Option bietet.)

    6. Anleitung zur Verwendung dieser Imperative

       Imperative der in diesem Memo definierten Art müssen mit Vorsicht verwendet werden
       und sparsam. Insbesondere DÜRFEN sie nur dort verwendet werden, wo sie sind
       tatsächlich für die Interoperation erforderlich oder um das Verhalten zu begrenzen, das hat
       potenzielle Schadensursache (z. B. Einschränkung von Neuübertragungen)
       Sie dürfen beispielsweise nicht verwendet werden, um eine bestimmte Methode aufzuzwingen
       bei Implementierern, bei denen die Methode für die Interoperabilität nicht erforderlich ist.

    7. Überlegungen zur Sicherheit

       Diese Begriffe werden häufig verwendet, um das Sicherheitsverhalten anzugeben
       Implikationen. Die Auswirkungen auf die Sicherheit, wenn kein MUSS implementiert wird oder
       SOLLTE oder sollte etwas getan werden, das in der Spezifikation NICHT angegeben ist
       NICHT getan werden kann sehr subtil sein. Dokumentautoren sollten sich die Zeit nehmen
       um die sicherheitstechnischen Auswirkungen der Nichtbeachtung zu erläutern
       Empfehlungen oder Anforderungen, die die meisten Implementierer nicht haben werden
       Ich hatte den Vorteil der Erfahrung und der Diskussion, aus denen die
       Spezifikation.

    8. Danksagung

       Die Definitionen dieser Begriffe sind eine Mischung aus Definitionen
       von einer Reihe von RFCs. Außerdem wurden Vorschläge gemacht
       aufgenommen von einer Reihe von Menschen, darunter Robert Ullmann, Thomas
       Narten, Neal McBurnett und Robert Elz.

Es würde nicht schaden, wenn sich Ihre Dokumentation auf RFC als Quelle für Definitionen bezieht:

In diesem Dokument werden Definitionen verwendet, die auf den in RFC 2119 angegebenen basieren .

Ich schätze es ist keine Antwort auf deine Frage, aber in meiner Welt ist es immer noch eine Voraussetzung, auch wenn du es aus irgendeinem Grund nicht erfüllen wirst.

Ich mag den MoSCoW-Ansatz (Must Have, Should Have, Could Have, Won't have this time), um Anforderungen mit Benutzern zusammen mit anderen Faktoren zu kategorisieren (in meiner regulierten Welt können Anforderungen kritisch oder unkritisch sein und viele andere) Argumentation über optionale, aber kritische Anforderungen.)

Ein besseres Wort für eine optionale Anforderung ist " Empfehlung ".

Wie wäre es damit, es als optionale Funktion oder als optionale Aufgabe zu identifizieren? Diese werden nur durchgeführt, wenn zu einem bestimmten Zeitpunkt im Projekt festgestellt wurde, dass Zeit und Geld zur Verfügung stehen, um diese Funktionen auszuführen.

Sie können auch ausgelöst werden, wenn ein externes Ereignis eintritt. Wenn der Kunde zu Windows 8 wechselt, müssen die folgenden Aufgaben erledigt werden ...

Die Beschreibung der Funktion sollte eine Frist enthalten, innerhalb derer bestimmt werden kann, ob sie ausgeführt wird.

Die Anforderungen sind im Software Engineering in 4 Bereiche unterteilt:

1. Geschäftsanforderungen : Konzentriert sich auf die allgemeinen Geschäftsziele und -ziele des Systems
2. Benutzeranforderungen : Konzentriert sich auf die Benutzerziele und darauf, was Benutzer tun müssen, um das System zum Erreichen von Geschäftszielen zu verwenden
3. Funktionsanforderungen : Welche Funktionen und Aufgaben muss das System ausführen, um die Geschäftsziele zu erreichen
4. Nichtfunktionale Anforderungen : Welche Anforderungen gibt es außer funktionalen. Dies schließt Umgebungsbedingungen, Einschränkungen, Schnittstellen- und Wartungsprobleme usw. ein.

Jetzt können die Anforderungen optional oder obligatorisch sein , abhängig von den oben beschriebenen vier Kategorien. Optionale Anforderungen können auch in den Anwendungsbereich des betrachteten Systems fallen oder auch außerhalb des Anwendungsbereichs liegen. Optionale Anforderungen sind ein gutes Mittel, um Scope Creep zu vermeiden und Ihren Bereich präzise zu definieren.

Optionale Anforderungen sind immer Teil des Software-Engineerings, da sie uns bei der Identifizierung des Bereichs helfen und ein gutes Mittel zur Vermeidung von Scope Creep sind. Man kann niemals sagen, dass sie den Entwicklungspraktiken von SDLC widersprechen. Anforderungen müssen jedoch priorisiert und genau definiert werden.

In der Volere-Vorlage wird der Begriff "Wartezimmer" verwendet.

... Diese Vorlage dient als Grundlage für Ihre Anforderungsspezifikationen. Die Vorlage enthält die Anforderungsarten, die für die heutigen Geschäfts-, Wissenschafts- und Softwaresysteme geeignet sind. Es bietet eine Checkliste, Struktur und Rückverfolgbarkeit für Ihre Anforderungen ... Die Vorlage ist werkzeugunabhängig und wurde erfolgreich mit Yonix, Requisite, DOORS, Calibre RM, IRqA und anderen gängigen Werkzeugen verwendet ...

Die Volere-Techniken werden in dem Buch Mastering the Requirements Process von Suzanne Robertson und James Robertson beschrieben ...

In meinem Unternehmen (Raumfahrzeug) werden sie entweder als "Ziele" bezeichnet, was darauf hinweist, dass sie dokumentiert sind und dass der Aufwand für ihre Erreichung aufgewendet wird. Das System wird jedoch weiterhin als erfolgreich angesehen, wenn sie nicht erfüllt werden. "Wünsche" (kein richtiges Wort, aber Sie sind da), die anzeigen, dass jemand sie will und versucht, den Status von Zielen zu erreichen, aber noch nicht akzeptiert oder dokumentiert ist; oder "schleichende Anforderungen", die eine abwertendere Version von Anforderungen sind, die auf Dinge hinweisen, die versuchen, Ressourcen zu verbrauchen, sich aber in einem Projekt nicht lohnen, das versucht, "gut genug" zu erreichen, wo sie das Erreichen der tatsächlichen Anforderungen gefährden oder drohen.

Wenn Ihre Anforderungen priorisiert sind , können Sie sie als Anforderungen mit niedriger Priorität ansehen .

Ich bin ziemlich überrascht, dass niemand erwähnt hat, dass diese Ziele genannt werden. Jede Firma, für die ich gearbeitet habe, hat sie so genannt. Sie werden mit den Worten "Wille" oder "sollte" anstelle von "soll" bezeichnet. Manchmal werden sie in geschweifte Klammern eingeschlossen, wenn es um Zahlen geht. Beispiel: Das System muss 100 {250} Stunden lang ununterbrochen arbeiten, ohne dass der Bediener darauf achten muss. Dies bedeutet, dass die Anforderung, die erfüllt werden muss, 100 Stunden beträgt, das Ziel jedoch 250 Stunden.

Als Randbemerkung: Es kommt sehr selten vor, dass jemand tatsächlich etwas entwirft, um die objektive Anforderung zu erfüllen, es sei denn, es handelt sich um einen Anreiz.

Der Begriff "Wunsch" wird manchmal für optionale Anforderungen verwendet. Es ist jedoch möglicherweise nicht für ein offizielles Dokument geeignet.

Ich bin überrascht, dass sich alle Antworten auf die Nachverfolgung von Anforderungen in der Projektentwicklung beziehen. Obwohl ich ein Entwickler bin, habe ich mir in diesem Zusammenhang nie allzu viele Sorgen um diese Terminologie gemacht. Als ich die Frage zum ersten Mal las, ging ich davon aus, dass sie sich auf die Produktspezifikation des Benutzers und nicht auf die Produktentwicklung bezieht. In einer Enzyklopädie wird beispielsweise ein Farbdrucker als optionale Anforderung aufgeführt. Es ist erforderlich, wenn Sie den vollen Nutzen aus der App ziehen möchten, aber optional, wenn Sie den Bildschirm anzeigen möchten. Aber was wäre, wenn Sie zum Beispiel einen Schwarzweißdrucker hätten? Wie können Sie klarstellen, ob Ihre App mit der offensichtlichen Einschränkung funktioniert, dass einige Fotos möglicherweise nicht so gut aussehen? Oder überhaupt nicht drucken? Als weiteres Beispiel: Wie überprüfe ich eine Druckerprüfung, um festzustellen, ob Tinte eine Anforderung oder eine optionale Anforderung in einem Multifunktionsdrucker ist? Mit anderen Worten, kann ich trotzdem scannen? Einige Hinweise zur Terminologie und was zu suchen wäre sowohl als Produktentwickler / -verkäufer als auch als Verbraucher willkommen.

Ich würde sie "optionale Funktionen" nennen, keine optionalen Anforderungen. Anforderungen klingen wie etwas, das Sie haben müssen , während Funktionen wie ein Add-On zum Originalprodukt klingen.