Romn Jimnez Maldonado.

UNIDAD 2 CAPTURA DE REQUISITOS

2.1.- Tipos de requisitos. En la ingeniera de sistemas, un requisito (del ingls requirement: requisito) es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniera de sistemas o la ingeniera de software. En la ingeniera clsica, los requisitos se utilizan como datos de entrada en la etapa de diseo del producto. Establecen qu debe hacer el sistema, pero no cmo hacerlo. La fase de captura, licitacin y registro de requisitos puede estar precedida por una fase de anlisis conceptual del proyecto. Esta fase puede dividirse en recoleccin de requisitos, anlisis de consistencia e integridad, definicin en trminos descriptivos para los desarrolladores y un esbozo de especificacin, previo al diseo completo. En ingeniera de sistemas existen tres tipos de requisitos. Un requisito funcional puede ser una descripcin de lo que un sistema debe hacer. Este tipo de requisito especfica algo que el sistema entregado debe ser capaz de realizar. Un requisito no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio sistema, y cmo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc. Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuacin a leyes o regulaciones aplicables al producto Una coleccin de requisitos describe las caractersticas o atributos del sistema deseado. Se omite el cmo debe lograrse su implementacin, ya que esto debe ser decidido en la etapa de diseo por los diseadores. En la ingeniera de software se aplica el mismo significado, slo que el nfasis est puesto en el propio software. Pseudorequerimientos: Son aquellos referidos al entorno donde ser instalado o implementado el sistema, que determinan en gran medida su desarrollo, pueden ser cuestiones como hardware y software. Caractersticas Los requisitos bien formulados deben satisfacer varias caractersticas. Si no lo hacen, deben ser reformulados hasta hacerlo. Necesario: Lo que pida un requisito debe ser necesario para el producto. No ambiguo: El texto debe ser claro, preciso y tener una nica interpretacin posible. Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo tcnico y especializado, aunque an as debe referenciar los aspectos importantes. Consistente: Ningn requisito debe entrar en conflicto con otro requisito diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requisitos debe ser consistente tambin. Completo: Los requisitos deben contener en s mismos toda la informacin necesaria, y no remitir a otras fuentes externas que los expliquen con ms detalle. Alcanzable: Un requisito debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles. Verificable: Se debe poder verificar con absoluta certeza, si el requisito fue satisfecho o no. Esta verificacin puede lograrse mediante inspeccin, anlisis, demostracin o testeo.

Romn Jimnez Maldonado. Estas caractersticas suelen ser subjetivas, es decir, no pueden ser calculadas de forma automtica por ningn sistema. Por ello, se tiende a medir otras mtricas o indicadores que s que pueden ser calculados de forma automtica y que, de algn modo, pueden sustituir o mapear con esta lista de caractersticas. 2.2.- Fuentes de Datos para el anlisis de sistemas. Existen bsicamente tres fuentes de hechos dentro y alrededor de la organizacin: 1. El sistema actual. Es verdaderamente raro que un analista tenga la oportunidad de desarrollar un sistema de informacin en donde anteriormente no haya existido ninguno. Con frecuencia se dedica una gran cantidad de tiempo investigando y documentando el sistema anterior, pero un anlisis de ventajas y desventajas puede ayudar a determinar cundo y qu tan extensamente debe estudiarse el sistema anterior. Las principales ventajas de analizar el sistema anterior: Eficacia del sistema actual. Ideas de diseo. Reconocimiento de recursos. Conocimiento de conversin. Punto de partida comn. Las principales desventajas de analizar el sistema anterior: Gastos Barreras Innecesarias. 2. Fuentes internas. La fuente ms importante de hechos de estudio a disposicin del analista es la gente. Los requerimientos de informacin pueden ser planteados mejor por los usuarios de la informacin. El papeleo describe la forma en que una organizacin est estructurada. 3. Fuentes externas. La exploracin de otros subsistemas de informacin dentro de la organizacin puede ser una fuente til de recopilacin de datos, procesamiento de datos o de ideas y tcnicas para el reporte de la informacin. 2.3 Seleccin y diseo de instrumentos para la recopilacin de Informacin. Recopilacin de datos: Deber dirigirse al registro de aquellos hechos que permitan conocer y analizar lo que realmente sucede en la unidad o tema que se investiga. Esto consiste en la recoleccin, sntesis, organizacin y comprensin de los datos que se requieren. Se conocen dos tipos de fuentes: 1. Primarias: que contienen informacin original no abreviada ni traducida. 2. Secundarias: obras de referencia que auxilian al proceso de investigacin.

Romn Jimnez Maldonado. Se conoce otra divisin que se conforma por las siguientes fuentes: -Documentales -De campo. FICHAS BIBLIOGRFICAS, DE TRABAJO Y HEMEROGRFICAS Las fuentes de recoleccin de datos son todos los registros de aquellos hechos que permitan conocer y analizar lo que realmente sucede en el tema que se investiga. Concluida la parte preparatoria de la investigacin se inicia la fase de recopilacin de datos. Para recabar la informacin existente sobre el tema, el investigador se auxilia de instrumentos como las fichas de trabajo; hay diversos tipos de fichas de trabajo como: Fichas de trabajo para fuentes documentales, fichas de trabajo de una revista, fichas de trabajo de un peridico, para investigacin de campo, para observacin, fichas bibliogrficas y hemerogrficas. ENCUESTA, CUESTIONARIO Y ENTREVISTA *Entrevista: esta herramienta consiste bsicamente en reunirse una o varias personas y cuestionarlas en forma adecuada para obtener informacin. *Cuestionario: estn constituidos por series de preguntas escritas, predefinidas, secuenciadas y separadas por captulos o temtica especfica. *Encuesta: la recoleccin de informacin se hace a travs de formularios, los cuales tienen aplicacin en aquellos problemas que se pueden investigar por mtodos de observacin, anlisis de fuentes documentales y dems sistemas de conocimiento. ANLISIS E INTERPRETACIN DE INFORMACIN La interpretacin de los resultados de la indagacin lleva inmediatamente a la solucin. El anlisis del instrumento de recoleccin de informacin de campo (encuesta), fue utilizando el anlisis individual de preguntas que se realiza con base en los porcentajes que alcanzan las distintas respuestas de cada pregunta. Para llevar a cabo este tipo de anlisis se dise una forma donde se tabulan las respuestas en base a la cantidad de personas que contestaron cada respuesta y el porcentaje que representa del total de la muestra. REDACCIN Y PRESENTACIN DEL INFORME El objetivo del informe es presentar a los lectores el proceso que se realiz para presentar una solucin al problema planteado, para lo cual es necesario hacer la presentacin del problema, los mtodos empleados para su estudio, los resultados obtenidos, las conclusiones a las que se llegaron y las recomendaciones en base a estas. Con respecto a la estructura del informe, sta es sencilla y sigue fielmente los pasos fundamentales del diseo de la investigacin, ya que el informe debe ser la respuesta a lo planteado por el diseo de investigacin. 2.4 Captura de requisitos candidatos. Enumerar los requisitos candidatos La lista de caractersticas deseadas del sistema constituyen los requisitos candidatos.De cada caracterstica se registra: Nombre corto Descripcin Estado (propuesto, aprobado, incluido, o validado) Coste estimado de implementacin (en trmino de tipos de recursos y horas-hombre) Prioridad (crtico, importante, o secundario)

Romn Jimnez Maldonado. Nivel de riesgo asociado a la implementacin de la caracterstica (crtico, significativo, ordinario). Estos valores se utilizan para estimar el tamao del proyecto y decidir cmo dividirlo en secuencia de iteraciones. La prioridad y nivel de riesgo asociados por ejemplo, se utiliza para decidir en qu iteracin se implementar la caracterstica. 2.5 Seleccin de metodologa de desarrollo. La buena seleccin metodologas; y tambin el buen desarrollo software; es producto o resultado de una buena seleccin de estndares y normas para trabajar mediante una Metodologa de Desarrollo de Software fija. En la actualidad, la experiencia en el rea de la Informtica me ha permitido comprender que el diseo y el desarrollo de software no es una tarea sencilla, por mucho tiempo esta labor se ha llevado adelante sin una metodologa definida. Sabemos por conocimiento puramente profesional que las metodologas tradicionales se basan en normas provenientes de estndares seguidos por el entorno de desarrollo; con una fuerte y cierta resistencia a los cambios donde todo se encuentra impuestas externamente y poseen un proceso muy controlado, con numerosas normas. Pero eso no es todo, dichas metodologas tradicionales necesitan un contrato prefijado donde el cliente interacta con el equipo de desarrollo mediante reuniones con grupos grandes los cuales requieren de ms artefactos y el resultado final se basa en la arquitectura del software es esencial. Las metodologas agiles son todo lo contario. Se basan en heursticas provenientes de prcticas de produccin de cdigo; total y completamente preparados para cambios durante el proyecto las cuales son impuestas internamente por el equipo con proceso menos controlado, con pocos principios. As como tambin con un contrato flexible e incluso inexistente, donde el cliente es parte del desarrollo y los grupos son pequeos por lo que se incluyen pocos artefactos y existe una menor nfasis en la arquitectura del software. Todo lo anteriormente mencionado, me ayuda a concluir algunas cosas. Es claro que antes de desarrollar un producto software, necesitamos comprender la visin del producto, la cual podemos obtenerla en base a la vinculacin con el cliente, y un previo establecimiento del modelo de ciclo de vida del software, as como la gestin de los requisitos, el plan de desarrollo y tambin la parte de la integracin del proyecto. Esto nos permitir tener un amplio panorama donde podremos ver las medidas de progreso del proyecto, as como las mtricas para evaluar la calidad, las maneras de medir el riesgo, y saber con ello como gestionar los cambios y as establecer una lnea de meta; lo que nos ayuda para poder seleccionar una metodologa de desarrollo de software; pues al ver lo que realmente necesitamos, podremos ver que es lo que nos proporciona una metodologa tradicional y una gil, independientemente de cul seleccionemos para llevar a cabo el desarrollo de nuestro software, ya que tenemos variedades de metodologas tanto tradicionales como agiles. Lo que se debe tener claro es que, para tener una seleccin optima de metodologa, este aspecto no ha sido tratado de manera adecuada, sobre todo en el mbito de las metodologas tradicionales, y en el caso de las giles no existe un criterio unificado para poder llevar una debida seleccin de la metodologa a tratar para poder desarrollar un software de calidad. Ahora bien por lo anteriormente mencionado podemos tener una gua de orientacin, o una formulacin inicial para la deba seleccin, el cual puede llenar las expectativas base del cliente, que es un coste del desarrollo inicial relativamente bajo, con un software fcil de mantener, portable a nuevo hardware y sobre todo que haga lo que el cliente quiere, ya que en base a la informacin existente a la fecha y a la experiencia personal, puedo decir que la formulacin para poder seleccionar una buena metodologa se basa en una buena

Romn Jimnez Maldonado. seleccin por criterios de expertos y por conocimiento de desarrollo en la rama de los analistas y diseadores que nos guie a la pura necesidad del cliente y la metodologa que se acople a dicha necesidad. 2.6 Modelo del negocio. El modelo del negocio forma parte del flujo de trabajo clave para lograr un desarrollo exitoso del servicio, ya que el mismo describe el curso de los procesos que sern objeto de automatizacin, y establece una buena comunicacin entre los desarrolladores, los clientes y el usuario final. Dentro de los pasos del modelo del negocio se encuentran: capturar y definir los procesos de negocio de la organizacin, realizar el modelo de casos de uso del negocio que identifique los actores y casos de uso asociados y el modelo de objetos del negocio compuesto por trabajadores y entidades de este, todos ellos, bajo el estudio, tarea crucial que define los lmites del proceso de modelado posterior. El proceso de negocio es un grupo de tareas relacionadas de manera lgica que se llevan a cabo en determinada secuencia, y producen o manipulan una coleccin de datos empleando recursos de la organizacin para dar resultados que apoyan sus objetivos. Actualmente en el CENEX las solicitudes de los clientes se hacen de forma manual, el cliente llega a la entidad o se comunica telefnicamente y ah lo atiende cualquiera del personal de la entidad, se realiza la solicitud del servicio que el cliente desee contratar, despus se hace una valoracin si es factible o no realizar el trabajo solicitado y si existen los productos disponibles en el almacn. Esto es un trabajo un poco complejo y molesto por lo que constituye una forma de perdida de tiempo a los usuarios de dicha entidad y por parte de los clientes, ya que tienen que esperar a que se apruebe la solicitud y despus esperar a que le manden la oferta de acuerdo a su solicitud, para mas tarde si est de acuerdo redactar el contrato y que el mismo lo firme para por ltimo se realice el trabajo solicitado. Solicitar Servicio. Confeccionar Oferta. Confeccionar Contrato. Reglas del Negocio. Despus de identificar el proceso de negocio se definen las siguientes reglas del negocio: Cualquier usuario de la entidad puede confeccionar la solicitud del cliente. Cada Solicitud debe tener un cdigo que se conforma por un consecutivo ms el ao en curso, siempre reinicindose con el inicio de un nuevo ao. Cada registro de revisin de solicitud, oferta y contrato (es una sola planilla) debe tener un nmero y a su vez el cdigo del contrato al que pertenezca. El cliente deber revisar la oferta realizada por parte de la empresa, si no es de su conveniencia se lo comunica al Jefe de la Divisin de Servicios, se analizarn las causas y se toman decisiones. Cuando el Jefe de la Divisin de Servicios realiza cualquier contrato debe confeccionar un documento que es entregado al cliente, quien a su vez lo firma. El Jefe de la Divisin de Servicios deber informar al cliente si se realizar algn cambio en el servicio solicitado. Para que el contrato entre en vigor el cliente deber estar de acuerdo con l y haberlo firmado. Para todo contrato de servicio el cliente debe pagar un abonado al terminar el tiempo del contrato.

Romn Jimnez Maldonado. El Jefe de la Divisin de Servicios es el encargado de entregar mensualmente a la empresa la informacin de la prestacin de los servicios solicitados. El Jefe de la Divisin de Servicios es el encargado de entregar mensualmente a la empresa la informacin de la prestacin de los servicios realizados. 2.7 Modelo del dominio. Un Modelo de Dominio es un artefacto de la disciplina de anlisis, construido con las reglas de UML durante la fase de concepcin, presentado como uno o ms diagramas de clases y que contiene, no conceptos propios de un sistema sino de la propia realidad fsica. Los modelos de dominio pueden utilizarse para capturar y expresar el entendimiento ganado en un rea bajo anlisis como paso previo al diseo de un sistema, ya sea de software o de otro tipo. Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el analista como un medio para comprender el sector industrial o de negocios al cual el sistema va a servir. 2.8 Validacin de requerimientos. La validacin de requisitos tiene como misin demostrar que la definicin de los requisitos define realmente el sistema que el usuario necesita o el cliente desea (Lowe & Hall, 1999). El proceso de validacin de requisitos comprende actividades que generalmente se realizan una vez obtenida una primera versin de la documentacin de requisitos. Los requisitos una vez definidos necesitan ser validados.Es necesario asegurar que el anlisis realizado y los resultados obtenidos de la etapa de definicin de requisitos son correctos. Pocas son las propuestas existentes que ofrecen tcnicas para la realizacin de la validacin y muchas de ellas consisten en revisar los modelos obtenidos en la definicin de requisitos con el usuario para detectar errores o inconsistencias. El proceso de validacin de requisitos debe realizarse o de lo contrario se corre el riesgo de implementar una mala especificacin, con el costo que eso conlleva Los parmetros a comprobar por la especificacin son: 1. Validez: No basta con preguntar a un usuario, todos los potenciales usuarios pueden tener puntos de vista distintos y necesitar otros requisitos. 2. Consistencia: No debe haber contradicciones entre unos requisitos y otros. 3. Completitud: Deben estar todos los requisitos. Esto es imposible en un desarrollo iterativo, pero, al menos, deben estar disponibles todos los requisitos de la iteracin en curso. 4. Realismo: Se pueden implementar con la tecnologa actual. 5. Verificabilidad: Tiene que existir alguna forma de comprobar que cada requisito se cumple.

La validacin en el proceso de requisitos La actividad de validacin tiene como entrada el documento de requisitos, los estndares relacionados y el conocimiento de la organizacin, y como salida se obtiene una lista de problemas y una lista de acciones recomendadas.

Romn Jimnez Maldonado. Tcnicas de Validacin de Requisitos Reviews o Walk-throughs: Est tcnica consiste en la lectura y correccin de la completa documentacin o modelado de la definicin de requisitos. Con ello solamente se puede validar la correcta interpretacin de la informacin transmitida. Ms difcil es verificar consistencia de la documentacin o informacin faltante. Auditoras: La revisin de la documentacin con esta tcnica consiste en un chequeo de los resultados contra una checklist predefinida o definida a comienzos del proceso, es decir slo una muestra es revisada. Matrices de trazabilidad: Esta tcnica consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo (Durn, Bernldez, Ruz &Toro, 1999). Es necesario ir viendo qu objetivos cubre cada requisito, de esta forma se podrn detectar inconsistencias u objetivos no cubiertos. Prototipos: Algunas propuestas se basan en obtener de la definicin de requisitos prototipos que, sin tener la totalidad de la funcionalidad del sistema, permitan al usuario hacerse una idea de la estructura de la interfaz del sistema con el usuario (Olsina,1999). Esta tcnica tiene el problema de que el usuario debe entender que lo que est viendo es un prototipo y no el sistema final. 2.9 Definicin de propuesta de solucin. Esta fase se ocupa de la reunin y estudio a detalle de los datos del sistema en operacin y la especificacin de los nuevos requerimientos del sistema a desarrollar. Concluye en general con un documento que recoge el resultado del anlisis. Con la recopilacin de datos se completan los datos resultantes de la fase 1, aadiendo detalles sobre el sistema actual. Son medios comunes para acometer tal recopilacin: Las entrevistas, cuestionarios, encuestas a usuarios finales, as como tambin, las consultas a documentos y manuales que contengan lineamientos de funcionamiento o normas de procedimientos de operacin. Existen varias tcnicas y herramientas tiles para el anlisis de datos. Una de estas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones de la organizacin de manera grfica. Estos diagramas sirven para desarrollar el llamado diccionario de datos, el cual contiene la definicin de los datos usados en el sistema, as como sus caractersticas de tipo, tamao, limitaciones o especificaciones especiales. La documentacin de la etapa de anlisis recoge la descripcin del sistema de informacin en uso, los requerimientos para el nuevo sistema y un probable plan de desarrollo en un reporte dirigido a la gerencia. Este reporte permite tomar la decisin de proseguir o no con el proyecto. El aspecto ms importante de cualquier propuesta es identificar y comprender el problema que el cliente busca resolver. Uno de los puntos del desarrollo de una propuesta de solucin es presentar una nocin propia del problema, as como la propuesta para resolverlo, con el fin de convencer al cliente de que tal propuesta es la mejor. Para ello, se presentara lo que implica una descripcin de los problemas: 1.- La Naturaleza del problema. 2.- La historia del problema. 3.- Las caractersticas del problema. 4.- Las soluciones alternas consideradas. 5.- La solucin o la tcnica seleccionada