features functional requirements
Acest tutorial explică tipurile, caracteristicile, compararea cerințelor funcționale față de cerințele nefuncționale și a cerințelor de business față de cerințele funcționale cu exemple:
Cerințele funcționale definesc ce ar trebui să facă un sistem software. Definește o funcție a unui sistem software sau a modulului său. Funcționalitatea este măsurată ca un set de intrări în sistemul testat la ieșirea din sistem.
Implementarea cerințelor funcționale într-un sistem este planificată în faza de proiectare a sistemului, în timp ce, în cazul cerințelor nefuncționale, este planificată în documentul Arhitectura sistemului. Cerința funcțională acceptă generarea de cerințe nefuncționale.
Ce veți învăța:
Cerințe funcționale și cerințe nefuncționale
Cerințe funcționale
Să înțelegem care sunt cerințele funcționale cu ajutorul exemplelor-
Exemplu: Într-un proiect ADAS pentru automobile, o cerință funcțională a sistemului de vizualizare surround ar putea fi „Camera din spate ar trebui să detecteze o amenințare sau un obiect”. Cerințele nefuncționale aici ar putea fi „cât de repede ar trebui afișată alerta către un utilizator atunci când o amenințare este detectată de senzorii camerei”.
Ia altul exemplu a proiectului de sisteme Infotainment. Utilizatorul activează Bluetooth aici de pe HMI și verifică dacă Bluetooth este activat sau nu. Notă , alte servicii Bluetooth sunt activate (de la gri la bold) atunci când utilizatorul activează Bluetooth.
intrare fișiere de ieșire c ++
Deci, cerințele funcționale vorbesc despre un anumit rezultat al sistemului atunci când utilizatorul le efectuează o sarcină. Pe de altă parte, cerința nefuncțională dă comportamentul general al sistemului sau al componentei sale și nu funcțional.
Tipuri de cerințe funcționale
Cerințele funcționale ar putea include următoarele componente care pot fi măsurate ca parte a testării funcționale:
# 1) Interoperabilitate: Cerința descrie dacă un sistem software este interoperabil între diferite sisteme.
Exemplu: Pentru cerința funcțională Bluetooth în sistemul de infotainment auto, atunci când utilizatorul împerechează un smartphone bazat pe Android activat Bluetooth la un sistem de infotainment bazat pe QNX, ar trebui să putem transfera agenda telefonică la sistemul de infotainment sau să redăm muzică de pe dispozitivul nostru telefonic la sistemul de infotainment.
Deci, interoperabilitatea verifică dacă comunicarea între cele două dispozitive diferite este posibilă sau nu.
O alta exemplu provine din sistemele de servicii de e-mail precum Gmail. Gmail permite importul de e-mailuri de pe un alt server de schimb de e-mail, cum ar fi Yahoo.com sau Rediffmail.com. Acest lucru este posibil datorită interoperabilității între serverele de e-mail.
# 2) Securitate: Funcționalul cerința descrie aspectul de securitate al cerințelor software.
Exemplu: Servicii bazate pe securitate cibernetică în sistemul bazat pe cameră surround ADAS care utilizează rețeaua de controler (CAN) care protejează sistemul de amenințarea la adresa securității.
O alta exemplu este de pe site-ul de socializare Facebook . Datele unui utilizator ar trebui să fie sigure și să nu fie difuzate către un extern. Sperăm că acest exemplu de Facebook oferă cititorilor o perspectivă mai largă asupra securității, datorită incidenței recente a încălcării datelor de pe Facebook și a consecințelor cu care se confruntă Facebook.
# 3) Precizie: Precizia definește faptul că datele introduse în sistem sunt calculate și utilizate corect de sistem și că ieșirea este corectă.
Exemplu: În rețeaua de zonă a controlerului, atunci când o valoare a semnalului CAN este transmisă pe magistrala CAN de către un ECU (și anume unitatea ABS, unitatea HVAC, unitatea grupului de instrumente etc.) un alt ECU va putea identifica dacă datele trimise sunt corecte sau nu prin verificare CRC.
O alta exemplu poate proveni dintr-o soluție bancară online. Atunci când utilizatorul primește un fond, suma primită trebuie să fie creditată exact în cont și nu se acceptă nicio variație a acurateței.
# 4) Conformitate: Cerințele funcționale de conformitate confirmă faptul că sistemul dezvoltat este conform cu standardele industriale.
Exemplu: Indiferent dacă funcționalitățile profilurilor Bluetooth (și anume streaming audio prin A2DP, apel telefonic prin HFP) sunt compatibile cu versiunile de profil de lansare Bluetooth SIG.
O alta exemplu poate fi cea a jocului Apple Car în sistemul de infotainment auto. Aplicația din infotainment primește un certificat de la măr dacă toate condițiile prealabile menționate pe site-ul web Apple sunt îndeplinite de dispozitivele Car Play terțe (infotainment în acest caz).
O alta exemplu poate fi dintr-o aplicație bazată pe web pentru sistemul de bilete de tren. Site-ul web ar trebui să respecte orientările privind securitatea cibernetică și să respecte World Wide Web în ceea ce privește accesibilitatea.
Exemplu de formular de cerință:
Am văzut deja care este cerința funcțională cu câteva exemple. Să vedem acum cum ar arăta o cerință funcțională atunci când este integrată în instrumente de gestionare a cerințelor precum IBM DOORS. Există mai multe atribute care trebuie luate în considerare la documentarea unei cerințe funcționale în instrumentul de gestionare a cerințelor.
Mai jos sunt câteva atribute care trebuie luate în considerare:
- Tipul obiectului: Acest atribut explică ce secțiune din documentul de cerință face parte din acest atribut. Acestea ar putea fi Titlu, Explicație, Cerință, etc. În general, secțiunea „Cerință” este luată în considerare pentru implementare și testare, în timp ce secțiunile de titlu și explicații sunt utilizate ca descrieri suport pentru cerințele pentru o mai bună înțelegere.
- Persoana responsabila: Un autor care a documentat cerința în instrumentul de gestionare a cerințelor.
- Nume proiect / sistem: Proiectul pentru care este aplicabilă cerința, de exemplu, „Sisteme de infotainment pentru XYZ OEM (producător de echipamente originale) o companie auto sau aplicație web pentru compania ABC banking limited”.
- Numărul versiunii cerinței: Acest câmp / atribut notifică numărul de versiune al cerinței dacă cerința a suferit mai multe modificări din cauza actualizărilor clienților sau a modificărilor în proiectarea sistemului.
- ID cerință: Acest atribut menționează codul unic de cerință. Identificarea cerinței este utilizată pentru a urmări cu ușurință cerințele din baza de date și, de asemenea, pentru cartografierea cerințelor în cod în mod eficient. Poate fi, de asemenea, utilizat pentru a furniza o referință la cerințe în timp ce înregistrați defecte în instrumentele de urmărire a erorilor.
- Descrierea cerinței: Acest atribut este unul dintre cele mai importante atribute care explică cerința. Citind acest atribut, un inginer ar putea înțelege cerința.
- Starea cerinței: Atributul stării cerințelor spune despre starea unei cerințe în instrumentul de gestionare a cerințelor, adică dacă este acceptat, în așteptare, respins sau șters proiectul.
- Comentarii: Acest atribut oferă persoanei responsabile sau managerului de cerințe o opțiune de a documenta orice comentariu cu privire la cerință. Exemplu: un posibil comentariu pentru o cerință funcțională ar putea fi „dependența de un pachet software terță parte pentru implementarea cerinței”.
Un instantaneu de la UȘI
Derivarea cerințelor funcționale din cerințele de afaceri
Acest lucru este deja acoperit ca parte a secțiunii „ Derivarea cerințelor funcționale din cerințele afacerii ' sub Analiza cerințelor articol.
Cerințe comerciale vs. cerințe funcționale
Această diferență este acoperită în mod vag în Analiza cerințelor articol. Cu toate acestea, vom încerca să evidențiați încă câteva puncte aici în tabelul de mai jos:
| Sl. Nu. | Cerințe de afaceri | Cerințe funcționale |
|---|---|---|
| 7 | De exemplu, în sistemul bancar online, o cerință comercială ar putea fi „În calitate de utilizator, ar trebui să pot obține extrasul de tranzacții în numerar”. | Cerința funcțională în acest sistem bancar online ar putea fi: „Când utilizatorul furnizează intervalul de date în interogarea tranzacției, această intrare este utilizată de Server și pagina web este furnizată cu datele necesare tranzacțiilor în numerar”. |
| 1 | Cerințele comerciale spun „ce” aspect al cerinței clientului. Exemplu, Ce ar trebui să fie vizibil pentru utilizator după conectarea utilizatorului. | Cerințele funcționale spun aspectul „cum” al cerințelor afacerii. Exemplu, Modul în care pagina web ar trebui să afișeze pagina de conectare a utilizatorului atunci când utilizatorul se autentifică. |
| Două | Cerințele afacerii sunt identificate de analiștii afacerii. | Cerințele funcționale sunt create / derivate de dezvoltatori / arhitectul software |
| 3 | Acestea pun accentul pe beneficiul organizației și sunt legate de obiectivele de afaceri. | Scopul lor este îndeplinirea cerințelor clienților. |
| 4 | Cerințele de afaceri sunt de la Client. | Cerințele funcționale sunt derivate din cerințele software, care, la rândul lor, sunt derivate din cerințele afacerii. |
| 5 | Cerințele comerciale nu sunt testate direct de inginerii de testare software. Acestea sunt testate în principal de către client. | Cerințele funcționale sunt testate de inginerii de testare a software-ului și, în general, nu sunt testate de clienți. |
| 6 | Cerința de afaceri este un document de cerințe la nivel înalt. | O cerință funcțională este un document detaliat de cerințe tehnice. |
Cerință nefuncțională
Cerința nefuncțională spune despre „ce ar trebui să fie un sistem” mai degrabă decât „ce ar trebui să facă un sistem” (cerință funcțională). Acestea sunt în mare parte derivate din cerințe funcționale bazate pe contribuția clientului și a altor părți interesate. Detaliile de implementare a cerințelor nefuncționale sunt documentate în documentul Arhitectura sistemului.
Cerințele nefuncționale explică aspectele de calitate ale sistemului care urmează să fie construit și anume. performanță, portabilitate, utilizare, etc. Cerințele nefuncționale, spre deosebire de cerințele funcționale, sunt implementate incremental în orice sistem.
URPS (Utilizare, fiabilitate, performanță și suportabilitate) de la FURPS Atributele de calitate (funcționalitate, utilizare, fiabilitate, performanță și suportabilitate) care sunt utilizate pe scară largă în industria IT pentru a măsura calitatea unui dezvoltator de software sunt toate acoperite de cerințe nefuncționale. În plus, există și alte atribute de calitate (detalii în secțiunea următoare).
Wikipedia numește uneori cerința nefuncțională drept „ilități”, datorită prezenței diferitelor atribute de calitate, cum ar fi portabilitatea și stabilitatea.
Tipuri de cerințe nefuncționale
Cerințele nefuncționale constau din subtipuri de mai jos (neexhaustive):
# 1) Performanță:
Un tip de atribut de performanță de cerință nefuncțională măsoară performanța sistemului. Exemplu: În sistemul de vizualizare surround ADAS, „vizualizarea camerei din spate ar trebui să fie afișată în decurs de 2 secunde de la pornirea contactului auto”.
O alta exemplu de performanță ar putea proveni dintr-un sistem de navigație a sistemelor de infotainment. „Când un utilizator merge la ecranul de navigare și intră în destinație, ruta trebuie calculată în„ X ”secunde”. Încă una exemplu din pagina de autentificare a aplicației web. „Timpul necesar pentru încărcarea paginii profilului utilizatorului după autentificare.”
Rețineți că măsurarea performanței sistemului este diferită de măsurarea sarcinii. În timpul testării încărcării, încărcăm CPU-ul și RAM-ul sistemului și verificăm randamentul sistemului. În cazul performanței, testăm randamentul sistemului în condiții normale de sarcină / solicitare.
# 2) Utilizare :
Utilizabilitatea măsoară utilizabilitatea sistemului software în curs de dezvoltare.
De exemplu , este dezvoltată o aplicație web mobilă care vă oferă informații despre instalatorii și disponibilitatea electricianului în zona dvs.
Intrarea în această aplicație este codul poștal și raza (în kilometri) față de locația dvs. curentă. Dar pentru a introduce aceste date, dacă utilizatorul trebuie să parcurgă mai multe ecrane și opțiunea de introducere a datelor este afișată în casete de text mici care nu sunt ușor vizibile pentru un utilizator, atunci această aplicație nu este ușor de utilizat și, prin urmare, utilizarea aplicației va fi foarte jos.
Implementarea listei c ++ legată dublu
# 3) Mentenabilitate :
Mentenabilitatea unui sistem software este ușurința cu care sistemul poate fi întreținut. Dacă timpul mediu dintre defecțiuni (MTBF) este scăzut sau Timpul mediu de reparație (MTTR) este ridicat pentru sistemul dezvoltat, atunci menținerea sistemului este considerată scăzută.
Mentenabilitatea este adesea măsurată la nivel de cod folosind complexitatea ciclomatică. Complexitatea ciclomatică spune că cu cât este mai puțin complex codul, cu atât este mai ușor de întreținut software-ul.
Exemplu: Este dezvoltat un sistem software care are un număr mare de coduri moarte (coduri care nu sunt utilizate de alte funcții sau module), foarte complex datorită utilizării excesive a condiției if / else, buclelor imbricate etc. sau dacă sistemul este imens cu coduri care rulează în multe milioane de linii de coduri și fără comentarii adecvate. Un astfel de sistem are un nivel scăzut de întreținere.
O alta exemplu ar putea fi o pagină de cumpărături online. Dacă există multe linkuri externe pe site, astfel încât utilizatorul să aibă o imagine de ansamblu asupra produsului (aceasta pentru a economisi în memorie), atunci menținerea acestui site este redusă. Acest lucru se datorează faptului că, dacă linkul paginii web externe se modifică, trebuie actualizat și pe site-ul de cumpărături online și prea frecvent.
# 4) Fiabilitate :
Fiabilitatea este un alt aspect al disponibilității. Acest atribut de calitate subliniază disponibilitatea unui sistem în anumite condiții. Se măsoară ca MTBF la fel ca mentenabilitatea.
Exemplu: Funcțiile care se exclud reciproc, cum ar fi camera retrovizoare și Trailer în sistemul de camere surround ADAS, ar trebui să funcționeze în mod fiabil în sistem, fără interferențe între ele. Când un utilizator apelează caracteristica Trailer, retrovizoarea nu trebuie să interfereze și invers, deoarece ambele caracteristici accesează camera din spate a mașinii.
O alta exemplu din sistemul de daune de asigurare online. Când un utilizator începe raportarea reclamației și apoi încarcă facturile de cheltuieli relevante, sistemul ar trebui să acorde suficient timp pentru finalizarea încărcării și nu ar trebui să anuleze rapid procesul de încărcare.
# 5) Portabilitate:
Portabilitatea înseamnă capacitatea unui sistem software de a lucra într-un mediu diferit dacă cadrul dependent de bază rămâne același.
Exemplu: Sistemul software / componenta dintr-un sistem de infotainment dezvoltat (și anume serviciul Bluetooth sau serviciul multi-media) pentru un producător de automobile ar trebui să poată fi utilizat într-un alt sistem de infotainment cu modificări reduse sau deloc ale codului, deși cele două sisteme de infotainment sunt complet diferite .
Să luăm altul exemplu de pe WhatsApp. Este posibil să instalați și să utilizați serviciul de mesagerie pe IOS, Android, Windows, tabletă, laptop și telefon.
# 6) Suportabilitate:
Facilitatea de întreținere a unui sistem software este capacitatea unui expert de service / tehnic de a instala sistemul software într-un mediu în timp real, de a monitoriza sistemul în timp ce rulează, de a identifica orice probleme tehnice din sistem și de a oferi o soluție pentru rezolvarea problemei.
Facilitatea de întreținere este posibilă dacă sistemul este dezvoltat pentru a facilita întreținerea.
Exemplu: Furnizarea de memento periodic utilizatorului pentru o actualizare software, furnizarea unui mecanism de înregistrare / urmărire pentru depanarea problemelor, recuperare automată de la eșec prin intermediul mecanismului de revenire (readuceți sistemul software la starea anterioară a stării de lucru).
O alta exemplu din Rediffmail. Când a existat o actualizare a versiunii serviciului de corespondență bazat pe web, sistemul a permis utilizatorului să treacă la o versiune mai nouă a sistemului de corespondență, păstrând cea mai veche intactă timp de câteva luni. Acest lucru îmbunătățește și experiența utilizatorului.
# 7) Adaptabilitate:
Adaptabilitatea unui sistem este definită ca fiind capacitatea unui sistem software de a se adapta la schimbările dintr-un mediu fără a se modifica comportamentul acestuia.
Exemplu: Sistemul de frânare antiblocare în mașină ar trebui să funcționeze conform standardului în toate condițiile meteorologice (cald sau rece). O alta exemplu ar putea fi cel al unui sistem de operare Android. Este utilizat în diferite tipuri de dispozitive, și anume. Smartphone-urile, computerele tabletă și sistemele Infotainment sunt extrem de adaptabile.
Pe lângă cele 7 cerințe nefuncționale enumerate mai sus, avem multe altele precum:
Accesibilitate, Backup, Capacitate, Conformitate, Integritate a datelor, Păstrarea datelor, Dependență, Implementare, Documentare, Durabilitate, Eficiență, Exploitabilitate, Extensibilitate, Gestionare eșecuri, Toleranță la erori, Interoperabilitate, Modificabilitate, Operabilitate, Confidențialitate, Citibilitate, Raportare, Reziliență, Reutilizare, Robustitate, scalabilitate, stabilitate, testabilitate, randament, transparență, integrabilitate.
Acoperirea tuturor acestor cerințe nefuncționale este în afara scopului acestui articol. Cu toate acestea, puteți citi mai multe despre aceste tipuri de cerințe nefuncționale în Wikipedia.
Derivarea cerințelor nefuncționale din cerințele funcționale
Cerințele nefuncționale pot fi derivate în mai multe moduri, dar cel mai bun și cel mai industrial mod încercat și testat este din cerințele funcționale.
Să luăm exemplul din sistemele noastre de infotainment pe care le-am luat deja în câteva locuri în acest articol. Utilizatorul poate efectua multe acțiuni pe sistemul Infotainment, și anume. schimbați melodia, schimbați sursa melodiei de la USB la FM sau audio Bluetooth, setați destinația de navigare, actualizați software-ul de infotainment printr-o actualizare de software etc.
# 1) Adunarea cerințelor nefuncționale:
Vom enumera sarcinile efectuate de un utilizator, care face parte din cerințele funcționale. Odată ce acțiunile utilizatorului sunt notate în diagrama cazului de utilizare UML (fiecare oval), vom începe întrebări relevante (fiecare dreptunghi) cu privire la acțiunile fiecărui utilizator. Răspunsurile la aceste întrebări vor oferi cerințele noastre nefuncționale.
# 2) Clasificarea cerințelor nefuncționale:
Următorul pas este clasificarea cerințelor nefuncționale pe care le-am identificat prin întrebări. În această etapă, putem verifica răspunsul posibil și clasifica răspunsurile la posibile categorii nefuncționale sau calități diferite.
În imaginea de mai jos puteți vedea atributele de calitate posibile identificate din răspunsuri.
Funcțional Vs Cerințe nefuncționale
Am văzut deja ce sunt și cum sunt derivate cerințele funcționale și nefuncționale. Să aruncăm o privire asupra diferențelor majore dintre cerințele funcționale și nefuncționale.
| Sl. Nu | Cerințe funcționale (FR) | Cerințe nefuncționale (NFR) |
|---|---|---|
| 7 | Cerințele funcționale formează scheletul implementării sistemului software | Cerințele nefuncționale completează sistemul SW ajutând cerințele funcționale să se lipească, ca un mușchi. |
| 1 | Ei spun, ce ar trebui să facă un sistem. | Ei spun, ce ar trebui să fie un sistem. |
| Două | Acestea sunt detaliate în documentul de proiectare a sistemului. | Acestea sunt detaliate în documentul Arhitectura sistemului. |
| 3 | Vorbesc despre comportamentul unei funcții sau caracteristici. | Aceștia vorbesc despre comportamentul de lucru al unui întreg sistem sau al unei componente a sistemului și nu o anumită funcție. |
| 4 | Utilizatorul va transmite intrarea și va verifica dacă ieșirea este afișată corect. | Când utilizatorul transmite o intrare, la următoarele întrebări pot fi răspunsuri de către NFR-uri: i) Cât timp este necesar pentru a afișa ieșirea? ii) Este rezultatul în concordanță cu timpul? iii) Există alte modalități de a trece parametrul de intrare? iv) Cât de ușor este să treceți parametrul de intrare? |
| 5 | Într-o aplicație web, utilizatorul ar trebui să se poată autentifica prin autentificare este FR | Într-o aplicație web, cât timp durează pentru a vă conecta la site-ul web, aspectul paginii de autentificare, ușurința utilizării unei pagini web etc. fac parte din NFR |
| 6 | Cerințele funcționale sunt derivate mai întâi din cerințele software. | Cerințele nefuncționale sunt derivate din cerințele funcționale. |
| 8 | Cerințele funcționale pot exista fără o cerință nefuncțională. | Cerințele nefuncționale nu pot exista fără cerințe funcționale. |
| 9 | O cerință funcțională oferă informații concrete despre o caracteristică, Exemplu , Fotografia de profil de pe Facebook ar trebui să fie vizibilă la conectare. | O cerință funcțională poate avea multe atribute de cerințe nefuncționale. Exemplu, timpul de conectare (performanță), aspectul paginii de profil (utilizare), numărul de utilizatori care se pot conecta simultan (capacitate, performanță) |
| 10 | Derivarea cerințelor funcționale din cerințele SW este posibilă pentru aproape toate cerințele companiei | NFR-urile sunt adesea ratate pentru a fi documentate, deoarece întrebările relevante nu sunt puse pe RF-uri. |
| unsprezece | Implementarea unei cerințe funcționale se face în mod normal într-o singură versiune de software. | NFR-urile sunt implementate pe tot parcursul ciclului de viață al proiectului până la atingerea comportamentului dorit. |
| 12 | Acestea sunt în mare parte vizibile pentru client. | Acestea nu sunt în mare parte vizibile pentru client, dar ar putea fi experimentate pe termen lung. Exemplu, Utilizarea, performanța etc. pot fi experimentate numai pe termen lung, dar nu pot fi deloc vizibile. |
Concluzie
Cerințele formează elementul de bază pentru dezvoltarea oricărui sistem software. Este posibil să se construiască un sistem cu cerințe funcționale, dar abilitățile sale nu pot fi determinate și nici măsurate. Acestea fiind spuse, este foarte important să aveți cerințe funcționale de bună calitate derivate dintr-o cerință de afaceri pentru a avea un sistem software de lucru de înaltă calitate.
Prin urmare, cerințele funcționale oferă direcția de implementare a unui sistem software, dar cerințele nefuncționale determină calitatea implementării pe care o vor experimenta utilizatorii finali.
Lectură recomandată
- Cum se testează specificațiile cerințelor software (SRS)?
- Testarea funcțională Vs testarea nefuncțională
- Cum se testează o aplicație fără cerințe?
- Ce este analiza și colectarea cerințelor în SDLC?
- 5 greșeli mortale în gestionarea cerințelor și cum să le depășești
- Caracteristici ale cerințelor funcționale și ale cerințelor nefuncționale
- Cum se creează matricea de trasabilitate a cerințelor (RTM): exemplu și șablon de probă
- Top 20+ Cele mai bune instrumente de gestionare a cerințelor (Lista completă)