Professional Documents
Culture Documents
Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Describe las interacciones entre el sistema y su entorno (usuarios u otros sistemas) sin tener en cuenta cuestiones de implementacin. Son de un diseo fsico, son proporcionados por el usuario. Indican todas las funciones que el sistema realizar. Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema, sern de un diseo lgico, no son proporcionados por el usuario hay que suponerlos, describe aspectos del sistema visibles por el usuario que no se relacionan en forma directa con el comportamiento funcional del sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares, restricciones en el tiempo de respuesta, precisin de los resultados, etc. Sirven para limitar el sistema.
* Conciso:
* Especificado por escrito: Como todo contrato o acuerdo entre dos partes. * Completo: * Consistente: * No ambiguo: *Verificable:
Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Un requerimiento es consistente si no es contradictorio con otro requerimiento. Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector. Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas.
Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros. Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.
Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeo, etc.). Mejora la comunicacin entre equipos: La especificacin de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no ser exitoso. Evita rechazos de usuarios finales: La ingeniera de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.
Punto de vista de los clientes Muchos sistemas tienen diferentes tipos de clientes. Cada grupo de clientes tiene necesidades diferentes y, diferentes requerimientos tienen diferentes grados de importancia para ellos. Por otro lado, escasas veces tenemos que los clientes son los mismos usuarios; trayendo como consecuencia que los clientes soliciten procesos que causan conflictos con los solicitados por el usuario. Diferentes puntos de vistas tambin pueden tener consecuencias negativas, tales como datos redundantes, inconsistentes y ambiguos. El tamao y complejidad de los requerimientos ocasiona desentendimiento, dificultad para enfocarse en un solo aspecto a la vez y dificultad para visualizar relaciones existentes entre requerimientos.
Barreras de comunicacin La ingeniera de requerimientos depende de una intensa comunicacin entre clientes y analistas de
requerimientos; sin embargo, existen problemas que no pueden ser resueltos mediante la comunicacin.
Para remediar esto, se deben abordar nuevas tcnicas operacionales que ayuden a superar estas barreras y as ganar experiencia dentro del marco del sistema propuesto.
Pocos sistemas son construidos desde cero. En la prctica, los proyectos se derivan de sistemas ya existentes. Por lo tanto, los analistas de requerimientos deben comprender esos sistemas, que por lo general son una integracin de componentes de varios proveedores. Para encontrar una solucin a problemas de este tipo, es muy importante hacer planeamientos entre los requerimientos y la fase de diseo; esto minimizar la cantidad de fallas directas en el cdigo.
Documentacin de requerimientos
Los documentos de ingeniera de requerimientos son largos. La mayora estn compuestos de cientos o miles de pginas; cada pgina contiene muchos detalles que pueden tener efectos profundos en el resto del sistema. Normalmente, las personas se encuentran con dificultades para comprender documentos de este tamao, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de especificacin de gran tamao, pues difcilmente una persona puede memorizar los detalles del documento. Esto causa problemas y errores que no son detectados hasta despus de haberse construido el sistema.
A continuacin se explicar cada una de ellas, presentndolas en el orden en que deben ser aplicadas para un nuevo proyecto.
Antes de describir qu pasos deben cumplirse en esta actividad, debemos tener una definicin clara
"Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean" . Aqu vemos nuevamente la importancia que tiene una buena comunicacin entre desarrolladores y clientes; de esta comunicacin con el cliente depende que entendamos sus necesidades. A travs de la definicin de problema, podemos ver entonces que la actividad de "Anlisis del Problema" tiene por objetivo que se comprendan los problemas del negocio, se evalen las necesidades iniciales de todos los involucrados en el proyecto y que se proponga una solucin de alto nivel para resolverlo. Durante el anlisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio. Estos pasos son los siguientes:
1. Comprender el problema que se est resolviendo : Es importante determinar quin tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista.
Veamos la siguiente necesidad: "El cliente se queja mucho por la enorme fila que debe formar
para realizar una transaccin bancaria". Perspectiva del cliente = Prdida de tiempo Perspectiva del banco = Posible prdida de clientes
Como puede verse, mltiples soluciones aplican para el mismo problema, sin embargo, slo una de ellas ser la ms factible. Las soluciones iniciales, deben ser definidas tomando en cuenta tanto la perspectiva tcnica como la del negocio.
2. Construir un vocabulario comn: Debe confeccionarse un glosario en dnde se definan todos los trminos que tengan significados comunes (sinnimos) y que sern utilizados durante el proyecto. Por ejemplo, las palabras pignoracin, retencin, valor en suspenso, custodia, garanta, entre otras, son utilizadas para referirse a la accin de dejar una prenda (puede ser cualquier forma de ahorros) como garanta de una deuda adquirida.
La creacin de un glosario es sumamente beneficiosa ya que reduce los trminos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunin estn en la misma pgina, adems de ser reutilizable en otros proyectos.
3. Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas a medida que avanza el proyecto. Las necesidades de cada afectado, son
Elabor: L.I. Araceli Soledad Domnguez Flores Ver.EJ2011m 6
discutidas y sometidas a debate durante de ingeniera de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la informacin necesaria para especificar un sistema adecuado. Para saber quines son las personas, departamentos, organizaciones internas o externas que se vern afectadas por el sistema, debemos realizar algunas preguntas.
Quin usar el sistema que se va a construir? Quin desarrollar el sistema? Quin probar el sistema? Quin documentar el sistema? Quin dar soporte al sistema? Quin dar mantenimiento al sistema? Quin mercadear, vender, y/o distribuir el sistema? Quin se beneficiar por el retorno de inversin del sistema?
Como vemos, debe conocerse la opinin de todo aqul que de una u otra forma est involucrado con el sistema, ya sea directa o indirectamente.
4. Definir los lmites y restricciones del sistema: Este punto es importante pues debemos saber lo que se est construyendo, y lo que no se est construyendo, para as entender la estrategia del producto a corto y largo plazo. Debe determinarse cualquier restriccin ambiental, presupuestaria, de tiempo, tcnica y de factibilidad que limite el sistema que se va a construir. 2. ESTUDIO DE VIABILIDAD
Contribuye a los objetivos de la organizacin? NO TIENE VALOR EN EL NEGOCIO. Se puede implementar con tecnologa actual dentro de costo y tiempo. Puede integrarse a otros existentes en la organizacin.
ACTIVIDAD
Puntos de Vista: Toma en cuenta la existencia de varias perspectivas y provee de un marco de trabajo para descubrir conflictos. Realizar Entrevistas. Establecer Escenario: Son descripciones de ejemplos de las sesiones de interaccin con el sistema. Inicia con un bosquejo y durante la obtencin de agregan detalles. Casos de Uso Etnografa: Tcnica organizacionales. de observacin para entender requerimientos sociales y
Documentacin: Se genera la Especificacin de Requisitos del Software (SRS) La especificacin de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripcin completa de las necesidades y funcionalidades del sistema que ser desarrollado; describe el alcance del sistema y la manera como har sus funciones, definiendo los requerimientos funcionales y los no funcionales. En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra informacin que sirva de soporte y gua para fases posteriores. Es importante destacar que la especificacin de requisitos es el resultado final de las actividades de anlisis y evaluacin de requerimientos; este documento resultante ser utilizado como fuente bsica de comunicacin entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementacin del sistema. Los clientes y usuarios utilizan la SRS para comparar si lo que se est proponiendo, coincide con las necesidades de la empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El personal de pruebas elaborar las pruebas funcionales y de sistemas en base a este documento. Para el administrador del proyecto sirve como referencia y control de la evolucin del sistema. La SRS posee las mismas caractersticas de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada caracterstica de la SRS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere verificable, cada requerimiento definido en ella debe ser verificable; para que una SRS se considere modificable, cada requerimiento debe ser modificable y as sucesivamente. Las caractersticas de la SRS son verificadas en la actividad de Validacin. La estandarizacin de la SRS es fundamental pues ayudar, entre otras cosas, a facilitar la lectura y escritura de la misma. Ser un documento familiar para todos los involucrados, adems de asegurar que se cubren todos los tpicos importantes. Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia plantilla. En el anexo #1 se muestra una plantilla completa para la especificacin de requisitos.
La validacin es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; adems revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes.
En este punto es necesario recordar que la SRS debe estar libre de errores, por lo tanto, la validacin garantiza que todos los requerimientos presentes en el documento de especificacin sigan los estndares de calidad. No debe confundirse la actividad de evaluacin de requerimientos con la validacin de requerimientos. La evaluacin verifica las propiedades de cada requerimiento, mientras que la validacin revisa el cumplimiento de las caractersticas de la especificacin de requisitos. Durante la actividad de validacin pueden hacerse preguntas en base a cada una de las caractersticas que se desean revisar. A continuacin se presentan varios ejemplos:
Estn incluidas todas las funciones requeridas por el cliente? (completa) Existen conflictos en los requerimientos? (consistencia) Tiene alguno de los requerimientos ms de una interpretacin? (no ambigua) Est cada requerimiento claramente representado? (entendible) Pueden los requerimientos ser implementados con la tecnologa y el presupuesto disponible? (factible) Est la SRS escrita en un lenguaje apropiado? (clara) Existe facilidad para hacer cambios en los requerimientos? (modificable) Est claramente definido el origen de cada requisito? (rastreable) Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable)
La validacin de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado.
5. ADMINISTRACIN DE REQUERIMIENTOS
Comunidad de usuarios diversa. Los requerimientos finales son comnmente un trmino medio. Quien paga raramente es quien usa el sistema. Entorno de negocios y tcnico cambiante.
Un proceso formal para que todos los cambios propuestos sean tratados de forma consistente.
Siempre existe la tentacin de hacer un cambio urgente al sistema y en retrospectiva modificar el documento de requerimientos. Esto conduce a un desfase e inconsistencias.
Usuario final:
Son las personas que usarn el sistema desarrollado. Ellos estn relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; estn familiarizados con los procesos especficos que debe realizar el software, dentro de los parmetros de su ambiente laboral. Sern quienes utilicen las interfaces y los manuales de usuario. Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde ser empleado el software desarrollado. Ellos proporcionan al equipo tcnico los detalles y requerimientos de las interfaces del sistema. Para proyectos que requieran un mantenimiento eventual, stas personas son las responsables de la administracin de cambios, de la implementacin y resolucin de anomalas. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado. Son los responsables del desarrollo del producto en s; ellos interactan directamente con el cliente. Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente. Administradores de proyecto, documentadores, diseadores de base de datos, entre otros.
Usuario Lder:
Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser:
Los requerimientos del usuario para un sistema describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento tcnico. nicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las caractersticas de diseo del sistema. Por consiguiente los
Elabor: L.I. Araceli Soledad Domnguez Flores Ver.EJ2011m 10
requerimientos del usuario no se deben definir utilizando un modelo de implementacin. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos y sencillos. Sin embargo pueden surgir diversos problemas cuando se redactan en lenguaje natural: 1. Falta claridad. Algunas veces es difcil utilizar el lenguaje en forma precisa y no ambigua sin detallar el documento y hacerlo difcil de leer. 2. Confusin de requerimientos. No se distinguen claramente los requerimientos funcionales y no funcionales, las metas del sistema y la informacin para el diseo. 3. Conjuncin de requerimientos. Diversos requerimientos diferentes se expresan de forma conjunta como un nico requerimiento.
Se debe asegurar que las caractersticas del sistema cumplan con los requerimientos del usuario.
Realiza en forma apropiada los procedimientos correctos. Presenta informacin e instrucciones en forma aceptable y efectiva. Produce resultados exactos. Proporciona aceptables. una interfaz y mtodo de interaccin
Se dice que un sistema de informacin satisface las necesidades de los usuarios si:
FUENTES DE INFORMACIN Senn, James A., Anlisis y diseo de sistemas. Pressman Roger S., Ingeniera de Software
http://www.opensolutions.com.py/ggonzalez/fpuna/is2/files/01_INGENIERIA_DE_REQUERIMIENTOS.pdf www.monografias.com/trabajos6/resof/resof.shtml http://cs.uns.edu.ar/ads/data/apuntes/ADS-mod%2005.pdf
11