what is requirement analysis
Aquest tutorial explica què és l'anàlisi de requisits, els passos d'anàlisi de requisits, els exemples i els objectius de reunió de requisits a SDLC:
El desenvolupament de programari és una tasca enorme que crea un producte de programari que funciona.
El producte de programari es crea segons els requisits del client. Majoritàriament, aquest producte de programari compleix el que esperava el client final / usuari, mentre que de vegades aquest producte no compleix completament el que el client / usuari final havia esperat.
Què aprendreu:
- Què és l'anàlisi de requisits?
- Conclusió
Què és l'anàlisi de requisits?
Comprenem l’anàlisi de requisits amb l’ajut d’un exemple.
Expectatives del client / usuari final:
El client / usuari final rep:
Com podeu analitzar a partir de les imatges anteriors, hi ha un desajust entre el producte final i les expectatives del client. Això es podria deure a infinitat de raons, a saber. implementació incorrecta dels requisits dels clients, disseny defectuós, una comprensió incorrecta dels requeriments dels clients per part dels programadors i l’equip de qualitat, etc.
Tanmateix, com podeu veure, ja sigui qualsevol motiu per a un lliurament incorrecte del producte, el motiu principal passa pel requisit. Per tant, si s’hagués comprès, capturat, implementat i provat correctament els requisits, hauria ajudat a mitigar l’enviament erroni i incomplet del producte al client / usuari final.
Un bon lliurament del producte requereix una recollida de requisits correcta, un examen eficient dels requisits que es recopilen i, finalment, una documentació clara dels requisits, com a condició prèvia. Tot aquest procés també es coneix com Anàlisi de requisits en el cicle de vida del desenvolupament de programari (SDLC)
Etapes / passos d’anàlisi de requisits
Com podeu veure, l'Anàlisi de requisits és la primera activitat a SDLC seguida d'especificacions funcionals, etc. L'anàlisi de requisits és un pas vital a SDLC, ja que ressona amb proves d'acceptació que són fonamentals per a l'acceptació del producte per part dels clients.
En aquest tutorial, explicarem com es fa l’anàlisi de requisits en SDLC. També veurem els diversos passos implicats, els resultats, els reptes i les mesures correctores en l’anàlisi de requisits.
L'anàlisi de requisits comença per:
- Reunió de requisits que també s’anomena elicitació.
- Això és seguit per analitzant els requisits recollits per comprendre la correcció i la viabilitat de convertir aquests requisits en un possible producte.
- I finalment, documentar els requisits recollits.
# 1) Reunió de requisits
Per assegurar-se que tots els passos esmentats anteriorment s’executen adequadament, cal recollir els requisits clars, concisos i correctes del client. El client hauria de ser capaç de definir els seus requisits correctament i l’analista empresarial hauria de ser capaç de recollir-los de la mateixa manera que pretén transmetre el client.
Moltes vegades no és possible que la recopilació de requisits la facin els analistes de negocis del client de manera eficient. Això pot ser degut a la dependència de moltes persones relacionades amb el producte final esperat, les eines, l'entorn, etc. Per tant, sempre és una bona idea involucrar a tots els grups d'interès que poguessin influir o que el producte final pogués influir.
El possible grup d'interessats podria ser enginyers de qualitat de programari (control de qualitat i control de qualitat), qualsevol proveïdor extern que pogués proporcionar assistència en el projecte, l'usuari final al qual està destinat el producte, programadors de programari, un altre equip de l'organització que pugui proporcionar un mòdul o una plataforma de programari, biblioteques de programari, etc. per al desenvolupament de productes.
Exemple: En una organització, desenvolupen un producte ADAS (sistema de càmera de visió envoltant per a un OEM de prestigi) que necessita Pila Autosar i Carregador d'arrencada binaris que es reben d’un altre proveïdor.
La implicació de diversos grups d'interès en l'etapa de recollida de requisits ajuda a entendre diverses dependències entre si i es pot evitar qualsevol possible conflicte futur.
De vegades, és una bona idea crear un model prototip del producte previst previst i mostrar-lo al client. Aquesta és una manera excel·lent de transmetre als clients quin producte esperen i com pot quedar més tard. Això ajuda el client a visualitzar el producte que espera i li ajuda a presentar requisits clars.
Aquesta creació de prototips depèn de dos tipus de producte:
- A l’organització hi ha un producte similar al que pretenien els clients.
- Nou producte a desenvolupar.
(i) En el primer cas, és més fàcil mostrar al client com seria el producte final i com es desenvoluparia. A ADAS per a automoció, és possible mostrar als clients un altre producte que ja es troba al mercat i que s’ha desenvolupat dins de l’organització.
Per exemple, Un sistema de càmera de visió envoltant desenvolupat per a un OEM (GM, Volkswagen, BMW, etc.) i que es pot presentar a un altre OEM.
Tingueu en compte , no és aconsellable mostrar el producte / prototips al client que s'està desenvolupant, ja que pot infringir l'acord de no divulgació signat amb un altre client per al qual es desenvolupa aquest producte. També pot resultar en un conflicte legal innecessari.
Un altre exemple podria ser el del sistema d'informació i entreteniment, desenvolupat per l'organització, i que ja està al mercat. Els analistes de negocis i altres parts interessades dins d’una organització poden planificar una demostració de tallers per al client, mostrant sistemes d’entreteniment amb HMI tangible, ports de connectors de dispositius, sandbox, etc.
Això ajudarà el client a entendre com quedaria el producte final i proporcionarà els seus requisits de manera molt més clara.
(ii) El segon cas es pot aconseguir creant un model de treball bàsic mitjançant la codificació i el muntatge senzills (la majoria de les funcions aquí estan codificades en programes de programari), o bé creant un diagrama de flux o diagrama que pugui convèncer al client com quedaria el producte.
En qualsevol cas, seria un respir per al procés de recollida de requisits, ja que el client ara sap el que vol.
L’analista de negocis ara pot organitzar reunions formals d’elucitació de requisits, on es poden convidar tots els grups d’interès i, per tant, pot anotar els diversos requisits proporcionats pel client (en alguns casos, si els grups d’interès són més nombrosos, es podria designar un escrivà separat per notar el client requisits o històries dels usuaris perquè l’analista de negocis es pugui concentrar a moderar la reunió).
Els requisits recollits poden ser en forma de històries dels usuaris (en desenvolupament àgil), casos d'ús, documents de llenguatge natural dels clients, diagrames, diagrames de flux, etc. Les històries dels usuaris s'estan popularitzant en el cicle de vida actual del desenvolupament de programari. Les històries dels usuaris són bàsicament un conjunt d’informacions dels clients en el seu llenguatge natural.
Exemple de reunió de requisits: Al sistema de càmeres de visió surround ADAS, una possible història de l'usuari podria ser: 'Com a usuari, hauria de poder veure què hi ha a la vista posterior del meu cotxe'.
N’hi podrien haver molts 'Per què,' preguntes sobre cada història de l'usuari, que ajudaran el client a proporcionar informació més detallada sobre el requisit.
A la història de l'usuari anterior, si un client diu 'Com a usuari, hauria de poder veure què hi ha a la retrovisió del meu cotxe', fent una pregunta 'Per què 'Podria donar' Com a usuari, hauria de poder veure què hi ha a la vista posterior del meu cotxe, perquè pugui aparcar el cotxe amb seguretat '.
Fent la pregunta 'Per què' també ajuda a crear requisits objectius i atòmics a partir de declaracions de llenguatge natural generoses donades pel client. Això es pot implementar fàcilment més endavant al codi.
en general, la majoria dels errors (defectes) es troben en quins dos períodes de prova?
Una altra forma de reunir el requisit és la forma de casos d’ús . Un cas d’ús és un enfocament pas a pas per aconseguir un resultat determinat. Això no indica com funcionarà el programari en l'entrada dels usuaris, sinó que diu què s'espera de les entrades dels usuaris.
Exemple:
# 2) Analitzar els requisits reunits
Recopilació de requisits posteriors, anàlisi de requisits inicials En aquesta etapa, diverses parts interessades seuen i fan una sessió de pluja d’idees. Analitzen els requisits recollits i busquen la viabilitat per implementar-los. Discuteixen entre ells i es soluciona qualsevol ambigüitat.
Aquest pas és important en el procés d’anàlisi de requisits a causa dels motius principals següents:
(i) El client pot proporcionar alguns requisits que podrien ser impossibles d’implementar a causa de diverses dependències.
Exemple: Clientspot demanar que envolti el sistema de càmeres amb una funció de càmera de retrovisió que us ajudi aparcament el cotxe. El client també pot demanar el Tràiler funció d’enganxament que també utilitza la càmera posterior per treballar.
Si el client estableix un requisit per a la càmera de retrovisió aparcament l 'assistència hauria de funcionar en tot moment sense excepció, aleshores Tràiler la funció mai funcionaria i viceversa.
(ii) Un analista de negocis podria haver entès el requisit del client diferent de com a programador hauria interpretat.
Atès que els programadors pensen que són experts tècnics, sempre és possible que els requisits dels clients es converteixin incorrectament en especificacions funcionals que posteriorment es faran incorrectament en documents d’arquitectura i disseny i, posteriorment, en codi. L'impacte és exponencial i, per tant, s'ha de comprovar.
Una possible mesura correctora podria ser seguir un mètode àgil de desenvolupament de programari, seguir casos d’ús que proporciona el client, etc.
# 3) Documentació dels requisits analitzats
Un cop feta l'anàlisi dels requisits, s'inicia la documentació dels requisits. De l'anàlisi dels requisits surten diversos tipus de requisits.
Alguns d'aquests són:
(i) Especificació del requisit del client.
(ii) Requisit d’arquitectura de programari.
java com eliminar un element d'una matriu
Exemple:
(Iii) Requisit de disseny de programari.
Exemple:
(iv) Especificació de requisits funcionals (derivada directament de les especificacions del client).
Exemple: 'Quan l'usuari toca la icona Bluetooth a la HMI Infotainment, s'hauria de mostrar la pantalla Bluetooth'
(v) Especificació de requisits no funcionals (a saber, rendiment, tensió, càrrega, etc.).
Exemple: 'Hauria de ser possible vincular 15 dispositius Bluetooth amb un sistema d'infodivertiment sense degradar el rendiment del sistema'.
(nosaltres) Requisits de la interfície d'usuari.
Exemple: 'A la pantalla Tuner FM, s'hauria de proporcionar un botó per seleccionar diferents emissores'
Els requisits anteriors es registren i documenten a les eines de gestió de requisits, com ara IBM DOORS, HP QC. De vegades, les organitzacions tenen les seves eines de gestió de requisits a mida per reduir els costos.
Vegem ara el procés de conversió Requisits empresarials a Requisits de programari (funcionals i no funcionals).
Conversió de requisits empresarials a requisits de programari
Els requisits empresarials, com es va comentar anteriorment, són requisits d'alt nivell que parlen del que vol l'usuari final d'una acció definida al sistema de programari. No és possible desenvolupar tot el sistema de programari en funció d’aquests requisits, ja que no s’esmenta una descripció detallada de com s’implementarà el sistema o component de programari.
Per tant, els requisits empresarials s’han de desglossar en requisits de programari més detallats, que es detallaran fins als requisits funcionals i no funcionals.
Per fer-ho, es podrien seguir els passos següents:
- Desglosseu els requisits empresarials d’alt nivell per obtenir històries detallades dels usuaris.
- Derivar un diagrama de flux per definir el flux d'activitats.
- Proporcionar la condició que justifica les històries d'usuaris derivades.
- Diagrames de filferro per explicar el flux de treball dels objectes.
- Definició de requisits no funcionals fora dels requisits empresarials.
Comencem per prendre un exemple de sistema d’entreteniment automotriu.
El requisit empresarial diu: 'L'usuari final hauria de poder accedir al quadre del widget de navegació des de la HMI del sistema d'Infotainment i hauria de poder configurar l'adreça de destinació'.
Per tant, els passos indicats anteriorment es poden implementar com:
# 1) Distribuïu els requisits empresarials d'alt nivell en històries detallades dels usuaris.
Convertim aquest requisit empresarial en una història d'usuari d'alt nivell '. Com a usuari, hauria de poder accedir al quadre del widget Navegació per poder introduir l'adreça de destinació ”. Aquesta història de l'usuari explica el que necessita l'usuari final. Intentarem definir com implementar aquest requisit.
Comencem per fer possibles preguntes a aquesta història de l'usuari.
- Qui són els usuaris?
- Com puc accedir a la navegació, a bord (des de la targeta SD) o des del telèfon intel·ligent?
- Quin tipus d'entrades de destinació puc introduir?
- M’hauria de permetre entrar a la destinació fins i tot quan el cotxe estigui a l’aparcament?
Es tracta d’històries d’usuaris de nivell més detallat derivades d’històries d’usuaris d’alt nivell i que ens ajudarien a conèixer millor el nostre requisit empresarial.
En aquest moment, podem ocupar una de les subhistòries d’usuaris i començar a qüestionar-nos. Prenem (núm. 3):
- Puc introduir entrades de destinació com coordenades geogràfiques, adreça postal, mitjançant el reconeixement de veu, etc.?
- Necessito GPS per introduir coordenades geogràfiques?
- Puc introduir l'adreça de destinació actual cercant a l'historial d'adreces?
# 2) Derivar un diagrama de flux per definir el flux d'activitats.
Ara podem veure que el requisit empresarial es divideix en casos d’ús molt detallats que es poden marcar al diagrama de flux de la manera següent:
# 3) Proporcionar condicions que justifiquin les històries dels usuaris derivats.
Podem veure que apareix informació més detallada a causa de la descomposició del requisit empresarial d’alt nivell en històries detallades d’usuaris de baix nivell i del diagrama de flux. A partir d’aquest diagrama de flux, podem obtenir els detalls tècnics necessaris per a la implementació.
- El temps de càrrega de la pantalla per mostrar l'entrada de destinació ha de ser d'1 segon.
- El teclat d’entrada de destinació ha de tenir caràcters alfanumèrics i símbols especials.
- El botó d'activació / desactivació del GPS hauria d'estar present a la pantalla d'entrada de la destinació de navegació.
La informació anterior satisfà les històries dels usuaris i fa possible que el requisit es pugui provar de manera discreta i mesurable evitant qualsevol confusió amb el requisit mentre s’implementa com a funcions.
# 4) Diagrames de filferro per explicar el flux de treball d'objectes.
A partir del cas d'ús anterior, obtindrem un diagrama wireframe que farà que la interfície d'usuari sigui més clara.
# 5) Definició de requisits no funcionals fora dels requisits empresarials.
És imprescindible que els requisits detallats de programari es derivin de requisits empresarials d’alt nivell, però moltes vegades només s’identifiquen requisits funcionals que indiquen com es comportarà un sistema davant d’una entrada o acció d’un usuari concret.
No obstant això, els requisits funcionals no aclareixen el rendiment dels sistemes i altres paràmetres qualitatius com la disponibilitat, la fiabilitat, etc.
Exemples:
a) Prendrem l'exemple del sistema d'informació i entreteniment automobilístic anterior.
Si el conductor (usuari final) del cotxe reprodueix música des de l’USB i la guia de navegació està en curs, també rebrà una trucada entrant per Bluetooth en mode Mans lliures, aleshores la càrrega de la CPU i el consum de RAM augmentaran fins a un nivell màxim, ja que hi ha diversos processos. funcionant en segon pla.
En aquest moment, si el controlador toca una interfície de pantalla tàctil del sistema d’entreteniment per rebutjar les trucades entrants mitjançant SMS de resposta automàtica (de la mateixa manera que ho fem als nostres telèfons mòbils), el sistema hauria de poder realitzar aquesta tasca i no hauria de penjar-se ni bloquejar-se. Aquest és el rendiment del sistema quan la càrrega és elevada i comprovem la disponibilitat i la fiabilitat.
b) Un altre cas és l’escenari de l’estrès.
Posem un exemple: el sistema d’entreteniment i entreteniment rep SMS de forma inversa (potser 20 SMS en 10 segons) mitjançant un telèfon Bluetooth connectat. El sistema d’entreteniment hauria de ser capaç de gestionar tots els SMS entrants i en cap moment hauria de perdre cap de les notificacions entrants a l’HMI d’entreteniment.
Els exemples anteriors són casos de requisits no funcionals que no es poden provar només mitjançant requisits funcionals. Tot i que de vegades, als clients els falta proporcionar aquests requisits no funcionals. És responsabilitat de l’organització proporcionar-los aquesta informació quan es lliura un producte al client.
Comprensió de casos de requisits no funcionals
La taula següent explica els requisits no funcionals:
SL núm | Característica / cas d'ús | Càrrega de la CPU (màx.) | Ús de RAM (màxim de 512 MB) | Paràmetres de rendiment |
---|---|---|---|---|
1 | Núm. Màx. de dispositius Bluetooth que es poden emparellar amb el sistema Infotainment | 75% | 300 MB | 10 dispositius Bluetooth |
2 | És hora de descarregar 2000 contactes de telèfon al sistema Infotainment després de connectar i connectar Bluetooth | 90% | 315 MB | 120 segons |
3 | Temps per escanejar totes les estacions de FM disponibles a Tuner en un sistema d’entreteniment i entreteniment | 50% | 200 MB | 30 segons |
Els requisits no funcionals, a diferència dels requisits funcionals, requereixen el cicle de vida complet d'un projecte per implementar-se, ja que s'implementen de manera incremental en els respectius Sprints àgils o en diferents iteracions.
Per tant, així és com derivem els requisits de programari dels requisits empresarials.
Diferència entre els requisits empresarials i els requisits de programari
Hem vist anteriorment com derivar els requisits de programari de requisits empresarials d’alt nivell. Els requisits de programari permeten al programador i a l'enginyer de proves desenvolupar el sistema i provar-lo de manera eficient. Per tant, ara sabem que els requisits empresarials són requisits de llenguatge natural dels clients d’alt nivell, mentre que els requisits de programari són requisits detallats de baix nivell que ajuden a la implementació del sistema de programari.
Vegem la diferència detallada entre els dos tipus de requisits.
Requisits empresarials | Requisits de programari |
---|---|
Són requisits d'alt nivell per part d'un client que diu 'què' hauria de fer el sistema. Aquests requisits no indiquen 'com' haurien de funcionar els requisits. | Es concentren en l'aspecte 'com' dels requisits del client. Aquests requisits expliquen com funcionaria / implementaria el sistema. |
Aquests requisits tracten l'objectiu empresarial d'una organització. Exemple: L'usuari hauria de poder configurar la destinació de navegació. | Aquests requisits expliquen el coneixement tècnic dels requisits. Exemple: Quan l'usuari fa clic a la icona de destinació de navegació, la base de dades hauria de carregar els detalls de destinació perquè l'usuari hi pugui introduir. |
Els requisits empresarials se centren en els beneficis de l’organització. Exemple: S'ha de proporcionar a l'usuari informació per actualitzar la funció de navegació del distribuïdor del sistema d'Infodivertiment si la navegació no hi és al sistema i l'usuari toca la icona de navegació. | Els requisits de programari tracten els detalls sobre la implementació dels requisits empresarials del sistema. Exemple: Quan l’usuari faci clic a la icona de navegació del sistema d’entreteniment, s’hauria d’iniciar una trucada API per mostrar un missatge a l’usuari per a l’actualització del sistema. |
Els requisits empresarials s’escriuen normalment en llenguatge natural o en històries d’usuaris d’alt nivell. | Els requisits de programari són funcionals i no funcionals. Exemple: dels requisits no funcionals són el rendiment, l'estrès, la portabilitat, la usabilitat, l'optimització de la memòria, l'aparença, etc. |
Conclusió
L’anàlisi de requisits és l’eix vertebrador de qualsevol model SDLC.
Un problema perdut durant l’anàlisi de requisits i detectat a les proves de la unitat podria costar desenes de milers de dòlars per a una organització i aquest cost podria comportar milions de dòlars si provenia del mercat com a devolució de trucada (el 2017, el fabricant de coixins d’aire multa de 1 mil milions de dòlars a causa de l’explosió dels coixins de seguretat).
L’organització acabaria realitzant tasques de control de danys com ara l’anàlisi de la causa arrel, preparant els documents per què, l’anàlisi de l’arbre de falles, el document 8D, etc.
En els pitjors casos, l’organització seria arrossegada a demandes judicials presentades pel client si la característica afectada està relacionada amb la seguretat / seguretat, com ara accés de seguretat, coixins de seguretat, ABS (sistema de frenada antiblocatge), etc.
Lectura recomanada
- Fases, metodologies, processos i models de SDLC (cicle de vida de desenvolupament de programari)
- Característiques dels requisits funcionals i dels requisits no funcionals
- Com provar l'especificació de requisits de programari (SRS)?
- 5 Errors mortals en la gestió de requisits i com superar-los
- Com provar una aplicació sense requisits?
- Mesures per SSDLC (cicle de vida segur de desenvolupament de programari)
- Model en espiral: què és el model en espiral SDLC?
- Què és el model de cascada SDLC?