Capitulo 6 Ingenieria de Requerimientos

1 1 Ingenier a de RequerimientosIngenier a de SoftwareIan Sommerville6 Edici n, cap tulo 6 Ingenier a de Requerimientos (IR) Proceso que comprende todas lasactividades de Requerimientos para crear ymantenerundocumentoderequerimientos del sistema. Proceso de aplicar un m todoestructurado, el cual analiza el sistema ydesarrolla un conjunto de modelosgr ficos del mismo que act an como unaespecificaci n del a de Requerimientos (IR) Existen 4 actividades gen ricas: Estudio de factibilidad del sistema, Obtenci n y an lisis de Requerimientos , Especificaci n de Requerimientos Validaci n. De las actividades se derivan modelos El conjunto de modelos describe elcomportamiento del sistema al cual se leagregan notas con informaci n adicional, quedetallan el desempe o o fiabilidad de IREstudio deFactibilidadObtenci n y An lisis de RequerimientosEspecificaci n de RequerimientosValidaci n de RequerimientosNecesidades del usuario,Dominio de la Informaci n,Sistemas de Informaci n existentes,Est ndares,otrosRequerimientos del Usuario y del sistemaEspecificaci n de Requerimientos de SoftwareInforme de FactibilidadModelos delSistema21.

2 Estudio de Factibilidad (1) Para todos los sistemas nuevos, el procesode IR empieza con un estudio defactibilidad. Entrada: descripci n resumida del sistema y c mo seutilizar dentro de una organizaci n. Salida: Estudio es un informe que recomienda si esconveniente llevar a cabo la IR y el proceso dedesarrollo de un Estudio de Factibilidad (2) Un estudio de factibilidad es corto yorientado a resolver las interrogantes:1. El sistema contribuye a los objetivosgenerales de la organizaci n? Mejorasecon micas,pol ticas o sociales2. El sistema se puede implementar utilizandola tecnolog a actual y con las restricciones decosto y tiempo?3. El sistema puede integrarse a otros queexisten en la organizaci n?1. Estudio de Factibilidad (3) Fases Recolecci n de informaci n. Las fuentes deinformaci n pueden incluir a: Administradores de departamentos Expertos en tecnolog a Usuarios finales del sistema Evaluaci n de la Informaci n identifica la informaci n requerida para contestar alas preguntas Estudio de Factibilidad (4) En la evaluaci n se cuestionan las fuentes deinformaci n para descubrir las respuestas a laspreguntas.

3 C mo se las arreglar la organizaci n si no se llevaa cabo este sistema? Cu les son los problemas con los procesos actualesy c mo ayudar a el nuevo sistema a resolverlos? Cu l es la contribuci n directa que har el sistemaa los objetivos del negocio? La informaci n se puede obtener y transferir a otrossistemas de la organizaci n? El sistema requiere de tecnolog a que no se hautilizado previamente en la organizaci n? A qu debe ayudar el sistema y a qu necesitaayudar?31. Estudio de Factibilidad (5) Cuando la informaci n est terminada seprepara el Informe del Estudio deFactibilidad que contendr : Recomendaci n de cu ndo debe continuar eldesarrollo del sistema Propuesta de cambios en el alcance y elpresupuesto Calendarizaci n del sistema Sugerencias sobre Requerimientos adicionalesde alto Obtenci n y an lisis de Requerimientos (1) Etapa en la que el personal de desarrollot cnico del software trabajar : con Stakeholders (involucrados): Clientes y los usuarios finales del sistema, Ingenieros que desarrollan o dan mantenimiento aotros sistemas, Administradores del negocio, Expertos en el dominio del sistema, Representantes de los trabajadores, etc.

4 Para: Establecer requerimientos2. Obtenci n y an lisis de Requerimientos (2) Dificultades: Stakeholders A menudo s lo conocen lo que desean obtenerdel sistema de c mputo en t rminos muygenerales. Expresan los Requerimientos con sus propiost rminos de forma natural y con unconocimiento impl cito de su propio trabajo. Se tienen Requerimientos distintos y podr anexpresarlos de varias Obtenci n y an lisis de Requerimientos (3) pol ticos Provienen de los administradores quienes solicitanrequerimientos espec ficos para el sistema debido aque sto les permitir incrementar su influencia enla organizaci econ mico y de negocios De forma inevitable cambia durante el proceso dean lisis. Por lo que la importancia de ciertosrequerimientos puede cambiar. Emergen nuevos Requerimientos de nuevosstakeholders quienes no hab an sido Obtenci n y an lisis de Requerimientos (4) Actividades: Comprensi n del dominio de aplicaci n El analista debe desarrollar su propia comprensi n deldomino de la aplicaci n Recolecci n de Requerimientos Interactuar con los stakeholders Clasificaci n recolecci n no estructurada de Requerimientos y losorganiza en grupos coherentes Resoluci n de conflictos cuando existen muchos stakeholders Priorizaci n interacci n con los stakeholders para descubrir losrequerimientos m s importantes Verificaci n de Requerimientos Visualizan su consistencia y completitud2.

5 Proceso de obtenci n y an lisis de requerimientosComprensi n delDominioRecolecci n de RequerimientosValidaci n de RequerimientosClasificaci nResoluci n deConflictosPriorizaci nEspecificaci nde Obtenci n orientada a puntos de vista En un sistema existen diferentes tipos deusuarios finales. Ejemplo: stakeholders para un sistema decajeros autom ticos: clientes actuales del banco, representantes de otros bancos, administradores de las sucursales bancarias, contadores de la sucursal bancaria, administradores de la base de datos, administradores de seguridad del banco, personas del departamento de marketing ing. de mantenimiento de hardware/ Enfoques Punto de vista Los enfoques orientados a puntos de vista para laingenier a de Requerimientos toman en cuenta: puntos de vista diferentes y los utilizan para estructurary organizar tanto el proceso de obtenci n como losrequerimientos mismo.

6 Un punto clave del an lisis orientado a puntos devista es que toma en cuenta: la existencia de varias perspectivas y provee un marcode trabajo para descubrir conflictos en losrequerimientos propuestos por diferentes Qu significa un punto de vista Se puede considerar como: Una fuente o consumidor de datos(identificaci n de fuentes, datos) Un marco de trabajo de la representaci n(diagrama E/R, m quinas de estado, etc.) Un receptor de servicios. En estos los puntos de vista son externos al sistema. Los puntos de vista proveen datos sobreservicios o se ales de El m todo VORD (1) Se ha dise ado como marco de trabajoorientado a servicios para la obtenci n yan lisis de Requerimientos . Las etapas principales de este m todoson: Identificaci n de puntos de vista Estructuraci n de puntos de vista Documentaci n de puntos de vista Trazado del punto de vista del El m todo VORD (2) Identificaci n de puntos de vista.

7 Trata de descubrir los que reciben los serviciosdel sistema e identificar los serviciosespec ficos que se suministran a cada punto devista. Estructuraci n de puntos de vista Comprende la agrupaci n de los usuariosrelacionados en jerarqu a. Los servicioscomunes se ubican en los niveles altos de lajerarqu a y heredan los puntos de vista de El m todo VORD (2) Documentaci n de puntos de vista Comprende refinar la descripci n de stos y losservicios identificados. Trazado del punto de vista del sistema Comprende identificar los objetos en un dise oorientado a objetos utilizando la informaci ndel servicio encapsulado en los puntos Lluvia de ideas para la identificaci n del punto de vistaConsulta deSalidaSuministrosa la m quinaTransaccionesObtenci n de TransaccionesRetiro deefectivoActualizaci nsoftwareActualizaci nRemota delsoftwareOrden deChequesTransferenciade fondosPaso de mensajesDiagn sticosRemotosComprobantede la ordenBase de Datosdel clienteAdministradorCajero delBancoCliente extranjeroMantenimiento Mantenimiento del HardwareCuenta-habienteInterfaz deUsuarioInformaci n deInformaci n dela cuentaCosto Plantilla del punto de vistaNombres de los subpuntos de vistaSubpuntosde vista:Referencia a un conjunto dedescripciones del servicioServicios.

8 Referencia a un conjunto de eventosque describen c mo reacciona elsistema a eventos del punto de vistaEventos:Atributos que proveen informaci n delpunto de vistaAtributos:Nombre del punto de Plantilla del servicioReferencia:Nombre del servicioFundamento:Raz n del porqu se provee el servicioEspecificaci n:Referencia a una lista de especificacionesdel servicio. Puede expresarse endiferentes de vista: Lista de los nombres de los puntos devista que reciben el nofuncionalesReferencia a un conjunto derequerimientos no funcionales querestringen el servicioProveedorReferencia a una lista de objetos delsistema que proveen el EjemploReferencia:ClienteAtributos:N mero de cuentaPINI nicio transacci nEventos:Seleccionar serviciosCancelar transacci nFinalizar transacci nServicios:Retiro de efectivoConsulta de saldoSubpuntos de vista:CuentahabienteCliente extranjeroReferencia:Retiro de efectivoFundamento:Mejorar el servicio al clienteyreducirel papeleoEspecificaci n:Los usuarios eligen este serviciopresionando el bot n de retiro deefectivoPuntos de vista:ClienteRequerimientosno funcionales :Entregar efectivo en menos de unminuto de que se haconfirmadola.

9 Llenar Diagramas de jerarqu a de puntos de vistaTodos los Puntosde VistaPersonal de bancoAdministradorCajeroCliente extranjeroCuentahabienteClienteIngeniero ServiciosConsulta de SaldoRetiro de EfectivoServiciosOrden de chequeLista de transaccionesTransferencia de Escenarios Un escenario empieza con un bosquejo deinteracci n y se van agregando detalles: En general incluyen: Una descripci n del estado inicial del sistema Una descripci n del flujo normal de eventos Una descripci n de lo que puede ir mal y c momanejarlo Informaci n de otras actividades que sepueden llevar a cabo al mismo tiempo Descripci n del estado del sistema al Escenarios de Eventos usados por VORDP etici n de PINV alidar usuarioSeleccionarservicioTarjetaPINP resentar tarjetaRecoger TarjetasInterrupci nRecoger TarjetasTarjeta inv lidaRecoger TarjetasTarjeta RobadaPIN del N merode CuentaTarjetav lidaReintroducir PINPIN incorrectoRegresar tarjetaPIN incorrectoN mero deCuentaUsuario Casos de Uso T cnica basada en escenarios, propuesta enObjectory [Jacobson, I et al, 1993]

10 Parte fundamental de todas las metodolog asque usan UML Un caso de uso encapsula un conjunto deescenariosCaso de EjemploRealizar Transacci nPagar recargo por saldo deudorSistema de Cuentas Bancarias Solicitar Bienes o ServiciosCompradorConfirmar PedidoEnviar Factura al CompradorPagar FacturaVendedorEnviar Aviso<<extend>>+Iniciador+Iniciador+Iniciador+ Escenario del Caso de Uso: Pagar Ejemplo del libroUsuariode laBibliotecaProveedorPersonalde laBibliotecaConsultarserviciosAdministra rUsuariosAdministrarCat logoDiagrama de Secuencia para el Caso de Uso Administrar Cat logo Libreria:ProveedorArticulo:ArticuloBibli otecaLibro: CatalogoCatalogador:PersonalBiblitecaAdq uirirNuevoCatalogarArticuloDisponerQuita r Etnograf a T cnica de observaci n que se puedeutilizar para entender requerimientossociales y organizacionales. Especialmente efectiva para descubrir dostipos de Requerimientos .