features functional requirements
Aquest tutorial explica els tipus, funcions, comparació de requisits funcionals i no funcionals i requisits empresarials versus funcionals amb exemples:
Els requisits funcionals defineixen què ha de fer un sistema de programari. Defineix una funció d'un sistema de programari o del seu mòdul. La funcionalitat es mesura com un conjunt d’entrades al sistema que es prova a la sortida del sistema.
La implementació de requisits funcionals en un sistema està prevista a la fase de disseny del sistema, mentre que, en cas de requisits no funcionals, es planifica al document d’Arquitectura de sistemes. El requisit funcional permet generar requisits no funcionals.
Què aprendreu:
Requisits funcionals i requisits no funcionals
Requisits funcionals
Comprenem què són els requisits funcionals amb l’ajut d’exemples-
Exemple: En un projecte ADAS d'automoció, un requisit funcional del sistema de visió envoltant podria ser 'La càmera posterior ha de detectar una amenaça o un objecte'. Els requisits no funcionals aquí podrien ser 'la rapidesa amb què s'ha de mostrar l'alerta a un usuari quan els sensors de la càmera detecten una amenaça'.
Agafeu-ne un altre exemple del projecte de sistemes d’entreteniment i entreteniment. L'usuari habilita el Bluetooth aquí des de la HMI i comprova si el Bluetooth està activat o no. Nota , altres serveis Bluetooth s'activen (de gris a negreta) quan l'usuari activa Bluetooth.
c ++ com fer un makefile
Per tant, els requisits funcionals parlen d’un resultat concret del sistema quan l’usuari els realitza una tasca. D'altra banda, el requisit no funcional proporciona el comportament general del sistema o del seu component i no la funció.
Tipus de requisits funcionals
Els requisits funcionals poden incloure els components següents que es poden mesurar com a part de les proves funcionals:
# 1) Interoperabilitat: El requisit descriu si un sistema de programari és interoperable entre diferents sistemes.
Exemple: Pel que fa als requisits funcionals de Bluetooth al sistema d’entreteniment automàtic, quan l’usuari emparella un telèfon intel·ligent basat en Android habilitat per Bluetooth a un sistema d’entreteniment basat en QNX, hauríem de poder transferir l’agenda telefònica al sistema d’entreteniment o transmetre música des del nostre dispositiu telefònic al sistema d’entreteniment.
Per tant, la interoperabilitat comprova si és possible o no la comunicació entre els dos dispositius diferents.
Un altre exemple prové dels sistemes de serveis de correu electrònic com Gmail. Gmail permet importar correus electrònics d’un altre servidor d’intercanvi de correu com Yahoo.com o Rediffmail.com. Això és possible a causa de la interoperabilitat entre servidors de correu electrònic.
# 2) Seguretat: El funcional requisit descriu l'aspecte de seguretat dels requisits de programari.
Exemple: Serveis basats en ciberseguretat al sistema basat en càmeres de visió envoltant ADAS que utilitza la xarxa d'àrea de controlador (CAN) que protegeix el sistema de l'amenaça de seguretat.
Un altre exemple prové del lloc de xarxes socials Facebook . Les dades d’un usuari han de ser segures i no s’han de filtrar a cap usuari extern. Esperem que aquest exemple de Facebook doni una visió més àmplia de la seguretat als lectors a causa de la incidència recent en la violació de dades a Facebook i de les conseqüències de Facebook.
# 3) Precisió: La precisió defineix que les dades introduïdes al sistema són calculades i utilitzades correctament pel sistema i que la sortida és correcta.
Exemple: A la xarxa d'àrea de controladors, quan un valor de senyal CAN es transmet per un bus CAN mitjançant una ECU (és a dir, unitat ABS, unitat HVAC, unitat de grup d'instruments, etc.), una altra ECU podrà identificar si les dades enviades són correctes o no. mitjançant comprovació CRC.
Un altre exemple pot ser d'una solució de banca en línia. Quan l’usuari rep un fons, l’import rebut s’ha d’abonar exactament al compte i no s’accepta cap variació en la precisió.
# 4) Compliment: Els requisits funcionals de conformitat validen que el sistema desenvolupat compleix les normes industrials.
Exemple: Si les funcionalitats dels perfils Bluetooth (és a dir, la transmissió d’àudio mitjançant A2DP, la trucada telefònica mitjançant HFP) compleixen les versions del perfil de llançament Bluetooth SIG.
Un altre exemple pot ser el joc d'Apple Car en el sistema d'infodivertiment del cotxe. L’aplicació de l’entreteniment d’informació rep un certificat de poma si tots els requisits previs esmentats al lloc web d’Apple els compleixen dispositius Car Play de tercers (infotainment en aquest cas).
Un altre exemple pot ser d'una aplicació basada en web per al sistema de venda de bitllets ferroviaris. El lloc web hauria de seguir les directrius de ciberseguretat i complir amb la World Wide Web en termes d’accessibilitat.
Exemple de formulari de requisits:
Ja hem vist quin és el requisit funcional amb alguns exemples. Vegem ara com seria un requisit funcional quan estigués integrat en eines de gestió de requisits com IBM DOORS. Hi ha diversos atributs que cal tenir en compte quan es documenta un requisit funcional a l'eina de gestió de requisits.
A continuació es detallen alguns atributs que cal tenir en compte:
- Tipus d'objecte: Aquest atribut explica quina secció del document de requisits forma part d’aquest atribut. Podrien ser Encapçalament, explicació, requisit, etc. La majoria de les seccions 'Requisits' es consideren per a la implementació i la prova, mentre que les seccions d'encapçalament i explicació s'utilitzen com a descripcions de suport per obtenir requisits per a una millor comprensió.
- Persona responsable: Un autor que ha documentat el requisit a l'eina de gestió de requisits.
- Nom del projecte / sistema: El projecte per al qual és aplicable el requisit, per exemple, 'Sistemes d'informació i entreteniment per a XYZ OEM (fabricant d'equips originals), una empresa d'automoció o aplicació web per a una empresa limitada bancària ABC'.
- Número de versió del requisit: Aquest camp / atribut notifica el número de versió del requisit si el requisit ha sofert diverses modificacions a causa d’actualitzacions dels clients o canvis en el disseny del sistema.
- Identificació del requisit: Aquest atribut menciona l'identificador de requisit únic. L'identificador de requisit s'utilitza per fer un seguiment dels requisits de la base de dades fàcilment i també per mapear els requisits del codi de manera eficient. També es pot utilitzar per proporcionar una referència als requisits mentre es registren defectes a les eines de seguiment d'errors.
- Descripció del requisit: Aquest atribut és un dels atributs més importants que expliquen el requisit. En llegir aquest atribut, un enginyer seria capaç d’entendre el requisit.
- Estat del requisit: L’atribut d’estat de requisit indica l’estat d’un requisit a l’eina de gestió de requisits, és a dir, si s’accepta, s’espera, es rebutja o se suprimeix el projecte.
- Comentaris: Aquest atribut proporciona a la persona responsable o al gestor de requisits una opció per documentar qualsevol comentari sobre el requisit. Exemple: un possible comentari sobre un requisit funcional podria ser 'la dependència d'un paquet de programari de tercers per implementar el requisit'.
Una instantània de DOORS
Derivar els requisits funcionals dels requisits empresarials
Això ja està cobert com a part de la secció ' Derivar els requisits funcionals dels requisits empresarials ' sota la Anàlisi de requisits article.
Requisits empresarials contra requisits funcionals
Aquesta diferència es recull poc a la Anàlisi de requisits article. Però ho intentarem ressalteu alguns punts més aquí a la taula següent:
| Sl. No. | Requisits empresarials | Requisits funcionals |
|---|---|---|
| 7 | Per exemple, al sistema bancari en línia, un requisit empresarial podria ser 'Com a usuari, hauria de poder obtenir un extracte de transacció en efectiu'. | El requisit funcional d’aquest sistema bancari en línia podria ser: “Quan l’usuari proporciona l’interval de dates en la consulta de transaccions, Server utilitza aquesta entrada i la pàgina web proporciona les dades necessàries de transaccions en efectiu”. |
| 1 | Els requisits empresarials indiquen 'quin' aspecte del requisit del client. Exemple, Què hauria de ser visible per a l'usuari després que l'usuari hagi iniciat la sessió. | Els requisits funcionals indiquen l'aspecte de 'com' dels requisits empresarials. Exemple, Com ha de mostrar la pàgina web la pàgina d'inici de sessió de l'usuari quan l'usuari s'autentifica. |
| 2 | Els analistes de negoci identifiquen els requisits empresarials. | Els desenvolupadors / arquitectes de programari creen / deriven els requisits funcionals |
| 3 | Destaquen els beneficis de l'organització i estan relacionats amb els objectius empresarials. | El seu objectiu és el compliment dels requisits del client. |
| 4 | Els requisits empresarials són del client. | Els requisits funcionals es deriven dels requisits del programari, que al seu torn es deriven dels requisits empresarials. |
| 5 | Els enginyers de proves de programari no proven directament els requisits empresarials. Són provats principalment pel client. | Els enginyers de proves de programari comproven els requisits funcionals i, en general, no els proven els clients. |
| 6 | El requisit empresarial és un document de requisits d’alt nivell. | Un requisit funcional és un document detallat de requisits tècnics. |
Requisit no funcional
El requisit no funcional diu sobre 'què ha de ser un sistema' en lloc de 'què ha de fer un sistema' (requisit funcional). La majoria es deriven de requisits funcionals basats en les aportacions del client i d'altres parts interessades. Els detalls d’implementació de requisits no funcionals es documenten al document d’Arquitectura de sistemes.
Els requisits no funcionals expliquen els aspectes de qualitat del sistema a construir, és a dir. rendiment, portabilitat, usabilitat, etc. Els requisits no funcionals, a diferència dels requisits funcionals, s’implementen incrementalment en qualsevol sistema.
URPS (Usabilitat, fiabilitat, rendiment i compatibilitat) de FURPS Els atributs de qualitat (funcionalitat, usabilitat, fiabilitat, rendiment i compatibilitat) que s’utilitzen àmpliament a la indústria de TI per mesurar la qualitat d’un desenvolupador de programari estan coberts en requisits no funcionals. A més, també hi ha altres atributs de qualitat (detalls a la secció següent).
De vegades, la Viquipèdia denomina el requisit no funcional com a 'il·lusions', a causa de la presència de diversos atributs de qualitat com la portabilitat i l'estabilitat.
Tipus de requisits no funcionals
Els requisits no funcionals consisteixen en els subtipus següents (no exhaustius):
# 1) Rendiment:
Un tipus d'atribut de rendiment de requisits no funcionals mesura el rendiment del sistema. Exemple: Al sistema de visió envoltant ADAS, 'la visualització de la càmera posterior s'hauria de mostrar en un termini de 2 segons després d'iniciar l'encesa del cotxe'.
Un altre exemple de rendiment podria provenir d'un sistema de navegació de sistemes d'informació i entreteniment. 'Quan un usuari accedeix a la pantalla de navegació i entra a la destinació, la ruta s'ha de calcular en un termini de' X 'segons'. Un més exemple des de la pàgina d'inici de sessió de l'aplicació web. 'El temps que triga la pàgina de perfil d'usuari a carregar-se després d'iniciar la sessió.'
Recordeu que la mesura del rendiment del sistema és diferent de la mesura de càrrega. Durant les proves de càrrega, carreguem la CPU i la RAM del sistema i comprovem el rendiment del sistema. En el cas del rendiment, provem el rendiment del sistema en condicions normals de càrrega / tensió.
# 2) Usabilitat :
La usabilitat mesura la usabilitat del sistema de programari que s'està desenvolupant.
Per exemple , es desenvolupa una aplicació web per a mòbils que us proporciona informació sobre la disponibilitat de lampistes i electricistes a la vostra zona.
L'entrada d'aquesta aplicació és el codi postal i el radi (en quilòmetres) de la vostra ubicació actual. Però, per introduir aquestes dades, si l'usuari ha de navegar per diverses pantalles i l'opció d'introducció de dades es mostra en petits quadres de text que no són fàcilment visibles per a l'usuari, aquesta aplicació no és fàcil d'utilitzar i, per tant, la usabilitat de l'aplicació serà molt fluix.
# 3) Manteniment :
El manteniment d’un sistema de programari és la facilitat amb què es pot mantenir el sistema. Si el temps mitjà entre fallades (MTBF) és baix o el temps mitjà de reparació (MTTR) és elevat per al sistema que es desenvolupa, la mantenibilitat del sistema es considera baixa.
La mantenibilitat es mesura sovint a nivell de codi mitjançant complexitat ciclomàtica. La complexitat ciclomàtica diu que, com menys complex és el codi, més fàcil és mantenir el programari.
Exemple: Es desenvolupa un sistema de programari que té l’elevat nombre de codis morts (codis no utilitzats per altres funcions o mòduls), molt complexos a causa de l’ús excessiu de la condició if / else, bucles imbricats, etc. o si el sistema és enorme amb codis en execució en molts milions de línies de codis i sense comentaris adequats. Aquest sistema té una baixa capacitat de manteniment.
Un altre exemple podria ser de la pàgina web de compres en línia. Si hi ha molts enllaços externs al lloc web perquè l’usuari pugui tenir una visió general del producte (això per estalviar memòria), el manteniment d’aquest lloc web és baix. Això es deu al fet que, si es modifica l’enllaç d’una pàgina web externa, també s’ha d’actualitzar al lloc web de compres en línia i amb massa freqüència.
# 4) Fiabilitat :
La fiabilitat és un altre aspecte de la disponibilitat. Aquest atribut de qualitat posa l'accent en la disponibilitat d'un sistema en determinades condicions. Es mesura com a MTBF igual que el manteniment.
Exemple: Les funcions mútuament excloents, com la càmera de retrovisió i el remolc del sistema de càmera de visió envoltant ADAS, haurien de funcionar de manera fiable al sistema sense interferències entre elles. Quan un usuari crida la funció Trailer, la vista posterior no hauria d'interferir-se i viceversa, ja que totes dues funcions accedeixen a la càmera posterior del cotxe.
Un altre exemple del sistema de reclamació d’assegurança en línia. Quan un usuari comença a informar de reclamacions i després penja les factures de despeses rellevants, el sistema hauria de donar prou temps perquè es completi la càrrega i no hauria de cancel·lar el procés de càrrega ràpidament.
# 5) Portabilitat:
Portabilitat significa la capacitat d’un sistema de programari per treballar en un entorn diferent si el marc dependent subjacent es manté.
Exemple: El sistema o component de programari desenvolupat en un sistema d’entreteniment (per exemple, servei Bluetooth o servei multimèdia) per a un fabricant d’automòbils hauria de permetre l’ús en un altre sistema d’entreteniment amb poc o cap canvi de codi, tot i que els dos sistemes d’entreteniment són completament diferents .
Agafem-ne un altre exemple de WhatsApp. És possible instal·lar i utilitzar el servei de missatgeria a IOS, Android, Windows, tauletes, portàtils i telèfons.
# 6) Compatibilitat:
La capacitat de manteniment d’un sistema de programari és la capacitat d’un expert / tècnic d’instal·lar el sistema de programari en un entorn en temps real, supervisar el sistema mentre s’executa, identificar qualsevol problema tècnic del sistema i proporcionar una solució per resoldre el problema.
La capacitat de manteniment és possible si el sistema es desenvolupa per facilitar la seva capacitat de manteniment.
Exemple: Proporcionar a l’usuari una finestra emergent de recordatori periòdic per a una actualització de programari, proporcionar mecanisme de registre / rastreig per depurar problemes, recuperació automàtica d’un error mitjançant un mecanisme de retrocés (recuperar el sistema de programari a l’estat anterior de les condicions de treball).
Un altre exemple des de Rediffmail. Quan hi va haver una actualització de la versió del servei de correu basat en web, el sistema va permetre a l'usuari canviar a una versió més nova del sistema de correu mantenint intacta la versió anterior durant uns mesos. Això també millora l’experiència de l’usuari.
# 7) Adaptabilitat:
com imprimir una matriu en ordre invers
L’adaptabilitat d’un sistema es defineix com la capacitat d’un sistema de programari d’adaptar-se als canvis d’un entorn sense cap canvi en el seu comportament.
Exemple: El sistema de frenat antibloqueig al cotxe hauria de funcionar segons les normes en qualsevol condició meteorològica (fred o calor). Un altre exemple podria ser el d’un sistema operatiu Android. S'utilitza en diferents tipus de dispositius, a saber. Els telèfons intel·ligents, les tauletes i els sistemes d’entreteniment i són molt adaptables.
A més dels 7 requisits no funcionals enumerats anteriorment, tenim molts altres com:
Accessibilitat, còpia de seguretat, capacitat, conformitat, integritat de dades, retenció de dades, dependència, desplegament, documentació, durabilitat, eficiència, explotabilitat, extensibilitat, gestió d’errors, tolerància a fallades, interoperabilitat, modificabilitat, operabilitat, privadesa, llegibilitat, informes, resistència, reutilització, Robustesa, escalabilitat, estabilitat, testabilitat, rendiment, transparència, integrabilitat.
Cobrir tots aquests requisits no funcionals queda fora de l’abast d’aquest article. Tanmateix, podeu llegir més sobre aquests tipus de requisits no funcionals a Viquipèdia.
Derivació de requisits no funcionals a partir de requisits funcionals
Els requisits no funcionals es poden derivar de moltes maneres, però la millor manera provada i provada de la indústria és la dels requisits funcionals.
Prenguem l'exemple dels nostres sistemes d'infodivertiment que ja hem pres en alguns llocs d'aquest article. L'usuari pot realitzar moltes accions al sistema d'Infodivertiment, a saber. canvieu la cançó, canvieu la font de la cançó d'àudio USB a FM o Bluetooth, configureu la destinació de navegació, actualitzeu el programari d'informació i entreteniment mitjançant una actualització de programari, etc.
# 1) Reunió de requisits no funcionals:
Enumerarem les tasques realitzades per un usuari, que forma part dels requisits funcionals. Una vegada que s’indiquen les accions de l’usuari al diagrama de casos d’ús UML (cada oval), iniciarem preguntes rellevants (cada rectangle) sobre les accions de cada usuari. Les respostes a aquestes preguntes donaran els nostres requisits no funcionals.
# 2) Classificació de requisits no funcionals:
El següent pas és classificar els requisits no funcionals que hem identificat mitjançant preguntes. En aquesta etapa, podem comprovar la possible resposta i classificar les respostes a possibles categories no funcionals o diferents qualitats.
A la imatge següent podeu veure els possibles atributs de qualitat identificats a partir de les respostes.
Funcionals contra requisits no funcionals
Ja hem vist quins són els requisits funcionals i no funcionals i com es deriven. Vegem les principals diferències entre requisits funcionals i no funcionals.
| Sl. no | Requisits funcionals (FR) | Requisits no funcionals (NFR) |
|---|---|---|
| 7 | Els requisits funcionals constitueixen l’esquelet de la implementació del sistema de programari | Els requisits no funcionals completen el sistema SW ajudant els requisits funcionals a unir-se, com un múscul. |
| 1 | Diuen, què hauria de fer un sistema. | Diuen, què hauria de ser un sistema. |
| 2 | Es detallen al document de disseny del sistema. | Es detallen al document d'arquitectura del sistema. |
| 3 | Parlen del comportament d’una funció o característica. | Parlen del comportament laboral de tot un sistema o d’un component del sistema i no d’una funció concreta. |
| 4 | L'usuari passarà l'entrada i comprovarà si la sortida es mostra correctament. | Quan l'usuari passa una entrada, els NFR poden respondre a les preguntes següents: i) Quant de temps triga a mostrar la sortida? ii) La producció és coherent amb el temps? iii) Hi ha altres maneres de passar el paràmetre d'entrada? iv) Què tan fàcil és passar el paràmetre d'entrada? |
| 5 | En una aplicació web, l'usuari hauria de poder iniciar sessió mitjançant l'autenticació FR | En una aplicació web, quant de temps es necessita per iniciar sessió al lloc web, tenir aspecte de la pàgina d’inici de sessió, la facilitat d’ús d’una pàgina web, etc. formen part de NFR |
| 6 | Els requisits funcionals es deriven primer dels requisits de programari. | Els requisits no funcionals es deriven de requisits funcionals. |
| 8 | Els requisits funcionals poden existir sense un requisit no funcional. | Els requisits no funcionals no poden existir sense un requisit funcional. |
| 9 | Un requisit funcional proporciona informació concreta sobre una característica, Exemple , La foto de perfil a Facebook hauria de ser visible en iniciar la sessió. | Un requisit funcional pot tenir molts atributs de requisits no funcionals. Exemple, temps per iniciar la sessió (rendiment), aspecte de la pàgina de perfil (usabilitat), nombre d'usuaris que poden iniciar sessió alhora (capacitat, rendiment) |
| 10 | És possible derivar requisits funcionals dels requisits SW per a gairebé tots els requisits empresarials | Sovint no es documenten els NFR, ja que no es fan preguntes rellevants als FR. |
| 11 | La implementació d’un requisit funcional es fa normalment en una compilació de programari. | Els NFR s’implementen durant tot el cicle de vida del projecte fins que s’aconsegueix el comportament desitjat. |
| 12 | Aquests són majoritàriament visibles pel client. | La majoria no són visibles pel client, però es poden experimentar a llarg termini. Exemple, La usabilitat, el rendiment, etc. només es poden experimentar a llarg termini, però no poden ser visibles en absolut. |
Conclusió
Els requisits constitueixen el bloc bàsic per desenvolupar qualsevol sistema de programari. És possible construir un sistema amb requisits funcionals, però les seves capacitats no es poden determinar ni mesurar. Dit això, és molt important tenir requisits funcionals de bona qualitat derivats d'un requisit empresarial per tenir un sistema de programari de treball d'alta qualitat.
Per tant, els requisits funcionals donen la direcció d’implementació d’un sistema de programari, però els requisits no funcionals determinen la qualitat de la implementació que experimentaran els usuaris finals.
Lectura recomanada
- Com provar l'especificació de requisits de programari (SRS)?
- Proves funcionals contra proves no funcionals
- Com provar una aplicació sense requisits?
- Què és l'anàlisi i la reunió de requisits a SDLC?
- 5 Errors mortals en la gestió de requisits i com superar-los
- Característiques dels requisits funcionals i dels requisits no funcionals
- Com es crea una matriu de traçabilitat dels requisits (RTM): exemple i plantilla de mostra
- Top 20+ millors eines de gestió de requisits (llista completa)