Kravspecifikation - Jensprog/CashTrack GitHub Wiki
1. Funktionella krav (Frivilligt)
1.1 Användarhantering
- Systemet ska tillåta användare att registrera ett konto med e-post och lösenord.
- Systemet ska tillåta användare att logga in på sitt konto med e-post och lösenord.
- Systemet ska tillåta användare att ändra sitt lösenord.
User Stories:
- US1: Som ny användare vill jag kunna registrera mig och logga in på mitt konto för att se över min ekonomi.
- US2: Som befintlig användare vill jag kunna ändra mitt lösenord.
1.2 Databashantering
- Systemet ska tillåta användare att lagra sitt användarkonto i en databas.
- Systemet ska tillåta användare att lagra sina transaktioner i en databas.
User Stories:
- US3: Som ny användare vill jag att mina användareuppgifter lagras utan att exponera personliga uppgifter.
- US4: Som befintlig användare vill jag att mina transaktioner lagras på ett säkert sätt.
1.3 Transaktionshantering
- Systemet ska tillåta användare att lägga till inkomster med belopp, titel och datum.
- Systemet ska tillåta användare att lägga till utgifter med belopp, titel och datum.
- Systemet ska tillåta användare att redigera inkomster.
- Systemet ska tillåta användare att redigera utgifter.
- Systemet ska tillåta användare att radera inkomster.
- Systemet ska tillåta användare att radera utgifter.
User Stories:
- US5: Som användare vill jag kunna lägga till inkomster och utgifter för att få en överblick över mina transaktioner.
- US6: Som användare vill jag kunna ändra och ta bort mina transaktioner ifall något blev fel vid inmatningen.
1.4 Kategorisering
- Systemet ska tillåta användare att kategorisera sina inkomster.
- Systemet ska tillåta användare att kategorisera sina utgifter.
User Stories:
- US7: Som användare vill jag kunna kategorisera mina inkomster för då jag får inkomst från olika källor.
- US8: Som användare vill jag kunna kategorisera mina utgifter för att få bättre kontroll över vad jag faktiskt spenderar min budget på.
1.5 Ekonomisk översikt
- Systemet ska tillåta användare att välja veckovis hur mycket de spenderat.
- Systemet ska tillåta användare att välja månadsvis hur mycket de spenderat.
User Stories:
- US9: Som användare vill jag ha möjligheten att kolla hur mycket jag spenderat den senaste veckan och månaden för att veta hur mycket jag spenderat och vad som kvarstår av budgeten.
1.6 Sparkonto
- Systemet ska tillåta användare att skapa och hantera sparkonton.
- Systemet ska tillåta användare att föra över pengar mellan vardagskonto och sparkonto.
- Systemet ska visa sparkontots saldo, historik och utveckling över tid.
- Systemet ska låta användare sätta upp och följa sparmål.
User Stories:
- US10: Som användare vill jag kunna skapa och hantera sparkonton för att hålla koll på mina besparingar separat från vardagsekonomin.
- US11: Som användare vill jag kunna föra över pengar mellan mina olika konton för att spegla verkliga överföringar jag gör.
- US12: Som användare vill jag se mitt sparkontosaldo och historik för att följa utvecklingen av mina besparingar.
- US13: Som användare vill jag kunna sätta upp sparmål för att motivera mig att spara regelbundet.
1.7 Budgetanalys
- Systemet ska tillåta användare att visualisera utgifter per kategori i ett cirkeldiagram.
- Systemet ska visa utgifter både i belopp (SEK) och procent.
- Systemet ska tillåta användare att välja datum för att analysera utgifter inom specifika tidsperioder.
- Systemet ska visa detaljerad information i en tabell över utgifter per kategori.
User Stories:
- US14: Som användare vill jag kunna se mina utgifter visualiserade i ett diagram för att få en tydlig överblick över mina utgiftsmönster.
- US15: Som användare vill jag kunna växla mellan att se utgifter i kronor och procent för att få olika perspektiv på min ekonomi.
- US16: Som användare vill jag kunna filtrera utgiftsdiagrammet baserat på datum för att analysera specifika tidsperioder.
- US17: Som användare vill jag se en detaljerad tabell med mina utgifter per kategori för att komplettera den visuella presentationen med exakta siffror.
2. Ickefunktionella produktkrav (non-functional product requirements)
2.1 Användarvänlighet
- Systemet ska ha ett intuitivt gränssnitt som är lätt att lära sig.
- Användare ska kunna lägga till en transaktion på mindre än 30 sekunder.
2.2 Prestanda
- Systemet ska ha en responstid på 2 sekunder när man byter sida.
2.3 Tillförlitlighet
- Systemet ska ha en up time på 99.5%.
- Systemet ska klara av avbrott så ingen data går förlorad.
2.4 Säkerhet
- Systemet ska leverera all kommunikation via HTTPS.
- Systemet ska implementera CSRF-skydd på alla formulär och API-endpoints.
- Systemet ska validera all användarinmatning på både klient- och serversidan.
- Systemet ska implementera en Content Security Policy för att begränsa varifrån resurser kan laddas.
- Systemet ska använda säkra HTTP-headers för att skydda mot vanliga webbangrepp (XSS, clickjacking, MIME sniffing).
- Systemet ska implementera rate limiting på känsliga endpoints som inloggning och registrering.
- Systemet ska lagra JWT-tokens på ett säkert sätt, helst i HttpOnly cookies.
- Systemet ska ha skydd mot SQL-injektions-attacker.
3. Organisationskrav (non-functional organizational requirements)
3.1 Versionshantering
Jag kommer att använda git och gitlab för versionshantering. Jag kommer börja använda mig av branches för att ha en main branch där allt fungerar, medan jag har en feature branch där jag utvecklar och testar tills det jag jobbar med fungerar och sedan mergar feature branchen med main branch. Det känns som ett bra arbetssätt för att hålla main branch så ren som möjligt utan några medvetna fel.
3.2 Kodstandard
Jag kommer att använda mig av ESLint och följa den kodstandarden.
- Variabler och metoder i camelCasing.
- React komponenter i PascalCasing.
3.3 Koddokumentation
Jag kommer använda mig av följande dokumentation:
- JSDoc vid komplexa metoder.
- Radkommentarer för enligt mig, komplex kod.
- README-fil för hela systemet.
Eftersom jag kommer använda mig av Next.js så kommer jag dokumentera mina API-endpoints. Hur de fungerar och deras förväntade returvärde.
4. Externa krav (non-functional external requirements)
4.1 Etiska krav
Med tanke på att jag ska hantera ekonomisk data så behöver min databas vara säker och därför är säkerheten central i min applikation. För att åstadkomma detta så har jag följande planer.
- Användarnas data skyddas i databasen genom user_id vilket inte direkt exponerar en individs mailadress, vilket är användarnamnet vid registrering.
- Det kommer inte finnas några rekommendationer som kan skada individens ekonomi.
- Användare kommer ha full kontroll över sin egna ekonomi. Eftersom man behöver lägga till alla inkomster och utgifter själv så är det något individen kontrollerar helt själv.
4.2 Lagar & Standarder
- Jag kommer se till att ett meddelande visas vid registrering att jag lagrar användarens data, men endast nödvändig data för att applikationen ska fungera.
- Eventuellt beroende på tid så skulle det vara optimalt att låta användaren hämta sin personliga data.
- Eventuellt låta användaren radera sin data.