Product backlog - BackEndByAlex/Timelock GitHub Wiki
Product Backlog
| ID | Namn | Typ | Status | Beskrivning | Motsägelsefullt | Prioritet | Beroenden |
|---|---|---|---|---|---|---|---|
| Node.js-miljö | Projektkrav | klart | Applikationen måste köras i en servermiljö med Node.js installerat. | icke | 10 |
- |
|
| Express.js installerat | Funktionellt krav | klart | Backend använder Express för routing & logik. | icke | 10 | 1 | |
| MongoDB via Docker | Infrastrukturkrav | klart | Två separata databaser (auth-db, password-db) ska köras via Docker. | icke | 8 | 1 | |
|
` |
NGINX konfigurerad | Infrastrukturkrav | klart | En omvänd proxy måste vara konfigurerad för att dirigera trafik till Auth- och Password-servern | icke | 2 | 1,2,3 |
| EJS-motor aktiv | Funktionellt krav | klart | Används för att server-rendera views till klienten. | icke | 10 | 1, 2 | |
| Indexsida med login-knapp | Funktionellt krav | klart | En tydlig login-knapp ska visas på startsidan. | icke | 9 | 1,2,5 | |
| Login-sida | Funktionellt krav | klart | Login-sidan ska ha formulär för e-post & lösenord. | icke | 7 | 1,2,5 | |
| Register-sida | Funktionellt krav | klart | Användare ska kunna registrera sig och spara till auth-db. | icke | 6 | 1,2,3,5 | |
| Autentisering med databas | Infrastrukturkrav | klart | Login måste verifieras mot auth-db. | icke | 5 | 1,2,3,5,7 | |
| Omdirigering efter login | Funktionellt krav | klart | Efter inloggning ska användaren skickas till /dashboard. | icke | 5 | 1,2,3,5,7,9 | |
| Sessionshantering | Infrastrukturkrav | klart | Efter inloggning sparas JWT payload i session för skyddade vyer. | icke | 8 | 1,2,3,5,7,9,10 | |
| Dashboard | Funktionellt krav | klart | En personlig dashboard visas när användaren är inloggad. | icke | 8 | 1,2,3,5,7,9,10,11 | |
| Skyddad dashboard | Kvalitetskrav | klart | Om inte inloggad redirectas man till /login. | icke | 9 | 1,2,3,5,7,9,10,11,12 | |
| Logout-funktion | Funktionellt krav | klart | Användaren ska kunna logga ut (session ska tas bort). | icke | 6 | 1,2,3,5,7,9,10,11 | |
| Google-inloggning via Firebase | Funktionellt krav | klart | Inloggning via Firebase och popup ska vara möjlig. | Om denna parallellt existerar med manuell login och kod verifiering, kan det leda till konflikter eller oklara användarflöden antagligen. | 10 | 1,2,15 | |
| Användarbesök på startsidan | Funktionellt krav | klart | Applikationen ska registrera varje gång en användare besöker hemsidan. | icke | 2 | 1,2,5 | |
| Anonym feedback-funktion | Funktionellt krav | klart | Användare ska kunna skicka in feedback på startsidan utan att vara inloggade | icke | 2 | 1,2,5 | |
| Verifiering via mejl efter inloggning | Funktionellt krav (Säkerhetskrav) | klart | Efter lyckad inloggning skickas ett mejl med en kod. Denna kod krävs på dashboard-sidan för att kunna visa användarens lösenord. | Risk för konflikt om olika metoder för inloggning (Firebase vs egen auth) hanterar verifiering olika. | 8 | 1,2,5,7,9,10,11,12,13,15 | |
| Dashboard-knapp för att generera lösenord | Funktionellt krav | klart | En knapp i dashboarden ska kunna skapa ett nytt, säkert lösenord. | icke | 7 | 1,2,5,11,1 | |
| Spara lösenord i användarens vault | Funktionellt krav | klart | Lösenord som genereras eller matas in ska lagras i användarens dashboard. | icke | 9 | 1,2,3,5,11,12 | |
| Inputfält för e-postkodverifiering | Funktionellt krav | klart | Användaren ska kunna ange kod som skickats via e-post vid registrering. | Kan orsaka problem om kod hantering inte är korrekt implementerad mellan registrering och login. | 8 | 1,2,5,18 | |
| Automatisk utloggning av inaktiv användare | Funktionellt krav | klart | Systemet ska logga ut användaren efter inaktivitet (t.ex. 15 minuter). | icke | 6 | 1,2,3,5,11 | |
| Glömt lösenord-hantering | Funktionellt krav | klart | Användaren ska kunna påbörja återställning av lösenordet via sin e-postadress. | Tydlig hantering av e-post, sessions och kod – kan skapa konflikt om koden inte är väll strukturerat | 5 | 1,2,3,5,7,9,18 | |
| Egen lösenordssida | Funktionellt krav | klart | En separat sida där användaren kan välja mellan olika altermativ | icke | 7 | 1,2,5,7,20 | |
| Historik för lösenord | Funktionellt krav | klart | Användaren ska kunna komma åt lösenordssida och kunna ser en historik angående lösenorden. | icke | 6 | 1,2,5,7,20 | |
| Postkodverifiering updateras | Funktionellt krav | klart | Användaren ska kunna använda samma kod om nyckeln inte "expired" |
Om nyckeln inte "expired" – detta kan motsäga säkerhetsprinciper där en kod normalt är engångsbruk. |
5 | 1,2,5,7,18,21 | |
| Säkerhet | Icke funtionela krav | klart | Alla lösenord ska sparas hashade (bcrypt). JWT måste vara signerat med RSA. | icke | 10 | 1,2,3 | |
| Tillgänglighet | Icke funtionela krav | klart | Webbsidan ska kunna användas i moderna webbläsare (Chrome, Firefox, Safari) | icke | 10 | 1,2,5 | |
| Robusthet | Icke funtionela krav | klart | Systemet ska hantera fel (t.ex. databaskrascher) utan att användaren får en vit sida. | icke | 10 | 1,2,3 | |
| Lösenord sida | Funktionellt krav | klart | Användaren ska kunna komma åt lösenord sidan som ska fungerar som en CRUD. | icke | 10 | 1,2,3,5,12,20 | |
| Kod struktur | Icke funtionela krav | klart | Kod strukturen ska vara vällstrukturerat för lätt att förstår. | icke | 7 | 1,2,5 | |
| Lint check | Icke funtionela krav | klart | alla microservices ska har gott genom lint och blivit godkända. | icke | 5 | 1,2,3,5 | |
| Nedladningsbar webbapplikation | Funktionellt krav | klart | användaren ska kunna ladda ner webbapplikationen och använda den online. | icke | 4 | 1,2,5,30 |