• Author / Uploaded
• Karla Herrera

Citation preview

UNIVERSIDAD NACIONAL DE LOJA

ENSA-CIS-UNL

Área de la Energía, las Industrias y los Recursos Naturales No Renovables ______________________________________________________________________ CARRERA DE INGENIERÍA EN SISTEMAS

EJERCICIOS DEL CAPITULO 6: REQUERIMIENTOS DE SOFTWARE

Integrantes:  Marjorie Chinchay Cuenca  Karla Herrera Paredes  Elivar Largo Ríos  Franklin Michay  Gabriela Rodríguez

Paralelo:

Fecha: Docente:

B

24 de noviembre de 2013

Ing. Roberto Jácome

LOJA-ECUADOR 2013 EJERCICIOS DEL CAPITULO 6: REQUERIMIENTOS DE SOFTWARE 6.1 Identifique y comente brevemente cuatro tipos de requerimientos que se pueden definir para un sistema informático.  Requerimientos del Usuario: Son declaraciones de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar, son declaraciones en lenguaje natural.  Requerimientos Funcionales: Son declaraciones de los servicios que debe proporcionar el sistema, son los que deben cumplir específicamente una tarea dentro del sistema y lo que debe hacer.  Requerimientos no Funcionales: Son restricciones de los servicios o funciones ofrecidas por el sistema, funciones agregadas al sistema más no fundamentales.  Requerimientos del Sistema: explica las funciones y tareas específicas que cumple el sistema y las limitaciones del mismo según los requerimientos del usuario y el software dado por el programador. 6.2 Comente los problemas de la utilización del lenguaje natural para definir los requerimientos del usuario y del sistema, y muestre, utilizando pequeños ejemplos, como el estructurar el lenguaje natural en formularios puede ayudar a evitar algunas de estas dificultades. La utilización de lenguaje natural ayuda a tener un buen contacto con el usuario y tener en muy claro lo que el necesita, el problema vendría en que cada programador lo podría tomar a su propia interpretación. A esto le podemos sumar algunas otras dificultades:  Falta de claridad: Algunas veces es difícil utilizar el lenguaje de forma precisa o inexacta, sin hacer el documento poco conciso y difícil de leer.  Confusión de requerimientos: no se distinguen claramente los requerimientos funcionales y no funcionales, las metas del sistema y la información para el diseño  Conjunción de requerimientos: diversos requerimientos diferentes se puede expresar de forma conjunta como un único requerimiento.

Para la redacción de los requerimientos del sistema no se debería utilizar el lenguaje natural ya que estos están dados por los desarrolladores y no por el usuario, entonces para estos se deberían especificar en un lenguaje técnico. En cuanto a la utilización de formularios estos ayudan al programador a saber cuáles son los datos de entrada y los datos que se obtendrán a la salida así como todos los eventos y sucesos relacionados para que se den los datos de salida. 6.3 Descubra las ambigüedades u omisiones en la siguiente declaración de requerimientos de una parte de un sistema expendedor de billetes. Un sistema automático de expedición de billetes vende billetes de tren. Los usuarios seleccionan su destino e introducen una tarjeta de crédito. Cuando el usuario presiona el botón de inicio, se activa un menú que muestra los posibles destinos, junto con un mensaje para el usuario que le indica que seleccione el destino. Se comprueba su validez y entonces se le pide a los usuarios que introduzcan su tarjeta de crédito. Se comprueba su validez y entonces se le pide introducir un identificador personal. Cuando la transacción de crédito se haya validado, se expide el billete. Ambigüedades:  La tarjeta se introduce dos veces.  El usuario selecciona su destino y luego presiona un botón de inicio y vuelve a elegir el destino.  Valida dos veces la tarjeta.  La validación la realiza antes de que el usuario haya ingresado sus datos.  Se debería especificar si la validación de la tarjeta no es correcta que pasaría (algún mensaje).  La transacción de crédito se podría reemplazar por “se valida que haya fondos en la cuenta y si existe se emite el billete caso contario, se da un mensaje da falta de fondos en la cuenta”.

6.4 Vuelva a redactar la descripción anterior utilizando el enfoque estructurado descrito en este capítulo. Resuelva de forma apropiada las ambigüedades identificadas. El usuario ingresa su tarjeta y sus datos respectivos, el sistema valida los datos ingresados, si son correctos. Si son correctos el usuario ingresa al sistema si no lo son el sistema muestra un mensaje de datos erróneos. Una vez que el usuario ingresa al sistema se muestra todas las ciudades de destino junto con su valor, el usuario elije un destino y acepta la compra del billete, el sistema valida si el usuario cuenta con fondos en la tarjeta, debita el costo del billete, muestra un mensaje si desea realizar otra transacción, si el usuario desea realizar otra transacción vuelve a mostrar las ciudades de destino y continua con este proceso, si no el sistema emite el billete y el usuario retira su tarjeta.

6.5 Dibuje un diagrama de secuencias que muestre las acciones llevadas a cabo en el sistema expendedor de billetes. Puede hacer algunas suposiciones

razonables sobre el sistema. Ponga especial atención en la especificación de los errores del usuario.

Figura Nº 1: Diagrama de Secuencia del Sistema Expendedor de Billetes

6.6 Utilizando la técnica sugerida aquí, en la que el lenguaje natural se presenta en una forma estándar, redacte requerimientos del usuario verosímiles para las siguientes funciones: La función de expedición de dinero en un cajero automático de un banco: El sistema debe pedir la tarjeta, la clave, monto de retiro, tipo de cuenta y finalizar la transacción desembolsando el dinero. La verificación de ortografía y la función de corrección en un procesador de texto:

El sistema debe identificar las palabras equivocadas, avisar al usuario de las palabras incorrectas y ofrecerle una ayuda para la corrección ortográfica y gramática de dichas palabra.

Un sistema de autoservicio de bombas de gasolina que incluye un lector de tarjetas de crédito. El cliente pasa la tarjeta a través del lector y especifica la cantidad de combustible requerido. Éste se entrega y se hace el cargo a la cuenta del cliente: El usuario debe deslizar la tarjeta de crédito por el lector y el Sistema pedirá la clave de seguridad y la cantidad de combustible; al final de la transacción emitirá una factura por el combustible comprado. 6.7 Describa cuatro tipos de requerimientos no funcionales que pueden existir en un sistema. Dé ejemplos de cada uno de estos tipos de requerimientos. 

Requerimientos del producto. Estos requerimientos especifican el comportamiento del producto.  Ejemplo: El sistema contemplará la facilidad de uso enfocado en personas que hablen otros idiomas distintos al país de origen. (Usabilidad)



Requerimientos organizacionales. Estos requerimientos enfocados en políticas y procedimientos de la organización, cliente y desarrollador.  Ejemplo: El Sistema será desarrollado en lenguaje java versión 1.6 o superior.(lenguaje de programación a utilizar)



Requerimientos externos. Incluye requerimientos que se derivan de factores externos al sistema y de su proceso de desarrollo.  Ejemplo: El sistema no deberá revelar a sus operadores alguna información personal de los clientes excepto su nombre y número de referencia. Privacidad / Ético).  Ejemplo: El sistema debe permitir la impresión de informes tanto en la impresora láser como en la impresora matriz (Interoperabilidad)

6.8 Redacte un conjunto de requerimientos no funcionales para el sistema expendedor de billetes, especificando su habilidad y su respuesta en el tiempo. Nº Requerimiento no funcional R001 El Sistema permitirá proveer al usuario la cantidad exacta de dinero solicitado en un tiempo de 5 segundos a partir del registro de la transacción. R002 El Sistema debe actualizar el estado de la cuenta cuando se realice una transacción (cambio de clave, retiro de dinero). R003 El Sistema debe permitir al usuario cambiar la clave de su cuenta. R004 El Sistema debe permitir al usuario visualizar el estado de su cuenta. R005 AL término de la transacción el sistema pedirá que se ingrese nuevamente la tarjeta por seguridad. R006 El Sistema debe presentar un comprobante de pago acorde la institución lo disponga luego de realizada la transacción. R007 El Sistema validará la tarjeta, usuario y clave antes de realizar una

transacción. Tabla Nº 1: Requerimientos no Funcionales

6.9 Sugiera la manera en que un ingeniero responsable de preparar la especificación de requerimientos del sistema podría controlar las relaciones entre los requerimientos funcionales y no funcionales. El ingeniero responsable de preparar la especificación de requerimientos debe hacer un diagnóstico de los procesos que debe realizar el sistema, dependiendo del tipo de software que se esté desarrollando, en base a este estudio se debe redactar los requerimientos funcionales de forma clara y entendible por el usuario sin utilizar términos técnicos de ser posible. Así mismo debe realizar un análisis de los requerimientos no funcionales que debe cumplir el sistema para realizar las funcionalidades de forma rápida, confiable y eficaz, En este punto el desarrollador debe prestar atención a cuestiones técnicas como plataforma a desarrollar el software, base de datos, entono en que se va a ejecutar el software (web,escritorio), la interfaces que requiere el sistema, la decisión por parte de desarrollador de utilizar la tecnología adecuada se basa en los requerimientos funcionales es decir en las procesos o servicios que el sistema debe realizar. En forma general Una buena especificación de requerimientos debe ser:      

 

Completa. Todos los requerimientos deben estar reflejados en ella y todas las referencias deben estar definidas. Consistente. Debe ser coherente con los propios requerimientos y también con otros documentos de especificación. Inequívoca. La redacción debe ser clara de modo que no se pueda mal interpretar. Correcta. El software debe cumplir con los requisitos de la especificación. Trazable. Se refiere a la posibilidad de verificar la historia, ubicación o aplicación de un ítem a través de su identificación almacenada y documentada. Priorizable. Los requisitos deben poder organizarse jerárquicamente según su relevancia para el negocio y clasificándolos en esenciales, condicionales y opcionales. Modificable. Aunque todo requerimiento es modificable, se refiere a que debe ser fácilmente modificable. Verificable. Debe existir un método finito sin costo para poder probarlo.

6.10 Ha obtenido un trabajo con un usuario de software quien ha contratado a su anterior compañía para desarrollar un sistema. Usted descubre que la interpretación de su compañía actual de los requerimientos es diferente de la tomada por su anterior compañía. Comente q u é haría en tal situación. Usted sabe que los costes de su compañía actual se incrementarán si las ambigüedades no se resuelven. También tiene una responsabilidad de confidencialidad para su anterior compañía. Se debe realizar una reunión con el cliente y la compañía actual para comunicar que se realizaran cambios en los requerimientos lo cual ayudara a mejorar los procesos y el sistema será por ende más eficiente. Durante la reunión no debe hacer comentarios

sobre la falta de una especificación de requerimientos adecuada por parte de la compañía anterior; sino en base al análisis de requerimientos realizada por su compañía actual con las mejoras del sistema comunicar que se va a contratar los servicios de la compañía actual.