Anàlisi de requeriments

De Viquipèdia
Dreceres ràpides: navegació, cerca

L'anàlisi de requeriments (o requisits) a enginyeria de sistemes i enginyeria de software, comprèn aquelles tasques que determinen les necessitats o condicions que un producte nou o modificat ha de complir, tenint en compte els possibles conflictes de requeriments entre diversos stakeholders (o interessats), com a beneficiaris o usuaris.

Visió general[modifica | modifica el codi]

Conceptualment, l'anàlisi de requeriments inclou tres tipus d'activitat:

  • Obtenció de requeriments: La tasca de comunicar-se amb els clients i usuaris per a determinar quins són els seus requeriments. També anomenat recollida de requisits.
  • Anàlisi dels requeriments: Determinar si els requeriments enunciats són poc clars, incompletes, ambigus, o contradictoris, i llavors resoldre aquests problemes.
  • Enregistrament de requeriments: Els requeriments es poden documentar de diverses formes, com ara documents en llenguatge natural, casos d'ús, històries d'usuari, o especificacions de procés.

L'anàlisi de requeriments pot ser un procés llarg i difícil durant el qual s'han de fer servir moltes habilitats psicològiques delicades. Els nous sistemes poden canviar l'entorn i les relacions entre la gent, per tant és important identificar a tots els interessats, tenir en compte totes les seves necessitats, i assegurar-se de que entenen les implicacions dels nous sistemes.

Els analistes poden fer servir diverses tècniques per a obtenir els requeriments del seu client. Històricament, això ha inclòs diverses coses com ara fer entrevistes, o tallers de requeriments, i crear llistes de requeriments. Algunes tècniques més modernes són fer prototipus, i casos d'ús. Si és necessari, l'analista farà servir una combinació d'aquests mètodes per a establir els requeriments exactes dels interessats, de forma que finalment es construeixi un sistema que satisfà les necessitats del negoci.

Enginyeria de requeriments[modifica | modifica el codi]

L'enginyeria de requeriments és una subdisciplina de l'enginyeria de sistemes i de l'enginyeria de software que es preocupa de determinar els objectius, funcions, i restriccions de sistemes de hardware i software. En alguns models de cicle de vida, el procés d'enginyeria de requeriment comença amb una activitat d'estudi de factibilitat, que desemboca en un informe de factibilitat. Si l'estudi de factibilitat suggereix que el producte hauria de ser desenvolupat, llavors l'anàlisi de requeriments pot començar.[1] Si l'anàlisi de requeriments precedeix als estudis de factibilitat, cosa que pot contribuir a pensar des de noves perspectives (out of the box thinking), llavors la factibilitat hauria de ser determinada abans que els requeriments siguin finalitzats.

Temes de l'anàlisi de requeriments[modifica | modifica el codi]

Identificació dels interessats[modifica | modifica el codi]

Els interessats són persones que seran afectades pel sistema, directament o indirectament.

Als anys 90 es va posar per primera vegada molt d'èmfasi en la identificació dels interessats. És reconegut de forma creixent que els interessats no es limiten a l'organització que contracta l'analista. Altres interessats poden ser:

  • Aquelles organitzacions que s'integren (o haurien d'integrar-se) horitzontalment (és a dir, que estan a la mateixa fase de la cadena de servei o producció) amb l'organització per a la que l'analista està dissenyant el sistema
  • Sistemes o organitzacions interns (backoffice)
  • Gestió sènior

Entrevistes amb els interessats[modifica | modifica el codi]

Les entrevistes amb els interessats són un mètode comú usat en l'anàlisi de requeriments. Aquestes entrevistes poden revelar requeriments no prèviament imaginats com a part del projecte, i requeriments que poden ser contradictoris. Això no obstant, cada interessat tindrà una idea de les seves expectatives o haurà visualitzat els seus requeriments.

Contractes de requeriments[modifica | modifica el codi]

Una forma tradicional de documentar requeriments ha estat llistes de requeriments amb estil de contracte. En un sistema complex, els contractes de requeriments poden ocupar centenars de pàgines.

Objectius mesurables[modifica | modifica el codi]

Les millors pràctiques agafen la llista de requeriments com a simples pistes i pregunten repetidament "per què?" fins que els propòsits reals del negoci són descoberts. Els interessats i els desenvolupadors poden llavors idear proves per a mesurar quin nivell de cada objectiu ha estat assolit fins a aquell punt. Aquests objectius canvien més lentament que la llarga llista de requeriments específics però no-mesurats. Un cop s'ha establert un petit conjunt d'objectius crítics i mesurats, el prototipatge ràpid i fases de desenvolupament d'iteracions curtes poden procedir a entregar valor real per a l'interessat molt abans que el projecte sigui acabat.

Prototipus[modifica | modifica el codi]

A meitat dels anys 80, el prototipatge es veia com la solució al problema de l'anàlisi de requeriments. Els prototipus són maquetes d'una aplicació. Les maquetes permeten als usuaris visualitzar una aplicació que encara no ha estat construïda. Els prototipus ajuden als usuaris a tenir una idea de quin aspecte tindrà el sistema, i faciliten que els usuaris puguin prendre decisions sense esperar a que el sistema estigui construït. Amb la introducció dels prototipus, sovint es veien grans millores en la comunicació entre els usuaris i els desenvolupadors. Poder veure l'aplicació abans va portar a la disminució dels canvis posteriors i per tant a una disminució considerable del cost total.

Això no obstant, durant la següent dècada, tot i demostrant que era una tècnica útil, el prototipatge no va resoldre el problema dels requeriments:

  • Els gestors, un cop veuen un prototipus, poden trobar difícil d'entendre que el disseny final no serà produït fins d'aquí a un temps.
  • Els dissenyadors es senten sovint convençuts a fer servir codi del prototipus al sistema real, ja que temen "perdre temps" començant de nou.
  • Els prototipus ajuden principalment amb decisions de disseny i de la interfície d'usuari. Això no obstant, no poden dir-te quins eren els requeriments originals.
  • Els prototipus funcionen bé per a interfícies d'usuari, distribucions de pantalla i flux de pantalles, però no són tan útils per a processos diferits o asíncrons que poden incloure complexes actualitzacions i/o càlculs de bases de dades.

Els prototipus poden ser diagrames plans ("wireframes" o "filferro") o aplicacions amb funcionalitat sintetitzada. Els wireframes són fets en diversos documents de disseny gràfic, i sovint no tenen colors on s'espera que el software final sí en tingui. Això ajuda a prevenir confusions en relació al look and feel final de l'aplicació.

Històries d'usuari[modifica | modifica el codi]

Les històries d'usuari són l'eina de documentació de requisits més habitual en els mètodes àgils. Els components bàsics d'una història d'usuari són:

  • Una descripció escrita de la història (serveix com a recordatori que existeix la història i és útil per a planificar, etc.).
  • Un seguit de converses que serveixen per a definir i aclarir els detalls de la història.
  • Un conjunt de proves que documenten els detalls i que permeten determinar quan la història està implementada completament.

El principal avantatge i, al mateix temps, el principal inconvenient, de les històries d'usuari, és que estan molt enfocades a la comunicació verbal. Això permet que la comunicació sigui més àgil i més fluida, amb la qual cosa els requisits seran més propers a les necessitats reals dels interessats però, en canvi, no queden registrades, amb la qual cosa no es tenen tots els detalls per escrit.

Cal tenir en compte, però, que la conclusió final de les converses sí que queda documentada, i a més, en un format que en facilita la validació, ja que estan documentades en forma de proves. Un altre avantatge de les històries d'usuari és que estan escrites en el llenguatge dels usuaris o interessats. De fet, són els usuaris o interessats mateixos els que, idealment, haurien d'escriure les històries d'usuari.

Casos d'ús[modifica | modifica el codi]

Els casos d'ús són una tècnica de documentació de requisits molt estesa, entre altres motius, perquè UML hi dóna suport. Es tracta d'un enfocament a la manera de documentar els requeriments potencials d'un nou sistema o canvi de programari. Cada cas d'ús proporciona un o més escenaris que expressen com el sistema hauria d'interaccionar amb l'usuari final o un altre sistema per a assolir un objectiu de negoci específic. Els casos d'ús típicament eviten l'argot tècnic, preferint al seu lloc el llenguatge de l'usuari final o de l'expert del domini. Els casos d'ús sovint són coredactats pels enginyers de requeriments i els interessats.

Un cas d'ús conté una descripció textual de totes les formes en què els usuaris ideals podrien treballar amb el programari o sistema. Els casos d'ús no descriuen cap treball intern del sistema, ni expliquen com serà implementat aquest sistema. Simplement mostren els passos que un usuari segueix per a portar a terme una tasca. Totes les formes en què els usuaris interaccionen amb el sistema poden ser descrites d'aquesta forma.

Especificació de requeriments de software[modifica | modifica el codi]

Especificació de requeriments de software (ERS) és una descripció completa del comportament del sistema a ser desenvolupat. Inclou un conjunt de casos d'ús per a descriure totes les interaccions que els usuaris tindran amb el software. Els casos d'ús són també coneguts com a requeriments funcionals. A més dels casos d'ús, l'ERS conté també requeriments no funcionals (o suplementaris). Els requeriments no funcionals són requeriments que imposen restriccions al disseny o la implementació (com ara requeriments de rendiment, estàndards de qualitat, o restriccions de disseny).

A la norma IEEE 830-1988 es descriuen recomanacions per a portar a terme especificacions de requeriments de software. Aquest estàndard descriu possibles estructures, continguts desitjables, i qualitats d'una especificació de requeriments de software.

Tipus de requeriments[modifica | modifica el codi]

Els requeriments es poden categoritzar de diverses formes. A continuació es mostren diverses formes de categoritzar els requeriments en relació a la gestió tècnica.

Requeriments de client[modifica | modifica el codi]

Declaracions de fet i assumpcions que defineixen les expectatives del sistema en termes d'objectius de la missió, entorn, restriccions, i mesures d'efectivitat i idoneïtat. Els usuaris són aquells que realitzen les vuit funcions principals de l'enginyeria de sistemes, amb especial èmfasi en l'operador com a client clau. Els requeriments operacionals definiran la necessitat bàsica i, com a mínim, respondran les preguntes posades a la següent llista:

  • Distribució o desplegament operacional: On es farà servir el sistema?
  • Perfil o escenari de missió: Com acomplirà el sistema els seus objectius de missió?
  • Rendiment i paràmetres relacionats: Quins són els paràmetres crítics del sistema per a acomplir la missió?
  • Entorns d'utilització: Com es faran servir els diversos components del sistema?
  • Requeriments d'efectivitat: Com d'efectiu o eficient ha de ser el sistema en la realització de la seva missió?
  • Cicle de vida operacional: Durant quant de temps el sistema serà fet servir per l'usuari?
  • Entorn: En quins entorns s'espera que el sistema operi de forma efectiva?

Requeriments funcionals[modifica | modifica el codi]

Els requeriments funcionals expliquen què ha de ser fet mitjançant la identificació de la tasca necessària, l'acció, o l'activitat que ha de ser acomplida. L'anàlisi de requeriments funcionals serà fet servir com a funcions del més alt nivell per a l'anàlisi funcional.

Requeriments no-funcionals[modifica | modifica el codi]

Els requeriments no funcionals són requisits que especifiquen criteris que poden ser fets servir per a jutjar l'operació d'un sistema, més que comportaments específics. És a dir, són requisits que expressen restriccions sobre el conjunt de solucions possibles.

Requeriments de rendiment
L'extensió fins a la que una missió o funció ha de ser executada; generalment mesurada en termes de quantitat, qualitat, cobertura, temporització o disponibilitat. Durant l'anàlisi de requeriments, els requeriments de rendiment (com de bé ha de ser fet) seran desenvolupats interactivament a través de totes les funcions identificades basades en factors del cicle de vida del sistema; i caracteritzades en termes de grau de certesa en la seva estimació, el grau de criticitat per a l'èxit del sistema, i la seva relació amb altres requeriments.
Requeriments de disseny
Requeriments derivats
Requeriments que són implicats o transformats des d'un requeriment de més alt nivell. Per exemple, un requeriment de rang llarg o alta velocitat pot resultar en un requeriment de disseny per a poc pes.
Requeriments distribuïts
Un requeriment que és establert mitjançant la divisió o el repartiment d'un requeriment de més alt nivell en múltiples requeriments de més baix nivell. Exemple: Un element de 100 kg que consisteix en dos subsistemes pot resultar en requeriments de pes de 70 kg i 30 kg per als dos elements de més baix nivell.

Problemes de l'anàlisi de requeriments[modifica | modifica el codi]

Problemes dels interessats[modifica | modifica el codi]

Steve McConnel, al seu llibre Rapid Development, detalla una sèrie de formes amb què els usuaris poden dificultar la recollida de requeriments:

  • Els usuaris no entenen què volen no tenen una idea clara dels seus requeriments
  • Els usuaris no es comprometran a un conjunt de requeriments per escrit
  • Els usuaris insisteixen en nous requeriments un cop el cost i el calendari han estat fixats
  • La comunicació amb els usuaris és lenta
  • Els usuaris sovint no participen en revisions o són incapaços de fer-les
  • Els usuaris són tècnicament ingenus
  • Els usuaris no comprenen el procés de desenvolupament
  • Els usuaris desconeixen la tecnologia actual

Això pot portar a una situació on els requeriments dels usuaris continuen canviant inclús quan el desenvolupament del producte o del sistema ha començat.

Problemes dels enginyers i desenvolupadors[modifica | modifica el codi]

Possibles problemes causats per enginyers i desenvolupadors durant l'anàlisi de requeriments són:

  • El personal tècnic i els usuaris tenen diferents vocabularis. En conseqüència, poden creure equivocadament que estan en perfecte acord fins que el producte finalitzat és entregat.
  • Els enginyers i els desenvolupadors poden intentar que els requeriments s'adaptin als d'un sistema o model existent, en comptes de desenvolupar un sistema específic per a les necessitats del client.
  • L'anàlisi pot ser sovint fet per enginyers o desenvolupadors, en comptes de pel personal amb les habilitats personals i el coneixement del domini que permeten entendre adequadament les necessitats del client.

Solucions intentades[modifica | modifica el codi]

Una solució intentada per als problemes de comunicació ha estat contractar a especialistes en anàlisi de negoci o de sistemes.

Les tècniques introduïdes als anys 90 com ara el prototipatge, UML, casos d'ús, i Agile (desenvolupament de software àgil), estan també pensades com a solucions per a problemes trobats amb mètodes anteriors.

També són ja al mercat una nova classe de simulacions d'aplicaicons o eines de definició d'aplicacions. Aquestes eines estan dissenyades per a cobrir el forat entre els usuaris del negoci i els desenvolupadors - i també per a permetre que les aplicacions siguin provades al mercat abans que es comenci a produir codi. Aquestes eines poden incloure:

  • Pissarres electròniques per a fer esbossos de flux d'aplicacions i provar alternatives
  • Capacitat per a capturar la lògica del negoci i les necessitats de dades
  • Capacitat per a generar prototipus d'alta fidelitat que imitin de prop l'aplicació final
  • Interactivitat
  • Capacitat per a afegir requeriments textuals i altres comentaris
  • Capacitat perquè usuaris remots i distribuïts executin i interaccionin amb la simulació

Referències[modifica | modifica el codi]

A Wikimedia Commons hi ha contingut multimèdia relatiu a: Anàlisi de requeriments Modifica l'enllaç a Wikidata
  1. Phillip A. Laplante (2007) What Every Engineer Should Know about Software Engineering. Page 44.

Vegeu també[modifica | modifica el codi]