Ingenieria de Requerimientos

 

INGENIERIA DE REQUERIMIENTOS 

La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna Ningun a otra otra parte parte del trabaj trabajo o concept conceptual ual es tan difíci difícill como como establ establece ecerr los requi requisi sito tos s técn técnico icos s detal detalla lado dos, s, in incl cluy uyen endo do toda todas s las las inte interf rfac aces es con con gent gente, e, máquinas máquin as y otros sistemas. sistemas. Ninguna otra parte del trabajo afecta tanto el sistema sistema si es hecha mal. Ninguna es tan difícil de corregir más adelante … Entonces, la tarea más importante que el ingeniero de softare hace para el cliente es la e!tracci"n iterati#a y el refinamiento de los requerimientos del producto. Introduccion:

Es muy frecuente escuchar entre los conocedores del desarrollo de software (programas (progra mas de comput computadoras), adoras), que un gran número de los proyectos de software fracasan por no realizar una adecuada definición, especificación, y administración de los requisitos. Dentro de esa mala administración se pueden encontrar factores como la falta de participaci participación ón del usuari usuario, o, requisitos incompl incompletos etos y el mal manejo del camio a los requisitos. !a "ngenier#a de $equisitos  $equisitos  ("$) cumple un papel primordial en el proceso de producción de software, ya que se enfoca un %rea fundamental& la definición de lo que qu e se dese desea a pr prod oduc ucir ir.. 'u pr prin inci cipa pall tare tarea a cons consis iste te en la gene genera raci ción ón de especificaciones correctas que descrian con claridad, sin amigedades, en forma consistente y compacta, las necesidades de los usuarios o clientes de esta manera, se pretende minimizar los prolemas relacionados por la mala gestión de los requisitos en el desarrollo de sistemas. Definicion: Requisito •

•

•

•

*na condición o necesidad de un usuario para resol+er un prolema o alcanzar un ojeti+o. *na condición o capacidad que dee estar presente en un sistema o comp co mpon onen enttes de siste istema ma pa para ra sa sattisf isfac acer er un cont contra rato to,, es estt%nda %ndarr, especificación u otro documento formal. *n requisito es simplemente una declaración astracta de alto ni+el de un ser+icio que dee proporcionar el sistema o una restricción de ste.

Definicion: Ingenieria de Requisitos

 

•

•

!a "ngenier#a de $equisitos ayuda $equisitos ayuda a los ingenie ingenieros ros de softw software are a entender  entender  mejor el prolema en cuya solución traajar%n. "ncluye el conjunto de tareas que conducen a comprender cu%l ser% el impacto del software sore el negocio, qu es lo que el cliente quiere y cómo interactuar%n los usuarios finales con el software. $equisitos es  es el proceso de desarrollar una especificación !a "ngenier#a de $equisitos de software. !as especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema.

•

!a  "ngenier#a de $equisitos !a  $equisitos se  se defin define, e, como un conjun conjunto to de acti+ acti+idades idades en las cuales, utilizando tcnicas y herramientas, se analiza un prolema y se concluye con la especificación de una solución (a +eces m%s de una).

•

Actividades de la Ingenieria de Requisitos:

•

Extracción:  Esta fase represent representa a el comie comienzo nzo de cada ciclo. E-tracc E-tracción ión es

el nom nomre re comú comúnm nmen ente te da dado do a las las acti acti+i +ida dade dess in+o in+olu lucr crad adas as en el descurimiento de los requisitos del sistema. •

Análisis:  'ore la ase de la e-tracción realiza realizada da pre+iamente, pre+iamente, comie comienza nza

esta fase en la cual se enfoca en descurir prolemas con los requisitos del sistema identificados hasta el momento. •

Especificación: En esta fase se documentan los requisit requisitos os acordados con

el cliente, en un ni+el apropiado de detalle. •

Validación: !a +alidación es la etapa final de la "$. 'u ojeti+o es, ratificar 

los requisitos, es decir, +erificar todos los requisitos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptale del sistema que se dee implementar. Esto implica +erificar que los requisitos sean consistentes y que estn completos. Técnic Técn icas as y erra erra!i !ien enta tas s ut util ili" i"ad adas as en las las acti activi vidad dades es de Ingenier#a Ingenier#a de Requisitos:: Requisitos

•

Entre+istas y cuestionarios 'istemas e-istentes

•

raaciones de +ideo y de audio

•

/rainstorming (tormenta de ideas)

•

•

 0rqueolog#a de documentos

•

 0prendiz.

•

1ser+ación

 

•

•

•

•

•

•

$un *se 2ase 3or4'hop (talleres de traajo asados en los 2asos de *so) 5rototipos  0n%lisis 61D0 (6ortalezas, 1portunidades, Deilidades y 0menazas) 0menazas) 2adena de +alor  7odelo de clase conceptual, Diagrama 2onceptual, Diagrama de 2lases 2onceptual Diagrama de pescado ("shi4awa Diagram, 2ause8and8Effect o 6ishone Diagram)

•

losario

•

Diagrama de acti+idad

•

Documento E'$E, 2asos de uso

•

!ista de requerimientos

•

2asos de uso

•

2asa de calidad o 96D (9uality 6unction Deployment)

•

2hec4list (lista de +erificación)

Entrevistas y $uestionarios

!as entre+istas y cuestionarios se emplean para reunir información pro+eniente de pers pe rson onas as o de gr grup upos os.. Du Dura rant nte e la en entr tre+ e+is ista ta,, el an anal alis ista ta con+ con+er ersa sa con con el encuestado encuest ado el cuesti cuestionario onario consist consiste e en una serie de pregun preguntas tas relacionad relacionadas as con +arios deencuestados un sistema. son usuarios de los sistemas e-istentes o usuarios 5or lo aspectos común, los en potencia del sist sistem ema a pro propu pues estto. En algu alguno noss ca caso sos, s, son son ge gere rent ntes es o em empl ple ead ados os que proporcionan datos para el sistema propuesto o que ser%n afectados por l. El -it -ito o de esta esta tcn tcnic ica, a, depe depend nde e de la ha hai ililida dad d de dell en entr tre+ e+is ista tado dorr y de su preparación para la misma.  %iste!as existentes

Esta tcnica consiste en analizar distintos sistemas ya desarrollados que estn relacionados con el sistema a ser construido. 5or un lado, podemos analizar las interfases de usuario, oser+ando el tipo de información que se maneja y cómo es manejada, por otro lado tamin es útil analizar las distintas salidas que los sistemas producen

 

(listados, consultas, etc.), porque siempre pueden surgir nue+as ideas sore la ase de estas.  &luvia de ideas '(rainstor!)

Este es un modelo que se usa para generar ideas. !a intención en su aplicación es la de generar la m%-ima cantidad posile de requerimientos para el sistema. :o hay que detenerse en pensar si la idea es o no del todo utilizale. !a intención de este ejercicio es generar, en una primera instancia, muchas ideas. !uego, se ir%n eliminando en ase a distintos criterios como, por ejemplo, ;caro;, ;impracticale;, ;imposile;, etc. !as reglas %sicas a seguir son&   !os participantes participantes deen pertenecer a distintas distintas discipli disciplinas nas y, preferent preferentemente emente,, deen tener mucha e-periencia. Esto trae aparejado la otención de una cantidad mayor de ideas creati+as.   2on+i 2on+iene ene suspende suspenderr el juicio cr#tic cr#tico o y se dee permit permitir ir la e+olució e+olución n de cada una de las ideas, porque sino se crea un amiente hostil que no alienta la generación de ideas.   5or m%s locas o sal+ajes que parezcan algunas ideas, no se las dee descartar, porqu po rque e lu lueg ego o de ma madur durada adass pr proa oal lem emen ente te se to torn rnen en en un re requ quer erim imie ient nto o sumamente útil.   0 +ec +eces es ocurr ocurre e que que una una id idea ea resul resulta ta en otra otra id idea ea,, y ot otras ras +ec +eces es po pode demos mos relacionar +arias ideas para generar una nue+a.   Escriir las ideas sin censura.  *rototipos

Durante la acti+idad de e-tracción de requerimientos, puede ocurrir que algunos requerimientos no estn demasiado claros o que no se est muy seguro de haer  entendido entend ido correctament correctamente e los requer requerimient imientos os otenidos otenidos hasta el momen momento, to, todo lo cual puede lle+ar a un desarrollo no eficaz del sistema final. Entonces, para +alidar los requerimientos hallados, se construyen prototipos. !os prototipos son simulaciones del posile producto, que luego son utilizados por el usuario final, permiti perm itind ndonos onos con conseg seguir uir una imp import ortant ante e ret retroal roalime imenta ntació ción n en cuanto cuanto a si el sistema dise