Dijous 11 d'Octubre
El document de requeriments té un doble objectiu:
Per això és interessant distingir dues audiències quan redactem el document de requeriments: farem els requeriments d'usuari adreçats a una audiència no tèncnica, i els requeriments de sistema orientats a una audiència tècnica.
En el nostre cas, tot el que estem treballant en el bloc A (requeriments de domini, casos d'ús, funcionals i no funcionals) ho podem veure com els requeriments d'usuari. En canvi els requeriments de sistema serà una versió més detallada i formal dels requeriments. Més endavant veurem que una forma d'expressar aquests requeriments és usant tests funcionals escrits en codi (executables). Els dos tipus de requeriments han d'estar relacionats per poder contrastar-los
Coherència del llenguatge
Actor: Quelcom (persona, sistema extern...) que interactua amb el sistema en consideració. En un determinat cas d'ús, els actors que intervenen són:
Un escenari és un exemple concret de com es pot desenvolupar un cert cas d'us. Per cada cas d'ús hi ha escenaris d'èxit i escenaris de fracàs segons si la intenció de l'actor primari es compleix o no. Per descriure el cas d'ús, escollirem l'escenari d'èxit més clar i directe com l'escenari exitós principal i enumerarem el fluxe d'events d'aquest escenari.
La resta de escenaris, tant exitosos com de fallada, es descriuen com a extensions respecte aquest escenari principal. Una extensió es defineix amb:
Així podem anar afegint extensions de forma incremental a l'escenari principal que al mateix temps queda més entenedor que si incorporessim la lògica de casos.
Les relacions entre casos ens permeten simplificar la lectura i escriptura de la seva descripció.
Relació includes |
A vegades, massa detall en els passos d'un cas d'ús el fa dificil de llegir. Sovint els passos s'agrupen en un nou cas d'ús i simplement s'hi estableix una relació d'inclusió (el gran inclou el cas d'ús de detall). Fer servir l'inclusió ens pot estalviar reescriure aquests passos en uns altres casos d'ús i facilita la lectura. |
Relació extends |
Quan tenim extensions llargues o extensions amb extensions,
el cas d'ús pot esdevindre dificil d'entendre.
Sovint és més clar extreure una alternativa com
un cas d'ús diferent
relacionat amb l'original per una relació d'extensió.
Diem que un cas d'ús (extensió) extén un altre (base) si defineix un fluxe d'events alternatiu al base que cal seguir quan es donen certes circumstàncies. |
Relació generalizes |
Sovint hi ha casos d'ús que tenen característiques molt semblants. Per no haver de repetir aquestes característiques a tots els casos d'ús podem crear un cas d'ús incomplert que defineixi les coses comuns. Les especialitzacions d'aquest cas d'ús hereden totes les relacions y definicions que fem al cas d'us generalitzat. |
Exemple de relacions entre casos d'ús:
Nota: Aquest diagrama és només un exemple de relacions. I no és directament aplicable al nostre problema.
També hem posat un exemple de redacció de casos d'ús. Al capítol 6.5 dels apunts pots trobar molta més informació sobre com elaborar els diagrames de casos d'ús i la documentació dels fluxes d'events. A continuació presentem un exemple de redacció d'un cas d'ús d'un altre sistema especialitzat en venda de música:
Cas d'ús: Definir àlbum Context: Un músic o operador vol agrupar cançons en un àlbum que pugui ser distribuit en suport físic. Actors primaris: Definidor d'album (generalitza Músic i Operador) Actors de suport: Responsable catàleg Precondicions: - El definidor està validat al sistema com a usuari de tipus músic o operador - El definidor ha introduit previament totes les cançons que vol posar a l'àlbum dintre del sistema - El definidor té una caràtula dissenyada al seu ordinador Postcondicions d'èxit: - El album queda definit i disponible pels futurs compradors - El Responsable del catàleg rep una notificació per mail del nou àlbum definit Postcondicions de fracàs: - El sistema no modifica el seu estat intern Escenari exitós principal: 1. El definidor introdueix la informació de l'àlbum (nom, artista, any, estils) 2. El sistema cerca les cançons disponibles y les presenta l'actor 3. El definidor <<determina la llista ordenada de les cançons>> que entraran a l'àlbum. 4. El sistema verifica que el tamany de les cançons no supera el tamany del CD 5. El definidor <<defineix la caratula>> de l'àlbum. 6. El definidor confirma la definició d'àlbum. 7. El sistema calcula el preu de cost i els marges de la discogràfica 8. El definidor defineix el marge que vol obtenir 9. El sistema posa àlbum a disposició de futurs compradors 10. El sistema envia una notificació per mail al responsable del catàleg Extensions: 4.a. El tamany de les cançons supera el tamany del CD 4.a.1. Tornem al pas 2 6.a. El definidor no està d'acord amb la definició 6.a.1. Tornem al pas 1, però oferint les dades ja entrades. 1-8.a. La sessió web finalitza abans de acabar la transacció 1-8.a.1. Tota la definició de l'àlbum queda invalidada 1-8.b. El definidor cancel.la la definició 1-8.b.1. Tota la definició de l'àlbum queda invalidada Includes: - Determinar llista ordenada de cançons - Definir caràtula Requeriments Funcionals Associats: - La notificacio al Responsable del catàleg ha de contenir: - Qui ho ha definit - La informacio de l'àlbum - La llista dels tracks - El CD grabat incloura la informació textual dels tracks - Al pas 1 cal presentar una llista d'estils existents - El preu de cost d'un CD és el definit al cas d'ús Fixar Preu de Venda - El marge de la discogràfica és marge de senzill si no supera els 4 tracks. - El marge de la discogràfica és marge de llarga durada, si té 4 tracks o més. - Els marges de senzill i de llarga durada són els definits al cas d'ús Fixar Preu de Venda - Les cançons descatalogades no es presenten com a disponibles - En el cas que el Definidor sigui un Músic, les cancions disponibles han de restringir-se a les del músic. - En el cas que el Definidor sigui un Operador, les cancions disponibles són les de tots els músics. - En cas que el Definidor sigui operador, la llista de cançons disponibles serà navegable per musics. - la llista de disponibles ha de contenir les cançons no seleccionades en tot moment - El Definidor ha de poder dessel.lecionar de la llista de tracks cançons previament seleccionades - El Definidor ha de poder reordenar la llista de tracks - El sistema ha de mostrar al Definidor el cost del CD, el marge de la discogràfica i la suma. (veure domini[marge_discografica, costos] Requeriments No Funcional Associats: - El tamany de l'álbum es limita a 65 minuts - Cadascuna de les pantalles presentades inclourà al costat una descripció detallada del punt del procés i del que l'usuari ha de fer. - La interfície ha de ser per web. (general?) - L'accés a la interficie web ha de estar encriptat. (general?) Requeriments de Domini Associats: - Un CD d'audio està limitat a 99 tracks
Al redactar els requeriments hem de tenir en compte:
Validació
Qué hauríem de revisar de la redacció abans de donar-lo al client per que ho validi?
Què comprovarà el client a la validació?
I haurem d'iterar el procés d'obtenció dels requeriments fins que el validador (client) consideri que les quatre coses es compleixin (o nosaltres ens busquem altres clients amb les idees més clares).
Són restriccions sobre els requeriments funcionals o al procés de desenvolupament. A vegades són massa subjectius, cal que siguin descrits de forma concreta (quantificant) per tal de poder-los verificar.
A continuació teniu una classificació dels requeriments no funcionals. Aquesta classificació ens va molt bé fer-nos descobrir requeriments no funcionals.
Nota: No cal posar al document, a quina categoria cau cada requeriment
Nota:
Com que a l'enunciat no tenim gaire informació concreta haureu de fer servir la imaginació. Fent servir el sentit comú, això sí.
Al món real també té sentit "inventar-se" alguns requeriments no funcionals, ja que serveix com a proposta concreta que el client haurà de validar (o no).