heiloliver / roomix Goto Github PK

• Weitere Regeln bestimmen (jeder ca. 5 Stück)
• Auf 5 sinnvolle Regeln eingen
• Mithilfe dieser Regeln VKW Website analysieren
• Regeln strukturieren und Dokument mit Ergebnissen erstellen + Titelblatt

Im Drive bereits Brain Storming mäßig einige mögliche Regeln aufgeschrieben.

https://docs.google.com/document/d/1zAaa1ARcBzaVAnstReHW0UlMNcWgYoXxwkNLRmniTfw/edit?usp=sharing

Kurze Beschreibung der Referenzen:
Dazu gehört das Treffen mit Herrn Tavulato und auch das Lastenheft. Eventuell kommt dann da noch was dazu (z.B. eine Person aus dem Hotelfachgeschäft)

This subsection should provide a complete list of all documents referenced elsewhere in the SRS document. Each document should be identified by title, report number (if applicable), date, and publishing organization (if any). Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document

Inspection Auftrag_V2.pdf

• Gewichtungen für die Probleme
• konkretere Beschreibung der Probleme
• URLs, Browser und Bildschirminfos eingefügt
• kurze Anwendungsszenarien geschrieben
• Verbesserungsvorschläge eingebaut und ergänzt
• Formular Probleme ergänzt

Zweck/Sinn des Pflichtenheftes, an wen es sich richtet und was wann umgesetzt wird (grob)

Specify the purpose of this SRS. The SRS should fully describe the external behavior of the application or subsystem identified. It also describes a domain model, nonfunctional requirements, design constraints and other factors necessary to provide a complete and comprehensive description of the requirements for the software. Furthermore, it defines an iterative development plan in the form of Timeboxes

Website anhand von 5 Regeln beurteilen. (Top 100 Unternehmen aus Vorarlberg)

Welche Akteure und Stakeholder kommen vor und welche Rollen haben diese in Kurzform. Jeweils auch schreiben was sich die Stakeholder erwarten.

To effectively provide products and services that meet your stakeholders’ and users' real needs, it is necessary to identify and involve all of the stakeholders as part of the Requirements Modeling process. You must also identify the users of the system and ensure that the stakeholder community adequately represents them. This section provides a profile of the stakeholders and users involved in the project and the key problems that they perceive to be addressed by the proposed solution. It does not describe their specific requests or requirements as these are captured in a separate stakeholder requests artifact. Instead it provides the background and justification for why the requirements are needed

Folgende Begriffe sind noch nicht eindeutig:

• Zusatzleistung/Extraleistung
• Front-Office Mitarbeiter/Personal vs. Rezeptionist

Kurzform von UseCase wird für jede "Klasse" beschrieben"

List and briefly describe the product features. Features are the high-level capabilities of the system that are necessary to deliver benefits to the users. Each feature is an externally desired service that typically requires a series of inputs to achieve the desired result. For example, a feature of a problem tracking system might be the ability to provide trending reports. This description refers to the use cases and usually describe them in the short form style. Several lightweight Usecases may be described at a higher level as one feature.
Because the SRS document is reviewed by a wide variety of involved personnel, the level of detail should be general enough for everyone to understand. More details will be presented in chapter 5-6.
Throughout this section, each feature should be externally perceivable by users, operators or other external systems. These features should include a description of functionality and any relevant usability issues that must be addressed. The following guidelines apply:
• avoid design. Keep feature descriptions at a general yet precise level. Focus on capabilities needed and why, not how they should be implemented. A good style is that of UseCase descriptions in their short form
• several lightweight Usecases may be described at a higher level as one feature

Bitte drüber schauen.

PersonaMüller_100223_02.pdf

Alle möglichen Use Cases aufschreiben und die wichtigsten heraussuchen, für welche dann auch detaillierte Beschreibungen gemacht werden.

• Buttons anpassen (Weiter und Zurück) + passende Beschriftung "Weiter zu Belegungsplan"
  reservierungsplan direkt sichtbar, um Verfügbarkeit anzuzeigen
• Belegungsplan, wieviele Zimmer in dieser Kategorie sind noch frei?
• Belegungsplan - Zurück Button fehlt
• Belegungsplan - weitere Reservierung buchen
• Belegungsplan - Kontextinformation fehlt, gerade bei mehreren zimmern buchen, welche gehören zu dieser Reservierung hinzu? z.B. 3 Zimmer
• Zusatzleistungen - Gast/Zimmerspezifisch!?! - gehört auf die Zimmer gebucht
• Bestätigung am Ende der Reservierungsübersicht
• Übersichtsleiste wo man gerade im der Reservierung steht (wie Amazon Bestellung)
• Gast suchen (Zurück zu ... Button fehlt)
• Gast anlegen
• Menu links richtig strukturieren
• Reservierungsübersicht (Zurück zu ...)
• Startscreen besser nutzen, die Hälfte ist noch frei (Übersicht letzter Aktionen)
  z.b. offene Tasks?
• während einer Reservierung in einer anderen Reservierung Daten nachsehen?

Erstellen einer Liste mit allen möglichen Usecases und gleichzeitige Einteilung wer welche genauer bearbeiten muss!

Prinzipiell eine Tabelle mit Überbegriffen zu den Fähigkeiten des Systems. Den Überbegriff kurz mit Unterpunkten beschreiben. Bsp.:
Systemverwaltung:
● Benutzerin anlegen
● Benutzerin bearbeiten
● Login in das System
● Logout aus dem System

Summarize the major benefits and features the product will provide. For example, a SRS document for a customer support system may use this part to address problem documentation, routing, and status reporting without mentioning the amount of detail each of these functions requires.
Organize the functions so the list is understandable to the customer or to anyone else reading the document for the first time. A simple table listing the key benefits and their supporting features might suffice.

Use Case Nr1: Reservierung

Stakeholder z.T. im Google Docs drin. Vllt noch ergänzen

hallo

Beschreibung was alles im Pflichtenheft vorkommt, damit der Leser direkt weiß was er sucht. Begriffe sollen verwendet werden die der Kunde kennt.

This subsection should describe what the rest of the SRS document contains and explain how the document is organized. The SRS is adressed to a variety of readers, and in this section, it should be specified which part of the document is interesting for which type of user

Beschreiben was alles Teil vom System ist und was nicht (Domänenspezifisch). Keine! technische Beschreibung. Beschreibung bezieht sich auf das Pflichtenheft und dessen Kapitel.

A brief description of the scope of this SRS document; what Project(s) it is associated with, and what is not included in this document

Weitere Use Cases bestimmen und ausarbeiten, allerdings nicht so detailliert

Was findet man in diesem Kapitel und wo findet man es.

• bis 29.02 fertig
• bitte noch drüber schauen

Überblick über die verschiedenen Bereiche (z.B. die Buchhaltung)

This section provides a high level view of the product capabilities, interfaces to other applications, and systems configurations

Zuvor definierte Use Cases detailliert ausarbeiten. Evtl. auch jeder für sich. Auf diesen liegt das Hauptaugenmerk des Projektes

Wie z.B. Front- und Back-Office aussehen. Also was haben die Benutzer zur Verfügung, wie sieht die Umgebung aus. Wie viele Personen im Office bedienen das Programm usw.

Detail the working environment of the target user. Here are some suggestions:
Number of people involved in completing the task? Is this changing?
How long is a task cycle? Amount of time spent in each activity? Is this changing?
Any unique environmental constraints: mobile, outdoors, in-flight, etc.?
Which systems platforms are in use today? Future platforms?
What other applications are in use? Does your application need to integrate with them?]

Kommt erst ganz am Ende:

Kurzer Überblick über das gesamte System und eine Beschreibung dessen was es macht in einem kleinen Absatz.

A brief description (one paragraph) of the system to be specified by its requirements: what it is used for, what it offers in general to the user, what the context of the system is like

Möglicherweise noch drüber schauen

• Sieht nice aus

Umändern der bisherigen