Está en la página 1de 14
Introduccion a la ingenieria de requisitos Un requerimiento es una caracteristica © una restriccicn que dabe tener el siste- ma. Segun Ia IEEE, un requerimiento es la capacidad que debe tener en un sistema © en sus componentes para satisfacer un contrato, esténdar, especificacién u otro documento formal. Roside en recopilar, anolizar y verificar la informacion necesoria para satisfacer las necesidades del usuario o cliente y las propias del sistema; en el desarrolla de sof- ‘tware esta tarea es de mucha importan- cia, ya que tiene como finalidad entendery especificar les requisites del sistema, para allo es necesario asurnir que es un procedi- milento tecnico que suele invalucrar a mu- chas personas, dependionda del tarnaho (© magnitud del software, lo que en oca- siones hace que la actividad sea bastante compleja. Estas acciones comprenden Ia obten- cién de informacion (recoleccion, andlisis, ion, especificacion y validacién de los requisitos del software) y = 5] — estoblece una actividad de Eesticcién: gestion de raquorimiantos Conaaonqiossestbh ara manejar los cambios, “= pe _ + Rostabildod: €l mantanimiento y la c0s- Condon hace tieabilidad dellos mismmas. juste deer Sgr Esto claramente indica que es lo qua se debe hacer al momento de emprender un proyecto de desarrollo de software, que consiste en aplicar las técri: cas necesarias para recopilar informacion y con esta hacer un andlisis de requerimien- ‘tos para identificar las funciones aperati vas del software, identificar plenamente las restriccionesy limitaciones del mismo y cla vez poder establecer la interfoz. Es importante establecer que el andlisis da raquisitos lo puede hacer un ingeniero de sistemas, ingeniero de software 0 un profesional en andliss 0 disento de sistemas de informacién, lo importante es construir los requerimientos basicos, utilizande uno de los modelos que se utilizan para esta actividad, que menciona Reger Pressman y que visualizamos en Ia siguiente tabla. Modelos basados en el escenario de los requerimientos desde el punto de visto de distintos “actores" del sistema Modelo de dates, que ilustran el dominio de la informacién problema. Modeles orientadas a clases, que representan claes orientada a objetos (atributas y ope- raciones) y la manera en que las clases colaboran para cumplir con los requerimientos del sistema. Modelos orientades al flujo, que representan los elementos funcionales del sistema y la ma- negra céme transforman les datos a medida que avanzan a través del sistema. Modelos de comportamiento, que ilustran el mada en que se comparten el software como consecuencia de “eventos” externos. Independiente del modelo que se utilice para el andlisis de requerimientas, este debe dar como resultada las pautas para que el desarrallador y el cliente evalua Ia calidad del mismo una vez se ponga en funcionamiento, ademas de esta tambien permite al disefador establecer los datos de Ia inor‘oz. El modelo basado en escenario se ha convertido en el mds usado y en una buena técnica dentro de los procesos de Ingenieria del software. El modelo basado en datos se utlliza mds que todo cuando se va a desarrollar un. software de mayor complelidac. EI modelo orientado a clases lo que hace es representar el funcionamiento del siste- ma mediante clases orientada a objetos. Descripcién ——B§ CET ota tome eters: Bemerto que perme ot ‘plcacion ‘Complajicact Dieese dé un software que conmlene muchos procesos 0 subsixemar Acepl 3 bt Ropebiced dose del disefio. to} Figura 1. Fases del modelo de especificacién de requerimiantos Pora el andlisis de sistemas Arlow y Neudstadt recomiendan que sea muy importante aplicar protacoles para crear e! modele del andlisis: * Eleje central del madelo recae en las requerimientos para que estén orientadas a la solucién del problema 6 dentro del deminio del negocio, y expliquen la funcionalidad del sistema. + Cada componente del modelo de requerimientos debe ser claro y abjetive para que permita entender el dominio de Ia informacién, los pracedimientos y el comporta- mianto dal software con un nivel de cbstraccién bastante alto para que cuando lle- gue ala etapa de disefio sea entendible y no se retrase este proceso. + Las relaciones entre las clases y las funciones deben representarse haciéndase un es- fuerzo para simplificor la interconectividad minimizando el ccoplamianto por med del sistema. Este modelo da requerimientos dabe cumplir una funcionalidad adecuada, es decir que por medio del mismo el cliente pueda evaluar los requerimientos, el gestor de ca- lidad lo pueda utilizar para generar un plan estratégico para raalizar las pruebas y los diseftadoras lo entiendan y plasmen unica y exclusivamente los diagramas necesarios para el desarrollo del producto, es decir que contenga la informacion apropiada para no crear diagramas innecesarios Anélisis de dominio: consiste en analizar, reconacer y determinar requerimientos través de un dominia de oplicacion definida, para que ser reutilizade en varios proyectos. Andlisis de dominio orientade a objetos: reside on establecer y analizar las compe- tencias y rautilizarlas en condicién de clases, objets y estructuras dentre de un dominio de aplicacién determinado. Dominio de aplicacién determinado o especifico: su finalidad es crear 9 hallar pa- trones de andlisis manejables de manera tal que se puedan reutilizar. Frecuantamente se hallan patrones de andlisis reutilizable en un dominio establecide, los cuales hacen que el modelo del andlisis sea practicable a la hora de clasificarlos y determinarlos, de manera que se logren identificar y emplear para dar respuesta a pro- blamas normales. Cuanda se introducen patrons de disefo y elementos de software ejecutable, estos generan una mejora, tanto en el tiempo camo en el coste de desarrolis llevando a que sean minimos. Biblograta tecnica. eee Peete Exéndoesde revtizocin, ae Encuestas chetes poate eee ies Caer ss Requerimientos netunlesy futuro. ech = eee rs Batt ass Ciera ae el oe Re eit net Requerimientos basicos Son aquellos que nos permiten identificar cual ¢s el proceso basico de la organizacion y su funcio- nalidad, para ello nos en- focamos en los usuarios del sistema mediante Ia ebservacién o antrovistas, con esto se abtione infor- macién detallada sobre qué tipos de datos utiliza © produce este praceso, el paso a pase de cada proce- dimiento que realiza cada usuario. Ademés, se podra evidenciar el tiempo que tarda en ejecutorse cada actividad y con qué fre- cuencia la hacen, el fujo de datos y quiénes emplean la informacién resultante, Io que permite describir la-ac- tividad (funciones, procedi- mientos y qué informacion se obtiene), el analista de requerimientos despues de la descripcion del problema por el cliente debe realizar fen un documento inicial una lista de raquerimiontos especificos, para mencio- nar en detalle el problema planteado por el cliente, este documento debe ser analizado para darle con- sistencia durante la fase de andlisis de requerimientes. Otra clasificacién de los requerimientos del sistema puede darse me- diante Ia identificacién de los elementos que la componen como: el pro- ceso basic de la empre- sa, Ia finalidad de esta actividad, para llevarla a cabo, dénde se realizan estos pasos, personas que lo realizan, el tiempo que tarda en efectuarle, cual es la frecuencia en que se hacen, personas que emplean Ia informacién resultante, los datos uti- lizados © producidos en este proceso y los limites impuestos por el tiempo y la carga de trabajo (cau- sa-frecuencia), les con- troles de desempefio que se utilizan (debilidad, es ‘tandares, errores). Especificacién y validacién Muchas de las caracte- risticas de calidad de los requerimientos han sido conocidas desde muchos aos; sin embargo, aun hoy dia muchos proyectos carecen de algunas de es- tas, por lo cual producen productos de software con poca calidad, pera mejorar los caracteristicas de cal- dad de los requerimientos es nacesario datallar los conceptos que permiten ‘optimizar la calidad de los requerimientos de software Ia cual debe estar dada de acuerdo a sus coracteristi cas, permitiendo gorant zor a los desarrolladores

También podría gustarte