Što je funkcionalni zahtjev u softverskom inženjerstvu?

By: Charles Moore Charles Moore
Hours Ažurirano

⚡ Pametni sažetak

Funkcionalni zahtjevi opisuju svaku uslugu koju softverski sustav mora ponuditi, bilježeći ulaze, ponašanje i izlaze kako bi programeri, testeri i poslovni dionici dijelili jednu, provjerljivu definiciju onoga što proizvod zapravo mora raditi.

  • 📘 Definicija: Funkcionalni zahtjev, također nazvan funkcionalna specifikacija, navodi što sustav mora raditi - ulaze, ponašanje i izlaze, opisane iz korisničke ili poslovne perspektive.
  • 📄 Opseg dokumenta: Dokument funkcionalnih zahtjeva obuhvaća operacije zaslona, ​​logiku rukovanja podacima, izvješća, tijekove rada, dozvole i usklađenost s propisima.
  • 🗂️ Uobičajene vrste: Obrada transakcija, poslovna pravila, izvještavanje, administrativne funkcije, razine autorizacije, revizija trackralj, vanjska sučelja i pravni zahtjevi.
  • 💡 Primjeri: Validacija prijave, evidentiranje prodaje, pregled prihoda temeljen na ulogama, integracija bankarskog API-ja i usklađenost s pristupačnošću nalaze se unutar funkcionalnih zahtjeva.
  • 🆚 Nefunkcionalni kontrast: Funkcionalni zahtjevi opisuju što sustav radi; nefunkcionalni zahtjevi opisuju koliko dobro to radi - performanse, sigurnost i upotrebljivost.
  • ✅ Najbolje prakse: Zahtjeve treba održavati granularnima, testiranima i mapiranima na poslovni cilj te ih utvrditi putem intervjua i radionica.
Pročitaj više

Funkcionalni zahtjev u softverskom inženjerstvu

Što je funkcionalni zahtjev?

A Funkcionalni zahtjev (FR) je opis usluge koju softver mora ponuditi. Opisuje softverski sustav ili njegovu komponentu. Funkcija je definirana ulazima, ponašanjem i izlazima. To može biti izračun, manipulacija podacima, poslovni proces ili interakcija s korisnikom koja definira što sustav mora učiniti. Funkcionalni zahtjevi u softverskom inženjerstvu nazivaju se i Funkcionalne specifikacije.

Funkcionalni zahtjev kreće se od potrebe visokorazinske zainteresirane strane do detaljne matematičke specifikacije. Funkcionalni softver zahtjevi obuhvaćaju namjeravano ponašanje sustava.

Što uključiti u dokument funkcionalnih zahtjeva

Evo što bi dokument s funkcionalnim zahtjevima trebao obuhvaćati:

Primjer funkcionalnih zahtjeva

Primjer funkcionalnih zahtjeva

Dokument funkcionalnih zahtjeva obično uključuje:

  • Detalji operacija provedenih na svakom zaslonu
  • Logika rukovanja podacima koju sustav mora primijeniti
  • Descriptizvješća sustava i drugih rezultata
  • Potpune informacije o tijekovima rada koje sustav izvršava
  • Tko smije kreirati, mijenjati ili brisati podatke u sustavu
  • Kako sustav ispunjava primjenjive regulatorne i usklađene potrebe

Prednosti funkcionalnih zahtjeva

Glavne prednosti dobro napisanog dokumenta funkcionalnih zahtjeva su:

  • Potvrđuje da aplikacija isporučuje svaku navedenu funkciju
  • Definira funkcionalnost sustava i njegovih podsustava na jednom mjestu
  • U kombinaciji s analizom zahtjeva, funkcionalni zahtjevi pomažu u identificiranju nedostajućih potreba i razjašnjavanju očekivanog ponašanja sustava
  • Greške uočene u fazi zahtjeva najjeftinije se ispravljaju
  • Podržava korisničke ciljeve, zadatke i aktivnosti

Vrste funkcionalnih zahtjeva

Uobičajene kategorije funkcionalnih zahtjeva uključuju:

  • Rukovanje transakcijom
  • Poslovna pravila
  • Certifikacija Zahtjevi
  • Zahtjevi za izvješćivanjem
  • Upravne funkcije
  • Razine autorizacije
  • Revizija Tracking
  • Vanjska sučelja
  • Upravljanje povijesnim podacima
  • Pravni i regulatorni zahtjevi

POVEZANI ČLANCI

Primjeri funkcionalnih zahtjeva

U nastavku su navedeni praktični primjeri funkcionalnih zahtjeva:

  • Softver će automatski provjeravati identitet korisnika u sustavu za upravljanje kontaktima ABC.
  • Prodajni sustav mora omogućiti korisnicima evidentiranje prodaje kupaca.
  • Boja pozadine za sve prozore u aplikaciji mora biti plava s heksadecimalnom RGB vrijednošću 0x0000FF.
  • Samo zaposlenici na rukovodećoj razini imaju pravo pregleda podataka o prihodima.
  • Softverski sustav će se integrirati s bankarskim API-jem.
  • Softverski sustav mora ispunjavati Odjeljak 508 zahtjevi za pristupačnost.

Funkcionalni i nefunkcionalni zahtjevi

Evo ključnih razlika između funkcionalnih i nefunkcionalnih zahtjeva u Programsko inženjerstvo:

Parametri Funkcionalni zahtjev Nefunkcionalni zahtjev
Što je Glagol Značajke
Zahtjev To je obavezno Nije obavezan
Tip hvatanja Hvata se u slučaju upotrebe. Uhvaćen je kao atribut kvalitete.
Krajnji rezultat Značajka proizvoda Svojstva proizvoda
snimanje Lako za snimanje Teško za uhvatiti
Cilj Pomaže vam provjeriti funkcionalnost softvera. Pomaže vam da provjerite učinkovitost softvera.
Područje fokusa Usredotočite se na zahtjeve korisnika Koncentrira se na očekivanja korisnika.
Dokumentacija Opišite čemu proizvod služi Opisuje kako proizvod radi
Vrsta testiranja Funkcionalno testiranje poput sustava, integracije, end to end, API testiranje, Itd Nefunkcionalna testiranja kao što su izvedba, stres, upotrebljivost, Ispitivanje sigurnosti, Itd
Izvršenje testa Izvršavanje testiranja se vrši prije nefunkcionalnog testiranja. Nakon funkcionalnog ispitivanja
Informacije o proizvodu Značajke proizvoda Svojstva proizvoda

Najbolje prakse za pisanje funkcionalnih zahtjeva

Najvažnije najbolje prakse za pisanje dokumenta funkcionalnih zahtjeva su:

  • Nemojte kombinirati dva zahtjeva u jedan; svaki zahtjev treba biti detaljan.
  • Učinite svaki zahtjev što potpunijim i točnijim.
  • Nacrtajte sve tehničke zahtjeve u dokumentu.
  • Povežite svaki zahtjev s ciljevima i principima koji pokreću uspješnu isporuku softvera.
  • Utvrdite zahtjeve putem intervjua, radionica i neformalnih razgovora.
  • Dokumentirajte svako poznato, provjereno ograničenje koje materijalno utječe na zahtjev.
  • Zabilježite svaku pretpostavku u dokumentu.

Uobičajene pogreške pri pisanju funkcionalnih zahtjeva

Uobičajene pogreške koje se događaju prilikom izrade dokumenta funkcionalnih zahtjeva uključuju:

  • Dodavanje neopravdanih dodatnih informacija koje zbunjuju razvojne programere
  • Izostavljanje detalja koje programeri trebaju za izgradnju značajke.
  • Pravila miješanja, primjeri, scoping izjave ili ciljeve u sam zahtjev.
  • Izostavljanje informacija koje su bitne za potpuno i točno navođenje zahtjeva.
  • Braniti postojeći zahtjev kada stigne zahtjev za promjenom, umjesto pronaći točan odgovor.
  • Zahtjevi za pisanje koji nisu povezani s bilo kojim ciljem ili načelom.

Pitanja i odgovori

Alati umjetne inteligencije grupiraju bilješke s intervjua, generiraju nacrte korisničkih priča, označavaju dvosmislen jezik i otkrivaju duplikate u velikim skupovima zahtjeva. Poslovni analitičari i dalje provjeravaju svaki prijedlog u odnosu na stvarne potrebe dionika prije nego što uđe u odobrenu osnovnu liniju.

Copilot i GPT izrađuju nacrte korisničkih priča, kriterije prihvaćanja i shall-izjave iz kratkih upita. Poslovni analitičar uređuje svaki izlaz radi testiranja i potvrđuje usklađenost s poslovnim ciljevima prije formalnog pregleda.

Poslovni zahtjev navodi zašto projekt postoji, kao što je rast prihoda ili usklađenost. Funkcionalni zahtjev navodi što sustav mora učiniti kako bi ostvario taj rezultat, kao što je validacija plaćanja ili generiranje izvješća.

Koristite jasan subjekt, riječ "shall" i jednu provjerljivu radnju po izjavi. Izbjegavajte dvosmislene riječi poput "fast" i obuhvatite jedno ponašanje kako bi se zahtjev mogao testirati jednom provjerom prolaza ili pada.

EARS, Jednostavan pristup sintaksi zahtjeva, nudi pet predložaka: sveprisutni, vođeni događajima, vođeni stanjem, opcionalna značajka i neželjeno ponašanje. Svaki nameće strukturu koju je moguće testirati, kao što je KADA SE AKTIVIRA, sustav će ODGOVORITI.

Specifikacija softverskih zahtjeva glavni je dokument koji opisuje što sustav mora raditi. Funkcionalni zahtjevi čine najveći dio, uz sučelja, nefunkcionalne zahtjeve, slučajeve upotrebe i ograničenja.

Funkcionalni zahtjevi pokreću testne slučajeve u testiranju sustava, integraciji, end-to-end, API-ju i testiranju prihvatljivosti korisnika. Svaki zahtjev se preslikava na barem jedan testni slučaj, a Zahtjevi Traceability Matrix potvrđuje pokrivenost prije objavljivanja.

Agilni timovi izražavaju funkcionalne zahtjeve kao korisničke priče koristeći format Kao uloga, želim sposobnost, dakle tu vrijednost. Kriteriji prihvaćanja pridruženi priči pretvaraju zahtjev u provjerljivu definiciju dovršenog.

Sažmite ovu objavu uz: