F5 - Modellera funktionella krav

Question 1

Vad är intressentkrav?

Answer 1

Intressentkrav är krav som kommer från intressenterna. De är ofta uttryckta i naturligt språk och intressenterna skiljer inte mellan funktionella- och icke-funktionella krav.

Question 2

Hur modelleras funktionella- och icke-funktionella krav?

Answer 2

De är kartlagda från intressentkraven.
Funktionella krav är modellbaserade (UML) - use cases, domänmodeller etc, för att underlätta tolkning av utvecklare och programvara.
Icke-funktionella krav kan inte modelleras, som funktionella, och därför hålls de vanligtvis i en strukturerad text.

Question 3

Vilka är fördelarna med modellering av krav?

Answer 3

• De utelämnar irrelevanta detaljer, minskar komplexiteten, med hjälp av abstraktionsmekanismer som urval, aggregation och klassificering
• Fokuserar på presentationen av ett enda perspektiv - data, funktioner
• Kan definiera ytterligare egenskaper, genom valda vyer, alternativa modelltyper, statistik och så vidare.
• Kontrollera/validera för fullständighet och korrekthet är mindre tidskrävande än med naturligt språk eftersom verktyg kan användas.
• Är lättare att översätta/kartlägga till programkod (eller till och med körbar kod) än med naturligt språk. Som sådan är de en viktig bro mellan de textbaserade kraven och ett framtida system.

Question 4

På vilka olika sätt kan man modellera?

Answer 4

Det finns två huvudsakliga sätt att modellera, analystdriven modellering (analyst driven) eller deltagande modellering (participatory modeling):

• Analystdriven modellering: En analytiker analyserar kravens källor och intressentkraven och därefter skapar modeller. Modellerna diskuteras sedan med intressenterna.
• Deltagande modellering: En grupp intressenter skapar en modell tillsammans med assistans av en modelleringsfasilitator. I detta fall är intressenterna ansvariga över den kunskap som finns i modellen. Handledaren är ansvarig för modelleringsmetoden samt kvaliteten på modellen.

Question 5

Vilka är vanliga problem vid modellering med Use Case?

Answer 5

• Relationerna mellan use casen är inte till för att visa i vilken ordning de är utförda.
• Use cases är interaktioner mellan användaren och systemet. Därmed bör det inte vara rent manuella aktiviteter som use cases eller use case steps.
• CRUD: information behöver vara Created, Read, Updated och Deleted, och vi behöver use case för att göra detta. Om inte saker “bara händer” rent automatiskt.
• Use case ska vara om systemet som vi bygger och inte om något externt system. Externa system är aktörer.
• Namnge use cases, ett aktivt verb och en substantivfras.
• För stort eller för litet, kom ihåg granularity test från OOS.

Question 6

Vad är ett Use Case?

Answer 6

Ett Use Case beskriver en sekvens av åtgärder som systemet utför för att uppnå ett observerbart resultat av värde för aktörerna.

Question 7

Vad är en domänmodell?

Answer 7

• En domänmodell dokumenterar informationskonceptet från problemdomänen. Tex person, kund, betalning, beställning.
• Identifiering av klasser i domänmodellen. Analysera källorna till kraven och använd use case beskrivningar.
• En domänmodell ska inte innehålla mjukvaruklasser eller andra artefakter för informationssystemdesign. En domänmodell kan senare utvecklas till ett klassdiagram.
• En domänmodell beskriver den statiska aspekten av en domän. Den dynamiska aspekten behandlas av business process models och use cases.