Recull de preguntes i respostes sobre requeriments - any anterior

From Es1

Jump to: navigation, search

P

(Silvia & Javi) No entenem la part de la A3 que fa referència a la rastrejabilitat, ens en podeu donar un exemple?

R

(Pau) Molt senzill: es tracta de posar els stakeholders que ens han donat informació per fer la fitxa del cas d'ús. Per exemple, el cas d'ús "definir àlbum" potser l'hem fet amb informació que ens ha donat el directiu de Singalong i el dissenyador gràfic (estic dient stakeholders hipotètics). Cal que hi poseu imaginació, això sí.

P

(Alan & Alba) No tenim clar si les tasques de manteniment es consideren un cas d'ús del nostre sistema, la qual cosa implicaria que l'administrdor de sistemes es convertiria en un actor primari, per exemple. Tot plegat sembla bastant subjectiu i difús, cadascu ho pot enfocar d'una manera diferent, per la qual cosa una petita orientació (on cal posar el límit, per no anar-nos estenen amb més i més casos d'ús) no ens vindria malament.

R

(Pau) Crec que és una bona pregunta. L'activitat de fer els casos d'ús consisteix en imaginar-se com serà el sistema un cop desenvolupat i implantat. Quin són els principals serveis que ofereix, i amb quins actors dialoga el sistema.
En canvi les tasques de desenvolupament serveixen per arribar a l'estat en que el sistema està funcionant com hem previst. Això també inclou les tasques de desenvolupament "correctives" (arreglar bugs). Quan fem desenvolupament "evolutiu", canviem la funcionalitat originalment prevista; això implica que també cal modificar els casos d'ús originals, si és que ens interessa mantenir-los actualitzats. En tot cas, el desenvolupador no interactua amb el sistema tal com ha estat pensat, sinó que el modifica, per tant no és un actor.
Ara un exemple del que sí seria un actor: Imagineu-vos que durant la vida del sistema, la base de dades anirà creixent perquè, diguem, guardem l'històric de totes les baixades de cançons. Com que l'espai és limitat necessitem un actor "administrador de BD" que s'encarregui d'eliminar les dades antigues periòdicament. Un altre exemple seria el de fer backups de les dades importants.
El punt clau és que aquest administrador interactua amb el sistema sense modificar-lo.


P

(Alan & Alba) D'altra banda pel que fa a l'entrega A3, en un principi ens ha semblat entendre que els requeriments funcionals es feien només dels casos d'ús dels quals hem creat fitxa (com a últim apartat dins d'aquesta), però en un punt posterior sembla que es refereixi a requeriments funcionals de TOTS els casos d'ús. Era bona la nostra primera impressió?

R

(Pau) Sí, era bona. Potser l'enunciat no és molt clar. Per cada cas d'ús que hagueu fet una fitxa, cal afegir-hi els seus requeriments funcionals associats. De fet, els escenaris que posem a la fitxa dels casos d'ús ja són requeriments funcionals, però sovint trobem requeriments addicionals que no s'expressen de forma natural dins la fitxa.
A banda d'això us demanem els requeriments "generals" que no estan associats a un cas d'ús concret. De requeriments generals heu de fer els funcionals, els no funcionals i els de domini.
No ens interessa que els requeriments siguin complets. Ens interessa que estiguin ben pensats i redactats (seguint les recomanacions de l'anunciat). El lema seria: qualitat abans que quantitat.

P

(Marcel M.) Aquesta pràctica ha de ser la continuació dels html's de la A2, es a dir els requeriments funcionals s'han de posar, per exemple al mateix html amb un link que digui "requeriments funcionals del cas d'us tal"??? a continuacio del link que et porta a la fitxa del cas d'ús, o no cal afegir-ho al que vam fer a la practica A2 i s'ha de fer per separat i entregar-ho per separat?

R

(Pau) Cal anar treballant sobre el mateix document i anar-lo millorant. Creeu apartats amb sentit a criteri vostre i si cal feu reestructuracions. En concret, els requeriments funcionals de cada cas d'ús els podeu posar després de la fitxa del cas d'ús.

P

(Marcel M.) Tampoc entenem lo del "tag" alhora d'entregar-ho , el tag vol dir el missatge que escrius cuan pujes una nova versió al subversion? es a dir a la ultima versio que pujessim (que seria la d'entrega posem : "Entrega ES1-12DJ-13-A3" al missatge? ) ???

R

(Pau) No. El tag no és el missatge de commit. Això ha quedat pendent explicar-ho a classe. I amb el david acabem de decidir que no farà falta posar tags per les entregues. Però sí que caldrà que quan envieu el mail de l'entrega digueu quina és la revisió corresponent a l'entrega.
Per exemple a l'entrega ES1-12DJ-13-A3 heu de posar, per exemple, "Entreguem la revisió 123".

P

(Marcel M.) Tampoc entenem exactament que vol dir el punt 5 cuan diu "Useu links sempre que sigui útil. Per exemple a l'apartat de Requeriments funcionals generals quan un requeriment es refereixi a certs casos d'ús concrets. Un altre cas (important!) és la fitxa de cada cas d'ús: cal linkar les referències als casos d'ús relacionats per <<uses>> i <<extends>> " . Nomes tenim 3 fitxes de casos d'ús , Ho hem de linkar a la llista de casos d'us amb la breu descripcio que ja tenim?

R

(Pau) L'enunciat A2 diu que cal fer la fitxa dels 3 casos d'ús i també dels seus relacionats. per tant, us falten fitxes! i els links que posareu seran cap a altres fitxes.

P

(Oriol G.) Voldria saber amb més detall que se'ns demana a l'apartat 2) Elaborar un glossari de termes del domini. Què hauria de ser? , un llistat amb les característiques que ha de tenir el sistema? o bé, un llistat dels passos que un usuari seguira en el sistema?

R

(Pau) No pas! Lo primer que dius seria, en tot cas, "requeriments". I lo segon podria ser un diagrama de seqüència o d'activitats --ja ho veurem més endavant.
El glossari és un petit diccionari: parelles de terme i traducció (curta però precisa). El domini és tot allò referent al negoci, àmbit, camp concret que volem informatitzar. En el nostre cas, el domini és el negoci de les discogràfiques per internet. Per tant el domini cobreix coses com els formats d'àudio, els actors implicats en el negoci, tipus de productes a la venta, etc.
Imagineu-vos que voleu explicar de que va aquest negoci a una persona que no en té la més remota idea, quins conceptes li explicarieu?
Noteu també que els termes informàtics involucrats en la implementació del sistema no formen part del domini
Retrieved from "http://parumi.org/wikis/es1/index.php?title=Recull_de_preguntes_i_respostes_sobre_requeriments_-_any_anterior"
Personal tools