You are on page 1of 11

I. T. D.

Materia: Fundamentos de Ingeniera de software

Unidad II Ingeniera de Requisitos

FUNDAMENTOS DE INGENIERIA DE SOFTWARE


UNIDAD II. Ingeniera de Requisitos.
Introduccin A travs de los aos se ha podido constatar que los requerimientos o requisitos son la pieza fundamental en un proyecto de desarrollo de software, ya que marcan el punto de partida para actividades como la planeacin, bsicamente en lo que se refiere a las estimaciones de tiempos y costos, as como la definicin de recursos necesarios y la elaboracin de cronogramas que ser uno de los principales mecanismos de control con los que se contar durante la etapa de desarrollo. Adems la especificacin de requerimientos es la base que permite verificar si se alcanzaron o no los objetivos establecidos en el proyecto ya que estos son un reflejo detallado de las necesidades de clientes o usuarios del sistema y es contra lo que se va a estar verificando si se estn cumpliendo las metas trazadas. Es muy frecuente escuchar entre los conocedores del desarrollo de software (programas de computadoras), que un gran nmero de los proyectos de software fracasan por no realizar una adecuada definicin, especificacin, y administracin de los requerimientos. Dentro de esa mala administracin se pueden encontrar factores como la falta de participacin del usuario, requerimientos incompletos y el mal manejo del cambio a los requerimientos.

La ingeniera de requerimientos y sus principales actividades Qu son Requerimientos?


Normalmente, un tema de la Ingeniera de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, a continuacin se presenta la definicin que aparece en el glosario de la IEEE .
(1) Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (Std 610.12-1900, IEEE: 62) (2) Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. (Std 610.12-1900, IEEE: 62) (3) Una representacin documentada de una condicin o capacidad como en (1) o (2). (Std 610.12-1900, IEEE: 62) (4) Un requerimiento es simplemente una declaracin abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restriccin de ste. (Somerville, 2005: 108)

Los requerimientos pueden dividirse en requerimientos funcionales y requerimientos no funcionales.

Elabor: L.I. Araceli Soledad Domnguez Flores Ver.EJ2011m

I. T. D. Materia: Fundamentos de Ingeniera de software

Unidad II Ingeniera de Requisitos

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.

Caractersticas de los requerimientos


Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, debe presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes: * Necesario:
Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

* 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.

Dificultades para definir los requerimientos


Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difcil de manejar.

Elabor: L.I. Araceli Soledad Domnguez Flores Ver.EJ2011m

I. T. D. Materia: Fundamentos de Ingeniera de software

Unidad II Ingeniera de Requisitos

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.

Ingeniera de Requerimientos vs. Administracin de Requerimientos


El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniera de Requerimientos. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software correcta y completa. A continuacin se darn algunas definiciones para Ingeniera de Requerimientos.
"Ingeniera de Requerimientos es la disciplina para desarrollar una especificacin completa, consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucradas y en dnde se describen las funciones que realizar el sistema" Boehm 1979. "Ingeniera de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987. " Ingeniera de Requerimientos es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinacin de mtodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987. "Ingeniera de requerimientos es un enfoque sistmico para recolectar, organizar y documentar los requerimientos del sistema; es tambin el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software.

Importancia de la Ingeniera de Requerimientos


Los principales beneficios que se obtienen de la Ingeniera de Requerimientos son: Permite gestionar las necesidades del proyecto en forma estructurada : Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, as como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimacin de costos, tiempo y recursos necesarios.

Elabor: L.I. Araceli Soledad Domnguez Flores Ver.EJ2011m

I. T. D. Materia: Fundamentos de Ingeniera de software

Unidad II Ingeniera de Requisitos

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.

Puntos a considerar durante la Ingeniera de Requerimientos


Aunque la lista no est completa, se enumeran los puntos ms importantes: Objetivos del negocio y ambiente de trabajo Aunque los objetivos del negocio estn definidos frecuentemente en trminos generales, son usados para descomponer el trabajo en tareas especficas. En ciertas situaciones IR se enfoca en la descripcin de las tareas y en el anlisis de sistemas similares. Esta informacin proporciona la base para especificar el sistema que ser construido; aunque frecuentemente se aadan al sistema tareas que no encajan con el ambiente de trabajo planificado. El nuevo sistema cambiar el ambiente de trabajo, sin embargo, es muy difcil anticipar los efectos actuales sobre la organizacin. Los cambios no ocurren solamente cuando un nuevo software es implementado y puesto en produccin; tambin ocurren cuando cambia el ambiente que lo rodea (nuevas soluciones a problemas, nuevo equipo para instalar, etc.). La necesidad de cambio es sustentada por el enorme costo de mantenimiento; aunque existen diversas razones que dificultan el mantenimiento del software, la falta de atencin a la IR es la principal. Frecuentemente la especificacin inicial es tambin la especificacin final, lo que obstaculiza la comunicacin y el proceso de aprendizaje de las personas involucradas; esta es una de las razones por las cuales existen sistemas inadecuados.

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.

Elabor: L.I. Araceli Soledad Domnguez Flores Ver.EJ2011m

I. T. D. Materia: Fundamentos de Ingeniera de software

Unidad II Ingeniera de Requisitos

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.

Evolucin e integracin del sistema

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.

Actividades de la Ingeniera de Requerimientos


En el proceso de IR son esenciales diversas actividades. En este documento sern presentadas secuencialmente, sin embargo, en un proceso de ingeniera de requerimientos efectivo, estas actividades son aplicadas de manera continua y en orden variado. Dependiendo del tamao del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo, las actividades de la IR varan tanto en nmero como en nombres. A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades podemos identificar y extraer cinco actividades principales que son:
1. 2. 3. 4. 5. ANLISIS DEL PROBLEMA ESTUDIO DE VIABILIDAD OBTENCIN Y ANLISIS DE REQUERIMIENTOS VALIDACIN DE REQUERIMIENTOS ADMINISTRACIN DE REQUERIMIENTOS

A continuacin se explicar cada una de ellas, presentndolas en el orden en que deben ser aplicadas para un nuevo proyecto.

1. ANLISIS DEL PROBLEMA


El

objetivo de esta actividad es entender las verdaderas necesidades del negocio.

Antes de describir qu pasos deben cumplirse en esta actividad, debemos tener una definicin clara

Elabor: L.I. Araceli Soledad Domnguez Flores Ver.EJ2011m

I. T. D. Materia: Fundamentos de Ingeniera de software

Unidad II Ingeniera de Requisitos

del trmino "Problema".

"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

Posibles soluciones pueden ser:


Determinar por qu demoran los cajeros, Colocar una nueva caja (implica contratacin de nuevos cajeros), Abrir una nueva sucursal (involucra personal nuevo y estudio de mercado), Realizar transacciones por otros medios (telfono, internet, mediante cajeros automticos, autobancos, etc).

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

I. T. D. Materia: Fundamentos de Ingeniera de software

Unidad II Ingeniera de Requisitos

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

Un estudio de viabilidad es a corto plazo y est orientado a resolver si el sistema:


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.

3. OBTENCIN Y ANLISIS DE REQUERIMIENTOS

ACTIVIDAD

Actividades del proceso:


Descubrimiento de requerimientos

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

Clasificacin y organizacin de requerimientos. Ordenacin por prioridades y negociacin.

Elabor: L.I. Araceli Soledad Domnguez Flores Ver.EJ2011m

I. T. D. Materia: Fundamentos de Ingeniera de software

Unidad II Ingeniera de Requisitos

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.

Otras tcnicas: _ Anlisis estructurado _ Anlisis OO _ Prototipos


4. VALIDACIN DE REQUERIMIENTOS

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.

Elabor: L.I. Araceli Soledad Domnguez Flores Ver.EJ2011m

I. T. D. Materia: Fundamentos de Ingeniera de software

Unidad II Ingeniera de Requisitos

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

La Administracin de requerimientos es necesaria debido a alguna de las siguientes razones:


Los requerimientos de sistemas grandes son siempre cambiantes. Los sistemas grandes usualmente se desarrollan para mejorar el status quo. Surgirn nuevos requerimientos debido a:

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.

Etapas de la Administracin de Requerimientos:


Anlisis del problema y especificacin del cambio. Anlisis del cambio y costo. Implementacin del cambio.

Elabor: L.I. Araceli Soledad Domnguez Flores Ver.EJ2011m

I. T. D. Materia: Fundamentos de Ingeniera de software

Unidad II Ingeniera de Requisitos

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.

Personal involucrado en la Ingeniera de Requerimientos


Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan roles especficos dentro de la planificacin del proyecto; el conocimiento de cada papel desempeado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR. No conocer estos intereses puede ocasionar una comunicacin poco efectiva entre clientes y desarrolladores, que a la vez traera impactos negativos tanto en tiempo como en presupuesto. Los roles ms importantes pueden clasificarse como sigue:

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:

Personal de Mantenimiento: Analistas y programadores: Personal de pruebas:

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

I. T. D. Materia: Fundamentos de Ingeniera de software

Unidad II Ingeniera de Requisitos

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:

Es percibido por los usuarios como un sistema confiable.

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

Elabor: L.I. Araceli Soledad Domnguez Flores Ver.EJ2011m

11

You might also like