Rolurile unei aplicații trebuie definite prin acțiuni și informații, nu doar prin nume. „Client”, „operator” și „administrator” nu explică singure ce poate vedea sau modifica fiecare.
O structură clară ajută proiectarea, ofertarea și testarea accesului. Regulile trebuie aplicate în sistemele potrivite, nu doar prin ascunderea unor butoane.
Identifică sarcinile fiecărui rol
Notează obiectivul și operațiunile necesare. Distinge persoana care trimite o cerere de cea care o evaluează sau confirmă.
Nu acorda acces larg doar pentru a simplifica demonstrația. Un rol trebuie să primească informația și operațiunile potrivite responsabilității sale.
Definește aria datelor
Arată dacă utilizatorul vede numai propriile înregistrări, ale unei organizații sau alte date autorizate. Aceste reguli trebuie să fie explicite.
Un cont autentificat nu trebuie presupus autorizat pentru orice referință pe care o poate introduce. Verificarea accesului este o cerință tehnică distinctă de designul ecranului.
Separă vizualizarea de modificare
Citirea, crearea, editarea și aprobarea sunt operațiuni diferite. Un operator poate avea nevoie de unele fără să le primească automat pe toate.
Definește și schimbările de stare. O persoană care completează informații nu trebuie să poată confirma o decizie care aparține altui rol, dacă procesul nu o autorizează.
Pregătește situațiile de schimbare
Stabilește ce se întâmplă când utilizatorul pleacă din organizație sau își schimbă rolul. Datele și responsabilitățile trebuie tratate prin procesul real.
Nu confunda ștergerea unei pictograme de meniu cu retragerea accesului. Implementarea și verificările trebuie să acopere operațiunile, nu numai interfața vizibilă.
Caz demonstrativ: două companii în aceeași aplicație
Un utilizator al primei companii trebuie să poată realiza sarcinile sale fără acces la datele celeilalte. Testele folosesc organizații și înregistrări sintetice separate.
Verifică lista, detaliul, exportul și modificarea. O restricție aplicată numai în pagina principală nu dovedește că toate traseele respectă regula.
Construiește matricea de acces
Pentru fiecare tip de înregistrare, notează operațiunile permise și aria datelor. Include rolurile administrative și acțiunile care necesită confirmare.
Folosește matricea la testare și după extinderea produsului. O funcție nouă poate introduce o cale de acces care nu este acoperită de regulile vechi.
Leagă rolurile de brief
Aceste decizii influențează ecranele, serviciile de server și criteriile de acceptare. Ele trebuie discutate înainte de o estimare bazată numai pe aspect.
Prin formularul ITroom, poți descrie utilizatorii și datele aplicației. Evaluarea tehnică și verificarea accesului se stabilesc după flux, cu livrabile concrete și fără promisiunea că simpla autentificare rezolvă toate riscurile.
Controlează un acces nepermis
În mediul de test, folosește un rol care nu trebuie să poată modifica o anumită înregistrare. Verifică rezultatul operațiunii, nu doar absența butonului. Păstrează proba și regula din matrice, astfel încât funcțiile adăugate ulterior să poată fi controlate după același criteriu.
Ghid editorial ITroom pentru pregătirea unui proiect digital. Exemplele demonstrative se adaptează informațiilor reale ale afacerii; nu reprezintă rezultate garantate sau recomandări profesionale individuale.
Vezi serviciul de dezvoltare aplicații iOS și Android, diferența dintre prototip și produsul funcțional, livrabilele și costurile separate. Începem cu utilizatorii și fluxul pe care trebuie să-l poată finaliza.