L'anàlisi de requisits, en 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 requisits entre diversos stakeholders (o interessats), com a beneficiaris o usuaris.
Conceptualment, l'anàlisi de requisits inclou tres tipus d'activitat:
- Obtenció de requisits: La tasca de comunicar-se amb els clients i usuaris per a determinar quins són els seus requisits. També anomenat recollida de requisits.
- Anàlisi dels requisits: Determinar si els requisits enunciats són poc clars, incompletes, ambigus, o contradictoris, i llavors resoldre aquests problemes.
- Enregistrament de requisits: Els requisits 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 requisits 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 que entenen les implicacions dels nous sistemes.
Els analistes poden fer servir diverses tècniques per a obtenir els requisits del seu client. Històricament, això ha inclòs diverses coses com ara fer entrevistes, o tallers de requisits, i crear llistes de requisits. 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 requisits exactes dels interessats, de forma que finalment es construeixi un sistema que satisfà les necessitats del negoci.
L'enginyeria de requisits é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 requisit 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 requisits pot començar.[1] Si l'anàlisi de requisits 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 requisits siguin finalitzats.
Identificació dels interessats
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
Les entrevistes amb els interessats són un mètode comú usat en l'anàlisi de requisits. Aquestes entrevistes poden revelar requisits no prèviament imaginats com a part del projecte, i requisits que poden ser contradictoris. Això no obstant, cada interessat tindrà una idea de les seves expectatives o haurà visualitzat els seus requisits.
Contractes de requisits
Una forma tradicional de documentar requisits ha estat llistes de requisits amb estil de contracte. En un sistema complex, els contractes de requisits poden ocupar centenars de pàgines.
Objectius mesurables
Les millors pràctiques agafen la llista de requisits 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 requisits 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
A mitjan anys 80, el prototipatge es veia com la solució al problema de l'anàlisi de requisits. 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 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 requisits:
- 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 se 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 requisits 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
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
Els casos d'ús són una tècnica de documentació de requisits molt estesa, entre altres motius, perquè UML hi dona suport. Es tracta d'un enfocament a la manera de documentar els requisits 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 requisits 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 requisits de software
Especificació de requisits 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 requisits funcionals. A més dels casos d'ús, l'ERS conté també requisits no funcionals (o suplementaris). Els requisits no funcionals són requisits que imposen restriccions al disseny o la implementació (com ara requisits 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 requisits de software. Aquest estàndard descriu possibles estructures, continguts desitjables, i qualitats d'una especificació de requisits de software.
Els requisits es poden categoritzar de diverses formes. A continuació es mostren diverses formes de categoritzar els requisits en relació a la gestió tècnica.
Requisits de client
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 requisits 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?
- Requisits 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?
Requisits funcionals
Els requisits 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 requisits funcionals serà fet servir com a funcions del més alt nivell per a l'anàlisi funcional.
Requisits no-funcionals
Els requisits 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.
- Requisits 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 requisits, els requisits 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 requisits.
- Requisits de disseny
- Requisits derivats
- Requisits que són implicats o transformats des d'un requisit de més alt nivell. Per exemple, un requisit de rang llarg o alta velocitat pot resultar en un requisit de disseny per a poc pes.
- Requisits distribuïts
- Un requisit que és establert mitjançant la divisió o el repartiment d'un requisit de més alt nivell en múltiples requisits de més baix nivell. Exemple: Un element de 100 kg que consisteix en dos subsistemes pot resultar en requisits de pes de 70 kg i 30 kg per als dos elements de més baix nivell.
Problemes dels interessats
Steve McConnel, al seu llibre Rapid Development, detalla una sèrie de formes amb què els usuaris poden dificultar la recollida de requisits:
- Els usuaris no entenen què volen no tenen una idea clara dels seus requisits
- Els usuaris no es comprometran a un conjunt de requisits per escrit
- Els usuaris insisteixen en nous requisits 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 requisits dels usuaris continuen canviant inclús quan el desenvolupament del producte o del sistema ha començat.
Problemes dels enginyers i desenvolupadors
Possibles problemes causats per enginyers i desenvolupadors durant l'anàlisi de requisits 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 requisits 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
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 requisits textuals i altres comentaris
- Capacitat perquè usuaris remots i distribuïts executin i interaccionin amb la simulació
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
