4616921
Descripción
Fichas por Jannis Brok, actualizado hace más de 1 año
|
Creado por Jannis Brok
hace más de 8 años
|
|
| Pregunta | Respuesta |
| Ein verteiltes System ist ... | eine Menge von unabhängigen Rechnern, die für den Nutzer als ein System erscheinen. |
| Software Engineering beschäftigt sich mit ... | allen Aspekten der Erstellung von Software |
| Ein Rendezvous ist ... | eine ereignisbasierende Synchronisation nebenläufiger Prozesse |
| Analyse heißt ... | das Herleiten der von den Beteiligten benötigten Funktionen eines SW-Produkts, sowie der Bedingungen für deren Entwicklung und dessen Betrieb |
| Beschreibe die Teilphasen der Analyse | |
| Nenne die Teile der Anforderungen | 1. Machbarkeitsstudie 2. Anforderung 3. Stakeholder 4. Anforderungsquellen |
| Nenne die möglichen Bestandteile einer Machbarkeitsstudie | 1. Kostenanalyse 2. Marktanalyse - Beteiligte, insbesondere Konkurrenz, Make-or-Buy 3. Designstudie 4. Prototyp 5. Akzeptanzanalyse - Achtung: mögliche Widerstände beachten, z.B. Rationalisierungsangst 6. Rechtliche Prüfung |
| Beschreibe die Anforderung | Bedingung oder Fähigkeit 1. die von einem Benutzer benötigt wird, 2. die ein System besitzen muss oder 3. als dokumentierte Repräsentation von 1. oder 2. |
| Beschreibe den Stakeholder | (auch: Anspruchsträger, Projektbeteiligter) - übt Einfluss auf Anforderungen aus |
| Nenne die Anforderungsquellen | 1. Standards 2. Normen 3. Gesetze 4. ethische Regeln 5. Konkurrenzprodukte |
| Gebe die Definition der Anforderungsermittlung wieder | (auch: Anforderungsanalyse) Das Requierements Engineering (Anforderungsanalyse) ist ein kooperativer, iterativer, inkrementeller Prozess, dessen Ziel es ist zu gewährleisten, dass 1. alle relevanten Anforderungen bekannt und in dem erforderlichen Detaillierungsgrad verstanden sind, 2. die involvierten Stakeholder eine ausreichende Übereinstimmung über die bekannten Anforderungen erzielen 3. alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert bzw. konform zu den Spezifikationsvorschriften spezifiziert sind |
| Gebe die notwendigen Eigenschaften eines Requirements Engineers wieder | 1. Analytisches Denken, 2. Methodische Kompetenz 3. Kommunikationsfähigkeit 4. Selbstbewusstes Auftreten 5. Empathie (Einfühlungsvermögen) 6. Moderationsfähigkeit (Konflikte lösen) 7. Überzeugungsfähigkeit |
| Welche Analysemethoden/Ermittlungstechniken sind Ihnen bekannt? | 1. Dokumentenanalyse 2. Brainstorming 3. Beobachtung 4. Interview 5. Checklisten 6. Prototyping 7. Szenarien/Stories |
| Nenne die Faktoren für die Auswahl der Analysemethoden | 1. Produkt - Weiterentwicklung - Neuentwicklung - Großer Systemumfang 2. Mensch - Geringe Motivation der Stakeholder - Unterschiedliche Stakeholder-Meinungen 3. Organisation - Komplexer Markt - Knappes Projektbudget |
| Für welche Faktoren ist die folgende Ermittlungstechnik/Analysemethode geeignet/neutral/ungeeignet: Dokumentenanalyse | Geeignet: Weiterentwicklung, Großer Systemumfang, Knappes Projektbudget, Komplexer Markt Neutral: Neuentwicklung, Unterschiedliche Stakeholder-Meinungen, Geringe Motivation der Stakeholder Ungeeignet: keine |
| Für welche Faktoren ist die folgende Ermittlungstechnik/Analysemethode geeignet/neutral/ungeeignet: Brainstorming | Geeignet: Neuentwicklung, Komplexer Markt Neutral: Weiterentwicklung, Geringe Motivation der Stakeholder, Knappes Projektbudget Ungeeignet: Großer Systemumfang, Unterschiedliche Stakeholder-Meinung |
| Für welche Faktoren ist die folgende Ermittlungstechnik/Analysemethode geeignet/neutral/ungeeignet: Beobachtung | Geeignet: Weiterentwicklung, Geringe Motivation der Stakeholder Neutral: Neuentwicklung, Unterschiedliche Stakeholder-Meinungen, Knappes Projektbudget Ungeeignet: Großer Systemumfang |
| Für welche Faktoren ist die folgende Ermittlungstechnik/Analysemethode geeignet/neutral/ungeeignet: Interview | Geeignet: Neuentwicklung, Unterschiedliche Stakeholder-Meinung Neutral: Weiterentwicklung, Großer Systemumfang, Komplexer Markt Ungeeignet: Geringe Motivation der Stakeholder, Knappes Projektbudget |
| Für welche Faktoren ist die folgende Ermittlungstechnik/Analysemethode geeignet/neutral/ungeeignet: Checklisten | Geeignet: Neuentwicklung, Knappes Projektbudget, Komplexer Markt Neutral: Weiterentwicklung, Großer Systemumfang, Unterschiedliche Stakeholder-Meinungen Ungeeignet: Geringe Motivation der Stakeholder |
| Für welche Faktoren ist die folgende Ermittlungstechnik/Analysemethode geeignet/neutral/ungeeignet: Prototyping | Geeignet: Neuentwicklung, Geringe Motivation der Stakeholder Neutral: Weiterentwicklung, Großer Systemumfang, Unterschiedliche Stakeholder-Meinungen, Komplexer Markt Ungeeignet: Kanppes Projektbudget |
| Für welche Faktoren ist die folgende Ermittlungstechnik/Analysemethode geeignet/neutral/ungeeignet: Szenarien / Stories | Geeignet: Neuentwicklungen, Geringe Motivation der Stakeholder Neutral: Weiterentwicklung, Großer Systemumfang, Unterschiedliche Stakeholder-Meinungen, Knappes Projektbudget, Komplexer Markt Ungeeignet: keine |
| Beschreibe die Klassifikation der Anforderungen | 1. Funktionale Anforderungen 2. Nichtfunktionale Anforderungen 3. Umgebungsanforderungen 4. Klassifikation nach Modellen |
| Beschreibe die Funktionalen Anforderungen | 1. Reaktion der Software auf Eingaben 2. Unerwünschte Reaktionen |
| Beschreibe die Nichtfunktionalen Anforderungen und gebe Beispiele | 1. Quantitativ spezifizierbare Bedingungen, die die Software einhalten muss 2. Benutzbarkeit (usability), Leistungsfähigkeit (performance), Sicherheit (security) Beispiele: Transaktionen/Sekunde; Antwortzeit, Schulungsdauer, Zuverlässigkeit, Dauer eines Neustarts |
| Beschreibe die Umgebungsanforderung | 1. Einhaltung spezieller Schnittstellen 2. Einhaltung rechtlicher Vorgaben wie Datenschutz (z.B. Anonymisierung von IP-Adressen) |
| Beschreibe das Kano-Modell mit Skizze | |
| Beschreibe das Bradner-Modell | - MUSS (MUST): absolute Festlegung - DARF NICHT (MUST NOT): absoluter Ausschluss - SOLL (SHOULD): Empfehlung - SOLL NICHT (SHOULD NOT): empfohlener Ausschluss - KANN (MAY): optional |
| Gebe die Grafik zur Anforderungsmodellierung aus den Vorlesungsunterlagen wieder | |
| Nenne die 3 Bestandteile von Use Case Diagrammen und beschreibe diese | 1. Actor: Dinge oder Personen, die Informationen oder Ereignisse an das System liefern oder von diesem empfangen. Namenskonvention: welche Rolle spielt der Actor in Bezug auf das System 2. Use Case: Ein vom einem Actor gestartetes vollständiges Systemverhalten, das dem Actor einen Nutzen bringt. Namenskonvention: Verb-Phrase, aus der Sicht des Actor 3. Kommunikationsbeziehung: zwischen Actor und Use Case. Gerichtete Beziehung (Pfeil) kann anzeigen, wer den Use Case startet. |
| Beschreibe die Include-Beziehung des Use Case-Diagramms | |
| Beschreibe die Extends-Beziehung des Use Case-Diagramms | |
| Beschreibe die Use Case Generalisierung | |
| Skizziere das Use Case-Diagramm Beispiel aus den Vorlesungsunterlagen | |
| Beschreibe das Vorgehen der Use Case - Spezifikation bis einschließlich 5. | 1. Benennen Sie den Use Case 2. Beschreiben Sie den Use Case kurz (2-3 Sätze) 3. Beschreiben Sie den Hauptgedanken (Hauptpfad) des Use Cases ausführlich, Schritt für Schritt 4. Definieren Sie geeignete Vor- und Nachbedingungen für den Ablauf, 5. Suchen Sie nach Alternativ-, Ausnahme- und Fehlerfällen. |
| Beschreibe das Vorgehen der Use Case Spezifikation ab 6. | 6. Beschreiben Sie die wichtigsten Alternativen (inkl. Vor- und Nachbedingungen), Ausnahmen und Fehlerfälle 7. Fügen Sie alle Anforderungen hinzu, die spezifisch für diesen Use Case sind und im Ablauf nicht vorkommen (nicht- funktionale Anforderungen, Geschäftsregeln, Datenprüfungen |
| Mache eine Anmerkung zum Hauptpfad | Der Hauptpfad ist nur ein möglicher Durchlauf des Use Case (Szenario); jede Alternative, Fehler, Ausnahme führt zu weiteren möglichen Durchläufen (Szenarien). Szenarien sind Instanzen von Use Cases |
| Beschreibe das UML-Sequenzdiagramm | |
| Gebe das beispielhafte UML Sequenzdiagramm aus den Vorlesungsunterlagen für eine E-Ticketbestellung wieder | |
| Beschreibe EPK | |
| Beispiel EPK: Zur Verdeutlichung | |
| Beschreibe die Anforderungsverwaltung | 1. Verwaltung: wer, was, wann, womit - Attribute: Gruppierung, Zuordnung, Bearbeitungsstand 2. Nachverfolgbarkeit der Anforderungen (traceability) 3. Anpassung der Anforderungen - Erstellung, Entfall, Änderung, Priorisierung, Versionierung - Baseline |
| Gebe die Skizze zum Anforderungsworkshop wieder | |
| Anforderungskarte: Zur Verdeutlichung | |
| Gebe die Skizze zur Aufteilung in Releases wieder | |
| Beschreibe das Lastenheft | |
| Gebe die Analyse-Zusammenfassung aus den Vorlesungsunterlagen wieder |
¿Quieres crear tus propias Fichas gratiscon GoConqr? Más información.