L'etapa de producció de requisits del procés de desenvolupament de programari és Especificacions de requisits de programari (SRS) (també anomenat a document de requisits ). Aquest informe estableix les bases per a les activitats d'enginyeria de programari i s'està construint quan s'obtenen i s'analitzen els requisits sencers. SRS és un informe formal, que actua com a representació del programari que permet als clients revisar si aquest (SRS) s'ajusta als seus requisits. A més, inclou els requisits d'usuari per a un sistema, així com les especificacions detallades dels requisits del sistema.
L'SRS és una especificació per a un producte de programari, programa o conjunt d'aplicacions específics que realitzen funcions particulars en un entorn específic. Serveix per a diversos objectius depenent de qui l'escrigui. En primer lloc, l'SRS podria ser escrit pel client d'un sistema. En segon lloc, el SRS podria ser escrit per un desenvolupador del sistema. Els dos mètodes creen situacions completament diferents i estableixen propòsits diferents per al document. El primer cas, SRS, s'utilitza per definir les necessitats i expectatives dels usuaris. El segon cas, SRS, està escrit amb diversos propòsits i serveix com a document de contracte entre el client i el desenvolupador.
Característiques d'un bon SRS
A continuació es mostren les característiques d'un bon document SRS:
1. Correcció: La revisió de l'usuari s'utilitza per proporcionar la precisió dels requisits establerts a l'SRS. Es diu que SRS és perfecte si cobreix totes les necessitats que realment s'esperen del sistema.
2. Exhaustivitat: El SRS està complet si, i només si, inclou els elements següents:
(1). Tots els requisits essencials, ja siguin relacionats amb la funcionalitat, el rendiment, el disseny, les restriccions, els atributs o les interfícies externes.
tipus de bucle for
(2). Definició de les seves respostes del programari a totes les classes realitzables de dades d'entrada en totes les categories de situacions disponibles.
Nota: és essencial especificar les respostes tant als valors vàlids com als no vàlids.
(3). Etiquetes completes i referències a totes les figures, taules i diagrames de l'SRS i definicions de tots els termes i unitats de mesura.
3. Coherència: L'SRS és coherent si, i només si, no es descriu cap subconjunt de requisits individuals en el seu conflicte. Hi ha tres tipus de possibles conflictes a l'SRS:
(1). Les característiques especificades dels objectes del món real poden entrar en conflicte. Per exemple,
(a) El format d'un informe de sortida es pot descriure en un requisit com a tabular, però en un altre com a textual.
(b) Una condició pot indicar que tots els llums han de ser verds, mentre que una altra indica que tots els llums han de ser blaus.
(2). Pot haver-hi un conflicte raonable o temporal entre les dues accions especificades. Per exemple,
(a) Un requisit pot determinar que el programa afegeixi dues entrades, i un altre pot determinar que el programa les multiplicarà.
(b) Una condició pot indicar que 'A' ha de seguir sempre 'B', mentre que una altra requereix que 'A i B' es produeixin conjuntament.
(3). Dos o més requisits poden definir el mateix objecte del món real però utilitzar termes diferents per a aquest objecte. Per exemple, la sol·licitud d'un programa per a l'entrada de l'usuari es pot anomenar 'indicació' en un requisit i 'indicació' en un altre. L'ús de terminologia i descripcions estàndard afavoreix la coherència.
4. Inequívocitat: SRS és inequívoc quan cada requisit fix només té una interpretació. Això suggereix que cada element s'interpreta de manera única. En cas que hi hagi un mètode utilitzat amb múltiples definicions, l'informe de requisits hauria de determinar les implicacions en l'SRS perquè sigui clar i senzill d'entendre.
python genera uuid
5. Classificació per importància i estabilitat: L'SRS es classifica per importància i estabilitat si cada requisit té un identificador per indicar la importància o l'estabilitat d'aquest requisit en particular.
Normalment, tots els requisits no són igualment importants. Alguns requisits previs poden ser essencials, especialment per a aplicacions vitals, mentre que altres poden ser desitjables. Cada element s'ha d'identificar per fer aquestes diferències clares i explícites. Una altra manera de classificar els requisits és distingir les classes d'elements com a essencials, condicionals i opcionals.
6. Modificabilitat: SRS s'hauria de fer tan modificable com sigui possible i hauria de ser capaç d'obtenir canvis ràpidament al sistema en certa mesura. Les modificacions han d'estar perfectament indexades i creuades.
7. Verificabilitat: SRS és correcte quan els requisits especificats es poden verificar amb un sistema rendible per comprovar si el programari final compleix aquests requisits. Els requisits es verifiquen amb l'ajuda de revisions.
8. Traçabilitat: L'SRS és traçable si l'origen de cadascun dels requisits és clar i si facilita la referència de cada condició en la documentació de desenvolupament o millora futura.
Hi ha dos tipus de traçabilitat:
1. Traçabilitat enrere: Això depèn de que cada requisit faci referència explícita a la seva font en documents anteriors.
2. Traçabilitat cap endavant: Això depèn que cada element de l'SRS tingui un nom únic o un número de referència.
La traçabilitat cap endavant del SRS és especialment crucial quan el producte de programari entra en la fase d'operació i manteniment. A mesura que es modifica el codi i el document de disseny, és necessari poder determinar el conjunt complet de requisits que poden afectar aquestes modificacions.
9. Independència del disseny: Hi hauria d'haver una opció per seleccionar entre múltiples alternatives de disseny per al sistema final. Més concretament, l'SRS no hauria de contenir cap detall d'implementació.
imprimir matriu en java
10. Testabilitat: Un SRS s'ha d'escriure de tal manera que sigui senzill generar casos de prova i plans de prova a partir de l'informe.
11. Comprensible pel client: Un usuari final pot ser un expert en el seu domini explícit, però pot ser que no estigui format en informàtica. Per tant, el propòsit de les notacions i símbols formals s'hauria d'evitar tant com sigui possible. El llenguatge ha de ser senzill i clar.
12. El nivell d'abstracció adequat: Si l'SRS està escrit per a l'etapa de requisits, els detalls s'han d'explicar explícitament. Mentre que, per a un estudi de viabilitat, es poden utilitzar menys anàlisis. Per tant, el nivell d'abstracció es modifica segons l'objectiu de l'SRS.
Propietats d'un bon document SRS
Les propietats essencials d'un bon document SRS són les següents:
Concís: L'informe de l'SRS ha de ser concís i, al mateix temps, inequívoc, coherent i complet. Les descripcions verbals i irrellevants redueixen la llegibilitat i també augmenten les possibilitats d'error.
Estructurat: Ha d'estar ben estructurat. Un document ben estructurat és fàcil d'entendre i modificar. A la pràctica, el document SRS se sotmet a diverses revisions per fer front als requisits de l'usuari. Sovint, els requisits dels usuaris evolucionen durant un període de temps. Per tant, per facilitar les modificacions al document SRS, és vital que l'informe estigui ben estructurat.
Vista de caixa negra: Només ha de definir què ha de fer el sistema i abstenir-se d'indicar com fer-ho. Això vol dir que el document SRS hauria de definir el comportament extern del sistema i no discutir els problemes d'implementació. L'informe SRS hauria de veure el sistema a desenvolupar com una caixa negra i hauria de definir el comportament visible externament del sistema. Per aquest motiu, l'informe SRS també es coneix com l'especificació de caixa negra d'un sistema.
Integritat conceptual: Ha de mostrar integritat conceptual perquè el lector només la pugui entendre. Resposta a esdeveniments no desitjats: hauria de caracteritzar les respostes acceptables a esdeveniments no desitjats. S'anomenen resposta del sistema a condicions excepcionals.
Verificable: Tots els requisits del sistema, tal com es documenten al document SRS, haurien de ser correctes. Això vol dir que hauria de ser possible decidir si s'han complert o no els requisits en una implementació.