Usabilty Requirements

Ich habe heute eine interessante Frage gestellt bekommen, die auf den ersten Blick trivial erscheint, im Detail aber knifflig sein kann:

Du möchtest eine *fertige* oder leicht angepasste Applikation für Standart Windows Platform erwerben, und dafür natürlich Usabilty Requirements vertraglich festhalten.

Was würdet ihr definieren (ausser “muss dem standard windows stylequide folgen, und “soll einfach und intuitiv zu bedienen sein”)?

danke für alle kommentare!

thomas

3 thoughts on “Usabilty Requirements”

  1. Verstehe ich das richtig: Du möchtest eine Software kaufen die du entweder “von der Stange” übernehmen kannst oder leicht anpassen lässt. Und dafür brauchst du Requirements.
    ?

    Schwierig schwierig. Ich würde vielleicht damit anfangen, Ziele der Benutzer herauszufinden und schriftlich festzuhalten. Aber nicht in der Form “die Anwendung soll das und das können”, sondern eingebettet in Szenarios, versehen mit einer Priorisierung (was ist die Hauptaufgabe der Anwendung, was soll sie außerdem noch können …).

    Wichtig wäre dann noch eine Beschreibung der User:
    Computernutzung, wie wird die Anwendung eingesetzt werden (bei welchen Arbeitsschritten, wie oft, ….) …
    Und daraus dann ebenfalls wieder Requirements ableiten: Wenn die User die Anwendung selten bedienen werden sollte auf rasche Wiedererlernbarkeit geachtet werden, ist die Anwendung das wichtigste Arbeitstool und wird sie demnach sehr oft verwendet dann wird eher die Effizienz im Vordergrund stehen und die Einlernzeit kann ruhig länger ausfallen…
    Am Besten wäre es vermutlich, Usabilitytests mit den Hauptkandidaten (gemeint ist die Software) und der Zielgruppe (den zukünftigen Usern) durchzuführen. Da würde dann zwar hauptsächlich die Erlernbarkeit getestet werden, aber man würde auf jeden Fall auch wichtige Inputs bekommen die man sonst möglicherweise übersieht…

    Aber darf ich fragen wozu die Usability Requirements in diesem Fall überhaupt benötigt werden? Bei einer angepassten Lösung leuchtet mir’s ja noch ein, aber bei einer Standardsoftware?

  2. hey, wer (vom uic oder ex ;-)versteckt sich denn hinter usability@frq ? danke für den link, diesen folder hab ich damals selber geschrieben… 🙂

    @jörg, der grund der usability requirements ist hauptsächlich der, dass vermieden werden soll, dass SW allzu proprietär ist und irgenwelche inherente bedientechnische eigenheiten besitzt, die zb durch das framwork vorgegeben sind (ein typisches bsp SAP), von uns dann auch nicht reklamierbar oder änderbar sind und durch diese bedientechnischen eigenheiten die benutzer von der bedienung abhält. *cooler satz, oder…*

    was ich vor allem gesucht habe sind möglichst generische aber keine unprüfbaren no-na requirements wie: die bedienung muss intuitiv sein…

    zb gefunden auf: http://www.usabilitynet.org/trump/methods/recommended/requirements.htm

    2. Detailed usability requirements

    Decide which usability requirements are relevant. Examples of potential requirements are:
    Understandability

    * Interface elements (e.g. menus) should be easy to understand
    * For a walk up and purchase or use system, the purpose of the system should be easily understandable

    Learnability

    * The user documentation and help should be complete
    * The help should be context sensitive and explain how to achieve common tasks
    * The system should be easy to learn

    Operability

    * The interface actions and elements should be consistent
    * Error messages should explain how to recover from the error
    * Undo should be available for most actions
    * Actions which cannot be undone should ask for confirmation
    * The system be customisable to meet specific user needs
    * A style guide should be used

    Attractiveness

    * The screen layout and colour should be appealing –> hmmm…?!?!?

    vg t.

Comments are closed.