Scribd Logo
Upload

Welcome to Scribd!

  • Lecturas Lectura 1 - Requerimientos de Software

    Uploaded by

    jbjrjaen4792
    7 views20 pages

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    7 views20 pages

    Lecturas Lectura 1 - Requerimientos de Software

    Uploaded by

    jbjrjaen4792

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    of 20
    Requerimientos del software Objetivos Los abjetivos de este capitulo son presenta los requerimientos de sistemas software y explicar las diferentes formas de expresar los, requerimientos del software. Cuando haya lefdo este capitulo: m entenderd los conceptos de requerimientos del usuario y del sistema y por qué estos requerimientos se deben escribir de diferentes formas: 1m entenderd las diferencias entre los requerimientos del software funcionales y no funcionales; m entenderé cémo los requerimientos se pueden organizar en un documento de requerimientos det software. Contenidos 16.1. Requerimientos funcionales y no funcionales 6.2 Requerimientos del usuario 6.3 Requerimientos dei sistema 6.4 Especificacion de a intertaz 65 El documento de requerimientos del software 108 CAPITULO 6 m Requeimienos del software Los requerimientos para un sistema son la deseripeidn de los servicios proporcionados por el sistema y sus restricciones operativas. Esis requerimientosreflejan las necesidades de ls clien- tes de un sistema que ayude a resolver algin problema como el control de un dispositive, hacer un pedido o encontrar informacién. El proceso de descubrir,analizar, documentary verificares- tos servicios y restricciones se denomina ingenieria de requerimientos (RE). Este capitulo se centra en dichos requerimientos y emo descrbiros. Enel Capitulo 4 se dio una introduccisn 4 proceso de ingenieria de requerimientos y en el Capitulo 7 se analizaré con mas detalle El témino requerimienzo no se utiliza de una forma constante en la industria de software. En algunos casos, un requerimiento es simplemente una declaracién abstracts de alto nivel de tun servicio que debe proporeionar el sistem o una retricién de éste. En el otro extrem es tuna definicidn detallada y formal de una funciGin del sistema. Davis (Davis, 1993) explica por que existen estas diferencias ‘Si una compatia desea establecer un contrato para un proyecto de desarollo de software arande, debe definir sus necesidades de una forma suficientemente abstract para establecer a partir de ella una solucidn, Los requerimientos deben redactarse de tal forma que varios conte tists pueden lcitar el contrato,ofreciendo, quizis, formas diferentes de cumpli las necesida- des de los clientes en la organizacin, Una vez que el contsto se asin el contratista debe r- actar una definicién del sistema para el cliente mis detalladamente de forma que éste ccomprenda y pueda validar lo que hard el software. Ambos documentos se pueden denomi documento de requerimientos para el sistema, Algunos de los problemas que surgen durante proceso de ingenierfa de requerimientos son resultado de no hacer una clara separacién entre estos diferentes niveles de descripein, Aqut se distinguen wilizando ta denominacién requerimientos del usuario para designar los requerimientos abstractos de alto nivel. y requerimtientos de! sistema para designar la des- cripeién detallada de lo que el sistema debe hacer. Los requerimientox del usuario y del sis tema se pueden definir como se muestra continuaciéa. 1. Los requerimientos del usuario son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funciona. 2. Los requerimientos del sistema establecen con detalle las funciones, servicios y res- triceiones operativas del sistema. FI documento de requerimientos det sistema (algu- nas veces denominado especificacién funcional) debe ser preciso. Debe definir exac- tamente qué es lo que se va a implementar. Puede ser parte del contrato entre et comprador del sistema y los desaerolladores del software Diferentes niveles de especificacin del sistema son de utilidad debido a que comunican Ja informacisn del sistema a diferentes tipos de lectores. La Figura 6.1 ilustraladistincién en- tre los requerimientos del usuario y del sistema. Este cjemplo de un sistema de biblioteca ‘muestra la manera en que un requerimiento del usuario se expande en varios requerimientos el sistema, Puede verse en la Figura 6.1 que el requerimiento del usuario ex mas abstracto, 1 que los requerimientos del sistema aiaden éetalle,explicando los servicios y funciones que ‘deben ser proporcionados por el sistema a desarrollar Es necesario redactr los requerimientos en diversos niveles de detalle debido a que dife- rents tipos de lectores los uiizan de distinta manera, La Figura 6.2 muestra los tipos de lee- tores de los requerimientos de usuario y del sistema, Los lectores de los requerimiientos de usuario normalmente no tratan de cémo se implementardel sistema y pueden ver administra dores que no estén interesados en los recursos detalladas del sistema. Los Iectores de los re- 6.1m Requerinientos uncionaes yo funcionals 109 Figura 6.1 Requerimientos el usuario y del sistema. Figura 6.2 Lectores de los diterentes tipos de especificaciones. 6.1 Definicign del requerimiento del usuario 1. UBSYS controlaré todos los datos licencian los derechos de autor en .queridos por las agencias que Reino Unido y en ota pare. Especificacin de los requerimiantos del sistema 1.1 Al hacer una peticén de un documento del LIBSYS, el solictante se presentaré con un formulario que registe los detalles del usuario y (71 ~ 10)) Si resultado redondeado = 0 entonces CompDose = DosisMinima 122 __ CAPITULO 6 wm Requarimientos det software Figura 6.14 Diagrama de secuencia de la retirada de dinero en un ATM. 6.4 ed | __Taseta»_7) wamero deta Trets hy Tayeta OK petion de pn _| je —Téset2 OK _| Pin Opciones del ment << Excepcion>> tarjeta no valida Peticion de reirada Peticion de saldo Peticion de cantidad | *———-—| fre le -- { “Tatar peticion Cargor(cantidad) <> | [Respuesta de la carga insuficiente dinero [Resoueste de lo carey 2. Tratar peticién. El sistema trata la peticién del usuario. Para una retirada de dinero, se ‘debe consultar la base de datos para comprobar el saldo del usuario y cargar ta canti- dad retirada, Fijese aqui en la excepcién si cl solicitante no tiene suficiente dinero en su cuenta 3. Completar sransaccién. Se devuelve la tarjeta del usuario y, cuando se ha extraido. se ‘entrega el dinero y el recibo. Se vers de nuevo los diagramas de secuencia en el Capitulo 8, que tata los modelos de sistemas, yen el Capitulo 14, que estudia el disero orientado a objetos. Especificacién de la interfaz Casi todos los sistermas software deben funcionar con otros sistemas que ya estén implemen- tados e instalados en el entorno. Si el sistema nuevo y los ya existentes deben trabajar juntos, {as interfaces de estos dltimos deben especificarse de forma precisa, Estas especificaciones se 6.5 Mm Eldocumento derequerimentos del sotware 123, 6.5 Figura 6.15 La descripcion en PDL basado en Java de una interfaz del servidor de impresion, | cumplen sus necesidades. Los clientes especiican los cambios ‘en los requerimientos Utiizan ef documento de requerimientos para planificar Adrinisadores } —| tit ota pore sistemay par planificar el proceso de sesarollo del sistema Ingenieros Utiizan los requerimientos para desisteras comprender qué sisterna debe sdesarolarse Utilzan los requesimientos para probadores desarollar las pruebes de ‘alidacién para el sistema Usizan los requerimientos para comprender el sistema y las telaciones entre sus partes 8.5m Eldocumento de requerimientos del software 125 requerimientos puede ser mucho menos detallado y cualquier ambigiiedad resuelta duran- te el desarrollo det sistema. arias organizaciones grandes, como ¢l Departamento de Defensa de los Estados Unidos y el IEEE, han definido esténdares para los documentos de requerimientos. Davis (Davis, 1993) analiza algunos de estos estindares y compara sus contenidos. El estindar més am- pliamente conocido es el IEEE/ANSI 830-1998 (IFEE, 1998). Este estindar IEEE sugiere la siguiente estructura para los documentos de requerimientos 1. Introduecién 1.1 Propiisito del documento de requerimientos 1.2 Aleance det producto 1.3 Definiciones, aerénices y abreviatures 14 Referencias 1.5. Descripcién del resto del documento 2. Deseripeién general 2.1 Perspectiva del producto 2.2. Funciones del producto 23, Caracteristicas del usuario 24 Restricciones generales 2.5. Suposiciones y dependencias 3. Requerimientos especificos: incluyen tos requerimientos funcionales, no funciona- les y de interfaz. Obviamente, ésta es la parte mas sustancial del documento, pero de- bido ala amplia variabilidad en fa préctica organizacional, no es apropiado definir una estructura estindar para esta seccién, Los requerimicntos pueden documentar las in- terfaces externas, describir a funcionalidad y el rendimiento del sistema, especificar los requerimientos lgicos de la base de datos, las restricciones de disefo, las propie- dades emergentes del sistema y las caracteristicas de calidad. 4. Apéndices 5. indice ‘Aunque el estindar IEEE no ¢s ideal, contiene muchos consejos sobre ¢émo redactar los requerimientos y cémo evitar problemas. Es muy general para que peda ser un estindar de tuna organizaci6n, Es un marco general que se puede transformar y adaptar para defini un es- téndar ajustado a las necesidades de una organizacion en particular Le Figura 6.17 ifustra una posible organizacién para un documento de requerimiientos que se basa en el estindar IEEE. Sin embargo, se ha ampliado para incluirinformacisn sobre la evolucién predicha de sste- ‘ma. Esto fue propuesto por primera vez por Heninger (Heninger, 1980) y, como se ha indica- 4, ayuda alas personas encargadas del mantenimiento del sistema y puede permits a los di seitadoresineluir soporte para futuras caracteristicas del sistema. Por supuesto, la informacién que se incluya en un documento de requerimientos debe de- ender del tipo de software a desarrollary del enfoque de desarrollo que se utilice. Si se adop- ta un enfoque evolutivo para un producto de software (por ejemplo), el documento de reque- rimientos dejar fuera muchos de los eapitulos detallados sugeridos anteriormente. El interés estar en definir los requerimientos del usuario y los requerimientos del sistema no funcio nales de alto nivel. En este caso, los disevladores y programadores utilzan su juicio para de- cidir cémo satisfacer el esquema de los requerimientos del usuario para el sistema. Por el contrario, cuando el software es parte de un proyecto de ingenieria de sistemas gran- de que incluye la interacci6n de sistemas hardware y software, a menudo es Fundamental de Finir con mucho detalle los requerimientos. Esto significa que el documento de requerimien- 126 CAPITULO 6m Requerinintos de software tos probablemente sea muy extenso y deba incluir la mayoria sino la totalidad de Tos capitu- Jos que se muestran en la Figura 6.17. Para documentos extensos, es de panicular importan- cia incluir una tabla de contenido comprensible y un indice del documento para que asi los lectores puedan encontrar la informacién que necesitan. El documento de requerimientos es fundamental cuando un contratsta exterior esti desarro- land el sistema software, Sin embargo, los métodos de desarrollo giles sostienen que los reque- rimientos cambian tan répidamente que un documento de requerimientos se queda desfasado en cuanto se redacta, por lo que el esfuerzo en gran parte se malgasta, Més que un documento formal, enfoques como la programacién extrema (Beck, 1999) proponen que los requerimientos del usua- rio deberian ser recogidos incrementalmente y escritos en tarjetas. El usuario entonces da priori- dada los requerimientos que se han de implementar en el siguiente incremento del sistema, Para sistemas de negocio donde los requerimientos son inestables, pienso que este enfo- {que es bueno, Sin embargo, argumentaria que todavia es itil redactar un breve documento de soporte que defina el negocio y los requerimientos de confiabilidad del sistema. Es fécil o: Vidarse de los requerimientos que se aplican al sistema en su totalidad al centrarse en los re- 4querimientos funcionales para la siguiente entrega del sistema, ‘Debe definir tox posibles letores del documento y descaibir su version dela historia, in- ‘duyendo un fundamento para la ceacién de una nueva versin y un resumen de los cambios hechos en cade una. ‘Dube desc a necesidad del sistema Debe desc brvernete 2 fundones y pce abner onc stra. Ob deci a manera equ te a ere al negocio total u objetvosexrattgicos del organizacion que solic el softwere. ‘Debe defini los tbrminos thericos ullzados en el document. Nose deben hacer si osiciones de a experiencia o perc del lec. Definicion de requerimientos ‘En esta seccin se deben desir las senidos que se proporcionan al usuario ylos re del usuario “Arquitectura del sisterna ‘quetimientos no funcionales del sistema. Esta puede utlizar lenguaje nate ‘al, diagramas u otrs notaciones que sea pra los clientes. Se deben e- eciticar los estindares de productos y procesos a seguir. [Ete caphtlo debe presentar una vision general de alo nivel dela previa

    You might also like