F3 Flashcards
Datakrav:
beskriver format för indata och utdata
anger vad för information systemet ska lagra
Funktionella krav:
beskriver mappning mellan indata och utdata beskriver hur information ska behandlas
•Datakravstilar:
§Datamodell
( =E/R-diagr.) §Dataordlista §Reguljära uttryck §Virtuella fönster
Funktionella kravstilar:
§Kontextdiagram
§Händelse- & Funktionslistor §Produktegenskapskrav §Skärmbilder & Prototyper
Funktionella detaljer:
§Enkla och sammansatta
funktioner
§Tabeller & Beslutstabeller §Textuella processbeskrivningar
När passar en viss teknik bra?
Svaret beror på…
§ abstraktionsnivå
§ projekttyp
§ intressenterna § verktygsstöd §mängden krav
•Exempel på data:
Abonnentdata, roaming data, telefonboksdata, data om bilder (när, upplösning, namn, kategori), data om låtar (album, artist, genre, låtnamn, uppspelningssannolikhet) etc
§Data model (E/R-diagr.)
Block diagram describing data inside and outside the product
– Precise and insensitive to abstraction level
– Excellent for experts – difficult for users; takes time to learn
– Easy to verify by experts that the data is handled by the product
– Difficult to decide how much detail should be included in the model
§Data dictionary
– Textual description of data inside and outside the product
– Structured and systematic descriptions using verbal text
– Very expressive, can be used for all levels of detail and special cases
– Easy to validate by experts and non-experts
– Takes long time to write; when is it good enough? (Start with difficult parts!!)
§Data expressions (regular expressions)
– Compact formulas for describing data sequences
– Useful for composite data and message protocolls
– Excellent for experts, acceptable for many users
– No visual overview
§Virtual windows
– Simplified screens with graphics and realistic data, but no buttons and menues
– Excellent for both experts and users
– Easy to validate and verify
– Risk of overdoing it and start designing the user interface
SYSTEM BOUNDARIES
System boundaries are established to define what is inside and what is outside the system.
– They show other systems that are used or depend on the system being developed.
The position of the system boundary has a profound effect on the system requirements.
CREATING THE CONTEXT DIAGRAM
Draw one process representing the entire system (bubble)
2. Find all inputs and outputs and draw as data flows (arrows)
3. Draw in external entities as the
source or destination of the data flows (rectangular)
USE CASE DIAGRAMS
– document the functionality of the system from the users’
perspective
– document the scope of the system
– document the interaction between
the users and the system using supporting use case descriptions
(behaviour specifications)
FÖRDELAR MED DYNAMISKA MODELLER AV VAD ANVÄNDAREN GÖR
- Lätt att förstå för icke-tekniska intressenter •Kan koppla ihop krav på olika nivåer
- Bra för att modellera funktionella krav •Hjälper till att strukturera kraven
- Ger ett dynamiskt perspektiv på kraven •Stödjer spårbarhet
- Bra grund för testfall
FALLGROPAR dynamiska modeller
• För mycket detaljer – ”överspecificering”
• För lite detaljer – ”underspecificering”
• Fragmentering av information
• För tidig design
• Ej enhetliga beskrivningar
– Olika form, detaljnivå, terminologi
• Inkonsekvenser
– Motstridiga användningsfall
• Begränsad täckning av kraven (ofullständighet)
• Funktionell nedbrytning -> dålig OO design
• Funktionella krav:
§ Vad som görs
§ Ofta antingen/eller § Indata – Utdata
§ Funktioner
Icke-funktionella krav
Hur bra det görs
§ Mäts ofta på en skala
§ Sätter begränsningar på systemet (eller
utvecklingsprocessen)
§ Kan ofta slå tvärs över många funktioner
FR & NFR HÄNGER IHOP
- I praktiken är funktionella krav och kvalitetskrav svåra att separera då kvalitetskraven manifesterar sig i extra funktionalitet.
- Exempel: icke-funktionellt krav om säkerhet kräver inloggningsfunktion
SVÅRA AVVÄGNINGAR MELLAN KVALITETSKRAV
•Kvalitetsaspekter ofta motverkande. •Vanliga exempel: – Ökad prestanda -> minskad underhållsbarhet – Ökad säkerhet -> minskad usability
Quality factors mccall
Product operation factors − Correctness, Reliability, Efficiency, Integrity, Usability.
Product revision factors − Maintainability, Flexibility, Testability.
Product transition factors − Portability, Reusability, Interoperability
VADÅ FULLSTÄNDIG KRAVSPEC
Det är i praktiken omöjligt att specificera allt i minsta detalj!
§ Vad är bra nog?
-> Beror på situationen
§ Tips: Fokusera på de krav som innebär störst risk för…
– Missförståndblandintressenter
– Attslutresultatetejblirönskvärt
