UdZ 01.22 /13 definieren Unternehmen die zukünftigen Prozesse unter Berücksichtigung des neu einzuführenden IT-Systems. Die daraus resultierenden Anforderungen werden in einem Lastenheft festgehalten. Die Formulierung neuer Prozessabläufe und die Ableitung lösungsneutraler Anforderungen stellen die betroffenen Stakeholder jedoch häufig vor Herausforderungen: Einerseits fehlt den Nutzer:innen häufig ein tiefer, lösungsneutraler Einblick in die Funktionalitäten über die auszuwählenden Software, andererseits ist die Definition durchgängiger, digitalisierter Prozesse schwierig, da Wechselwirkungen mit vor- und nachge- lagerten Prozessen meist nicht transparent sind. Ohne das Wissen über Funktionalitäten sowie der fehlenden Transparenz zur Gestaltung durchgängiger, digitaler Prozesse können Anwender:innen nur schwer lösungsneutrale Anforderungen in Lastenheften definieren. Wird dasklassischeVorgehenangewendet,könnendabeiüberspezifizierte, potenzialarme und sehr generische Lastenhefte entstehen, die den tatsächlichen Bedarf von Unternehmen und Anwender:innen nicht adäquat abbilden. Hinzu kommt, dass die fehlende Nutzerorientierung den begleitenden Change-Prozess nur bedingt unterstützt. Um diese Nachteile auszugleichen, empfiehlt sich der kombinierte Einsatz von Lastenheft und User-Storys, um auf diese Weise die Vorteile beider Methoden zu vereinen. User-Storys sind aus der Ich-Perspektive einer Rolle formulierte, nicht formalisierte Erklärungen einer Software-Funktion. Hierbei kann aus Sicht der Anwender:innen der Zweck der benötigten oder gewünschten Funktion angegeben werden, um die Anforderungen im Nachgang zu bewerten. Durch die Formulierung aus Sicht der Stakeholder sind User-Storys per se nutzerzentriert und unterstützen daher den Change-Prozess durch den einfachen Einbezug in den Auswahlprozess. Durch die Formulierung als „Story“ setzen sich die Stakeholder bereits mit ihren Anforderungen auseinander, sodass diese Anforderungen als informelle, lösungsneutrale Formulierung in Form eines Begleitdokuments einem Lastenheft angehangen werden können. Die Übersetzung der User-Storys in funktionale Anforderungen kann von Systemexperten in den Unternehmen übernommen werden oder durch die Software-Anbieter erfolgen. Das hilft dabei, eine Ausschreibung für eine neue Business-Software-Lösung anhand von User-Storys zu formulieren. Auch für die and downstream processes are typically not transparent. Without knowledge of the functionalities and given the lack of transparency in the design of end-to-end, digital processes, it is difficult for users to define solution-neutral requirements in specifications. If the traditional approach is used, this can result in over-specified, low-potential, and highly generic specifications that do not adequately reflect the actual needs of the company and the users. In addition, the lack of user-centricity makes the accompanying change management activities more difficult. To compensate for these disadvantages, we recommend the combined use of specifications and user stories, thus leveraging the advantages of both methods. User stories are non-formalized explanations of a software function formulated from a user perspective. The purpose of the desired or required function is explained in the words of the user, and this input can be used as a basis for a subsequent evaluation of the requirements. Told from the perspective of the stakeholders, the user stories are per se user-centric and their inclusion in the selection process supports the change process. Just by telling these “stories”, stakeholders think about their requirements; their informal, solutionneutral contributions can be added to the requirements specification in the formof an accompanying document. The user stories can subsequently be translated into functional requirements by in-house systems experts or by the software vendor. This helps to formulate an RFP (Request for Proposal) for a new business software solution based on user stories. User stories can also be used to create the requirements specification document. In this case, the user stories are supplemented by detailed information from the provider that reflects how they intend to implement the business software solution. The provider also indicates whether a requirement is met by the standard product or whether customized programming is necessary. User stories can also be used to complement a detailed functional specification in order to give the provider a better insight into customer requirements. Companies must decide whether exclusively to rely on user stories or whether to create a detailed functional specification. In any case, companies are recommended to agree on a detailed requirements specification with the provider before signing the contract. Above all, the user stories helped us to get all employees on board and to make use of their diverse ideas. ChristianWenzel, Innolite GmbH
RkJQdWJsaXNoZXIy NzcyMw==