12. RequisitosIngeniería del Software I3º I.T.I.GestiónMiguel A. LagunaContenidos2.1 Tipos de requisitos.2.1.1 Requisitos ...
22.1 Tipos de requisitosRequisitos de usuario y del sistemaRequisitos funcionales y no funcionales(Reglas y requisitos de ...
3Ejemplos de requisitos funcionales1. Se deben poder realizar búsquedas enbase a diferentes criterios.2. Se deben proporci...
4UU sability Human factors aesthetics, consistency,documentationRR eliabilityFrequency/severity of failure,Funcionality Re...
5Ejemplo: Un catálogo derequisitosRequisitos Funcionales.• Funciones principales del sistema• Mantenimiento de datos de so...
6Problemas con el lenguajenaturalFalta de claridadLa precisión es difícil sin hacer eldocumento ilegible.Confusión de requ...
7Definiciones del diccionariocordero.(Del lat. vulg. *cordarius, der. de cordus, tardío).1. m. Hijo de la oveja, que no pa...
8Estudio de viabilidadEl estudio de viabilidad permite decidir si elsistema propuesto es convenienteEs un estudio rápido y...
9Entrevistas,Flujos detrabajo49Casos deuso2.3 Elicitación de RequisitosLa entrevistaHerramientas gráficasTécnicas de elici...
10Entrevistas a puestos detrabajoObjetivos:operaciones efectuadas (Lista de Tareas)eventos periódicosdatos y documentos/in...
11Proveedor Almacén EncargadoHacer pedido[Ficha Producto][Menu]juevesServir Pedido[Pedido]actor externo61[Pedidos Ptes.][A...
12Documento y datosImporte: 999.999Fecha 99/99/99XXXXXXXXXXXCIF 99999999Factura Ref. : XXX67Iva: 999.999Total: 999.999Nomb...
13Gestión de los requisitosLa gestión de los requisitos es el proceso demanejar los requisitos que cambian duranteel desar...
14El documento de requisitosEl documento de requisitos es la declaraciónoficial de lo que se necesita construir. Sedenomin...
15Ejemplo Larman: Visión1.2 Participantes en el proyectoDescripción del personal involucradoEntrevistas:Resumen del person...
16Ejemplo Larman: Catálogo derequisitos del sistema3.2 Requisitos no funcionalesFacilidad de usoEl cliente será capaz de v...
Próxima SlideShare
Cargando en…5
×

2 requisitos

295 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
295
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
1
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

2 requisitos

  1. 1. 12. RequisitosIngeniería del Software I3º I.T.I.GestiónMiguel A. LagunaContenidos2.1 Tipos de requisitos.2.1.1 Requisitos de usuario y del sistema2.1.2 Requisitos funcionales y no funcionales.2.2 Actividades de la Ingeniería de Requisitos22.3 Elicitación de Requisitos2.2.1 Entrevistas.2.2.2 Herramientas. Diagramas de actividades2.4 Validación y gestión de requisitos2.5 El documento de requisitosProblema y SoluciónUsuariosEspacio delProblemaProblemProblema3sistemanuevoRequisitosSoftwareDiseñoTest Doc.ObjetivosEspacio dela SoluciónTrazabilidadIngeniería de RequisitosLos requisitos determinanlo que hará el sistema (cómo funcionará)restricciones sobre su operación eimplementación.4La elicitación, análisis y especificación derequisitos es el proceso del estudio de lasnecesidades de los usuarios para llegar a unadefinición de los requisitos del sistema¿Qué es un requisito?Un requisito es una “condición o capacidadque necesita el usuario para resolver unproblema o conseguir un objetivodeterminado”.5También se aplica a las condiciones que debecumplir o poseer un sistema o uno de suscomponentes para satisfacer un contrato, unanorma o una especificación.¿Qué es un requisito?Puede verse comouna declaración abstracta de alto nivel de unservicio que el sistema debe proporcionaruna definición matemática detallada y formal de6una definición matemática detallada y formal deuna función del sistema.Los requisitos cumplen una doble funciónSon una oferta de contrato -> abiertos a lainterpretaciónSon el contrato en sí mismo -> deben definirse deforma detallada
  2. 2. 22.1 Tipos de requisitosRequisitos de usuario y del sistemaRequisitos funcionales y no funcionales(Reglas y requisitos de información)Tipos de requisitosRequisitos de usuarioDeclaraciones en lenguaje natural y en diversos diagramasde los servicios del sistema y de las restricciones bajo lasque debe operar.Requisitos del sistema8qUn documento estructurado que determina las descripcionesdetalladas de los servicios de sistema.Escrito como contrato entre el cliente y el desarrolladorDeben ser una especificación completa y consistente delsistemaEspecificación del software: descripción detallada delsoftware que sirve de base a los desarrolladores paradiseñar el sistema .Requisitos de usuario y del sistema1.- El sistema debe permitir representar y acceder a archivosexternos creados por otras herramientasUn requisito de usuarioRequisitos del sistema asociados91.- El usuario deberá poder definir el tipo de un nuevo archivo externo.2.- Cada tipo de archivo tendrá una herramienta asociada, que se aplicaráal archivo.3.- Cada tipo de archivo se representará con un icono específico.4.- El usuario deberá poder definir el icono que representa un tipo dearchivo externo.5.- Cuando el usuario selecciona un icono que representa un archivoexterno, el efecto es aplicar la herramienta asociada con este tipo dearchivo al archivo representado por el icono seleccionado.Entradas SalidasSistemaRequisitos funcionales y no funcionales10FuncionalidadRNFRequisitos funcionales y no funcionalesRequisitos funcionales (RF)Definición de los servicios que el sistemadebe proporcionar, cómo debe reaccionara una entrada particular y cómo se debe11a una entrada particular y cómo se debecomportar ante situaciones particulares.Requisitos no funcionales (RNF)Restricciones que afectan a los servicios ofunciones del sistema, tales comorestricciones de tiempo, sobre el procesode desarrollo, estándares, etc.Requisitos funcionalesDescriben el funcionamiento del sistemaLos RF del usuario pueden ser frases muygenerales sobre lo que el sistema debería12generales sobre lo que el sistema deberíahacer. Se suelen expresar como objetivos delsistema.Los RF del sistema deben describir losservicios que hay que proporcionar con tododetalle: los casos de uso
  3. 3. 3Ejemplos de requisitos funcionales1. Se deben poder realizar búsquedas enbase a diferentes criterios.2. Se deben proporcionar diferentesvisores para que el usuario lea los13p qdocumentos recuperados.3. Cada factura tendrá un número únicoy correlativo y la fecha.Requisitos no funcionalesDefinen propiedades emergentes del sistema, talescomo el tiempo de respuesta, las necesidades dealmacenamiento, la fiabilidad, …Pueden especificar también la utilización de una14Pueden especificar también la utilización de unaherramienta CASE en particular, un lenguaje deprogramación o un método del desarrollo.Pueden ser más críticos que los funcionales.Si un R. funcional no se cumple, el sistema se degradaSi un R. no funcional no se cumple, el sistema puedeinutilizarseClasificación de los requisitos nofuncionalesRequisitos del productoEspecifican el comportamiento del producto obtenido:velocidad de ejecución, memoria requerida, porcentaje defallos aceptables, …15Requisitos organizacionalesSon una consecuencia de las políticas y procedimientosexistentes en la organización: procesos estándar utilizados,de fechas de entrega, documentación a entregar, …Requisitos externosPresentan factores externos al sistema y a su proceso dedesarrollo: interoperabilidad del sistema con otros, requisitoslegales, éticos, …Ejemplo de requisitos no funcionales1. Requisito del producto4.C.8 Se utilizará en todas las comunicaciones elconjunto de caracteres ADA estándar2. Requisito organizacional16q g9.3.2 El sistema se debe desarrollar de acuerdocon el proceso estándar XYZCo-SP-STAN-95.3. Requisito externo7.6.5 El sistema no divulgará a los operadoresninguna información personal sobre losclientes aparte de su nombre y su número dereferencia.Requisitos verificablesLos requisitos no funcionales pueden ser muydifíciles de expresar con exactitud.Los requisitos imprecisos pueden ser difícilesd ifi17de verificarUn deseo general del usuario es, por ejemplo, lafacilidad de usoRequisito no funcional verificableUna frase que incluye alguna medida que puedeser objetivamente probadaEjemplo: RNF verificables1. RNF imprecisos (una primera versión)- Los usuarios especializados deberán utilizar el sistemafácilmente.- El sistema deberá estar organizado para minimizar los18El sistema deberá estar organizado para minimizar loserrores del usuario.2. RNF verificables (detallados)- Los usuarios experimentados deberán poder utilizartodas las funciones del sistema después de un total dedos horas de entrenamiento.- Después de este entrenamiento, el número medio deerrores cometidos por los usuarios experimentados noexcederá de dos por día.
  4. 4. 4UU sability Human factors aesthetics, consistency,documentationRR eliabilityFrequency/severity of failure,Funcionality Requisitos funcionalesUna guía básica de RNF: [F]URPS19RR eliability(Fiabilidad)recoverability, predictability, accuracy,MTBFPPerformance(Rendimiento)Speed efficiency, resource usage,throughput, response timeSSupportability(Soporte)Testability ExtensibilityAdaptability MaintainabilityCompatibility ConfigurabilityServiceability InstallabilityLocalizability Robustness[F]URPS, ejemploFacilidad de uso (usability)Se debe ver el texto fácilmente a una distancia de 1metroFiabilidad (reliability)20( y)Si se produce algún fallo al usar un servicio externo(autorización de pago) solucionarlo localmenteRendimiento (performance)conseguir la autorización de pago en menos de 1minuto, el 90% de las vecesSoporte (supportability)El sistema debe ser instalable por los usuarios.Reglas del negocioy Requisitos de informaciónLas reglas del negocio describen las característicasdel dominio en el que se encuadra la organización.Pueden ser requisitos funcionales, restringir los existentes odefinir cálculos particulares.Si las reglas del negocio no se satisfacen, el sistema puede21g g , pno trabajar de forma satisfactoria.Los requisitos de información son también formasespecializadas de requisitos:el sistema guardará información sobre los socios delvideoclub, en concreto DNI, nombre…)Reglas de negocio en diversosdominios1. Restricción a un requisito funcional:Habrá una interfaz del usuario estándar paratodas las bases de datos, que tomará comoreferencia el estándar Z39.50.222. Restricción legal:Debido a las restricciones en los derechos deautor, algunos documentos se deben suprimirinmediatamente después de su llegada.3. Cálculo particular:La desaceleración del tren se calcula como:Dtren = Dcontrol + DgradienteRequisitos de informaciónIRQ–02: Información sobre un socio de unvideoclubNúmero de socioNúmero del DNI23Número del DNINombre y apellidosFecha de nacimientoSexoFecha de alta como socioDirecciónTeléfonosPelículas alquiladas en un momento dadoGuías para escribir requisitosInventar un formato estándar y utilizarlo paratodos los requisitosUtilizar el lenguaje de forma consistente.Distinguir entre los requisitos obligatorios y24Distinguir entre los requisitos obligatorios ylos deseables.Resaltar el texto para identificar las partesclaves del requisito.Evitar el uso de lenguaje “técnico”.
  5. 5. 5Ejemplo: Un catálogo derequisitosRequisitos Funcionales.• Funciones principales del sistema• Mantenimiento de datos de socios.• Generación de facturas con periodicidad25Generación de facturas con periodicidadvariable (1, 2, 3, 6, 12 meses) a partir decualquier mes.• Facturación con el formato exigido por la Cajade Ahorros.• Facturación mensual para recibos corrientes, yen cualquier momento para no corrientesEjemplo: Un catálogo derequisitos• Funciones de consultas• Socios, facturas e impagados• Lista detallada de facturas impagadas parapoder proceder a su reclamaciónF i d i f ió26• Funciones de información• Socios (datos personales, bancarios, cuota yperiodicidad)• Facturas (todas las facturas emitidas, seancobradas o pendientes de pago)Ejemplo: Un catálogo derequisitos• Funciones de interacción con otros sistemas• Caja de ahorros: disco con formato normalizadopara realizar la facturación• Programa de contabilidad, para realizar losasientos correspondientes a cada mes27asientos correspondientes a cada mesEjemplo: Un catálogo derequisitosRequisitos No Funcionales.• De rendimiento• No se especifican detalles28• Volumen de 500 socios• De frecuencia de tratamiento• Facturación mensual típica de 250 socios, conpicos de hasta 5000• Los impagados suelen ser el 2% del volumentotal facturado al mesEjemplo: Un catálogo derequisitos• De seguridad• Control de accesos: Una palabra clave para elusuario (secretaria)• Copias de respaldo: No especificadoI t id d d l i f ió N ifi d29• Integridad de la información: No especificado• De comunicaciones• Ninguno. Todas las aplicaciones funcionan en elmismo computadorImprecisiones en los requisitosAparecen problemas cuando los requisitos nose precisan con exactitudLos requisitos expresados de forma ambigua sepueden interpretar de manera diferente por losd ll d l i30desarrolladores y por los usuariosObjetivo: La especificación debe ser completay consistenteCompleta: Todos los servicios solicitados por elusuario están definidos.Consistente: Los requisitos no tienen definicionescontradictorias.
  6. 6. 6Problemas con el lenguajenaturalFalta de claridadLa precisión es difícil sin hacer eldocumento ilegible.Confusión de requisitos31Confusión de requisitosLos requisitos funcionales y no funcionalestienden a estar mezclados.Conjunción de requisitosVarios requisitos se pueden expresarjuntos, como un único requisito.Ejemplos de mezcla de requisitos4.A.5La base de datos debe soportar la generación yEn el siguiente ejemplo se mezclan requisitos de usuariocon requisitos del sistema:32La base de datos debe soportar la generación yel control de la configuración de aquelloselementos que agrupaciones de otros elementosque también están en la base de datos.Este control de la configuración debería permitiral usuario acceder a los elementos de unadeterminada versión sin especificar su nombrecompleto.Ejemplos de requisitos2.6En el siguiente ejemplo aparecen requisitosfuncionales y no funcionales33Para ayudar en la ubicación de una entidad enun diagrama, el usuario activará una cuadrículaen centímetros o en pulgadas, mediante unaopción en el panel de control.Inicialmente, la cuadrícula estará desactivada. Lacuadrícula se podrá activar o desactivar encualquier momento y ponerse en centímetros oen pulgadas.RNF: el sistemadeberá soportardistintos sistemasde unidades“A deberá hacer B”AmbigüedadUn requisito debe tener una únicainterpretación34“A deberá hacer B”“A deberá hacer B”Ambigüedad: un ejercicioMaría tenía un cordero…35Gause & Weinberg, 1989Definiciones del diccionarioTenía, del verbo Tener1. tr. Asir o mantener asido algo.2. tr. poseer ( tener en su poder).3. tr. mantener ( sostener). U. t. c. prnl.4. tr. Contener o comprender en sí.5 tr dominar ( sujetar)365. tr. dominar ( sujetar).6. tr. guardar ( cumplir). Tener la palabra, la promesa7. tr. hospedar ( recibir huéspedes).8. tr. Estar en precisión de hacer algo u ocuparse en ello. Tener clase Tener junta9. tr. Juzgar, reputar, considerar. Tener a alguien POR rico. Tener A gala, A honra algo. U.t. c. prnl. Tenerse POR sabio10. tr. Estimar, apreciar. Tener EN POCO, EN MUCHO. U. t. c. prnl.11. tr. Emplear, pasar algún espacio de tiempo en un lugar o sitio, o de cierta manera.Tener las vacaciones en Barcelona Tener un día aburrido12. tr. experimentar. Tener cuidado, vergüenza, miedo, hambre, calor, nervios….
  7. 7. 7Definiciones del diccionariocordero.(Del lat. vulg. *cordarius, der. de cordus, tardío).1. m. Hijo de la oveja, que no pasa de un año.2. m. Piel de este animal adobada.3. m. Hombre manso, dócil y humilde.374. m. por antonom. Jesucristo, Hijo de Dios.…Ambigüedad ycomprensibilidadcomprensibilidad38AmbigüedadAlternativas al lenguajenaturalLenguaje natural estructuradoMantiene la expresividad y comprensión dellenguaje naturalDelimita la terminología utilizada y emplea39Delimita la terminología utilizada y empleaplantillas.Se describen los objetos que manipula el sistema,las funciones que ejecuta y los eventos queprocesa.Notaciones gráficasSe utiliza un lenguaje gráfico, complementado conanotaciones en lenguaje natural estructurado.2.2 Actividades de la Ingenieríade RequisitosUn esquema general…Entrevistas conlos“Stakeholders”Definición delProblema41Especificación derequisitosDocumento deVisionReq. NFModelo decasos de usoRequisitos Func.Modelo dedominioActividades de la Ingeniería deRequisitosLos procesos utilizados en Ingeniería de Requisitosvarían dependiendo del dominio de aplicación, de lagente implicada y de la organización que desarrollalos requisitos42Sin embargo, hay un número de actividadesgenéricas comunes a todos los procesosEstudio de viabilidadElicitación (extracción o captura) de RequisitosAnálisis de RequisitosValidación de RequisitosGestión de Requisitos
  8. 8. 8Estudio de viabilidadEl estudio de viabilidad permite decidir si elsistema propuesto es convenienteEs un estudio rápido y orientado a conocer:si el sistema contribuye a los objetivos de la43y jorganizaciónsi el sistema se puede realizar con la tecnologíaactual y con el tiempo y el coste previstosi el sistema puede integrarse con otros existentesElicitación y análisis derequisitosElicitación (o extracción o captura o determinación…)de requisitos:El proceso mediante el cual los usuarios descubren, revelan,organizan y comprenden los requisitos que desean.Técnicas: observación, entrevistas, herramientas CASE (REMy UML)44Análisis de requisitos:El proceso de razonamiento sobre los requisitos obtenidosen la etapa anterior, detectando y resolviendo posiblesinconsistencias o conflictos, coordinando los requisitosrelacionados entre sí, etc.Técnicas: diferentes representaciones gráficas (UML) ytécnicas de revisiónValidación y gestión derequisitosValidación de los requisitos:El proceso de confirmación, por parte de los usuarios, deque los requisitos especificados son válidos, consistentes,completos, etc.Técnicas: Listas de comprobación y técnicas de revisión.45p yGestión de Requisitos:es el proceso de manejar los requisitos que cambian duranteel desarrollo del sistemaTécnicas: Herramientas CASE (REM)ElicitaciónEn esta etapa, se trata de descubrir losrequisitosEl personal técnico trabaja con los clientes yusuarios para descubrir el dominio de laaplicación los servicios que se deben46aplicación, los servicios que se debenproporcionar y las restriccionesPuede implicar a usuarios finales,encargados, ingenieros implicados en elmantenimiento, expertos del dominio, etc.Son los llamados participantes o interesados(stakeholders).ProblemasLos participantes no conocen realmente loque quierenLos participantes expresan los requisitos consus propios términosDiferentes participantes pueden tener47Diferentes participantes pueden tenerrequisitos conflictivosFactores políticos y organizativos puedentener influencia en los requisitosLos requisitos cambian durante el análisis.Pueden aparecer nuevos participantes ycambiar el entorno del negocioEtapas en la elicitación derequisitos1: Obtener información sobre el dominio delproblema y el sistema actual.2: Preparar y realizar las reuniones deelicitación/negociación.3: Identificar/revisar los objetivos del sistema.4: Identificar/revisar los requisitos de información484: Identificar/revisar los requisitos de información.5: Identificar/revisar los requisitos funcionales.6: Identificar/revisar los requisitos no funcionales.7: Priorizar objetivos y requisitos.Metodología de elicitación de requisitos (AmadorDurán, 2003)
  9. 9. 9Entrevistas,Flujos detrabajo49Casos deuso2.3 Elicitación de RequisitosLa entrevistaHerramientas gráficasTécnicas de elicitaciónRequisitos?????Talleres dediscusiónEntrevistas Cuestionarios,fichas, etc.PrototiposSystemRequirement lNeedsdsStoryboards, Flujos de trabajoTalleres de requisitos(Workshops)Busca un acuerdo general sobre el alcance, riesgos, ylas características importantes del sistema desoftware.Son dirigidos por un facilitador.Duración: tres a cinco de díasDuración: tres a cinco de díasArtefactos creados:declaración de problemaobjeto de negociodiagrama de Casos de usolista de riesgos…Ventajas:Resultados muy pronto52La entrevistaLos objetivos de la etapa de elicitación son dos:Conocer a fondo el departamento donde la empresa necesitamejorar.Realizar un censo exhaustivo de las necesidades del sistemaque se quiere informatizar53Cada persona del departamento tiene su propiavisión del sistema.La dirección, global pero difusa; los trabajadores, parcialpero concretaLas técnicas de recogida inicial de información son:Observación directaEstudio de los documentosRevisión de los ficheros que se manejan actualmenteSobre todo, las entrevistas.Entrevistas a la direcciónObjetivos:primer conocimientocenso de objetivos deseadosorganigrama de puestos de trabajointerfaces con otros proyectosdelimitar en lo posible el campo de estudio54delimitar en lo posible el campo de estudioEntrevistados: jefe de área, de servicio, de negociado,...Técnica: informal, periodísticaResultados: Visión del proyectoobjetivos principaleslista de puestos de trabajocampo de estudiorestricciones: medios, calendario, legislación, etc.
  10. 10. 10Entrevistas a puestos detrabajoObjetivos:operaciones efectuadas (Lista de Tareas)eventos periódicosdatos y documentos/informaciones manipuladasqué puestos intervienentambién mensajes electrónicos, telefónicos, fax,...55también mensajes electrónicos, telefónicos, fax,...reglas del negociolenguaje de la empresaEntrevistados: contable, administrativo, agente de ventas,etc.Técnica: Se debe intentar estructurar la información recibida,mediante fichas, representación gráfica...Fichas de entrevistaEl contenido de una ficha de entrevista a un puestode trabajo será:IdentificaciónPersonaDepartamento56DepartamentoEmpleoOperaciones que realiza y descripciónDocumentos enviados y recibidos desde el puesto(incluidos los “documentos” orales) y descripciónnombreorigen y destinoperiodicidadvolumenconservación/destrucciónHerramientas auxiliaresMatriz de flujos:En ella, se representan tanto los actores externoscomo los internos y cómo fluye la informaciónentre ellosDiagrama de flujos de trabajo (diagrama de57Diagrama de flujos de trabajo (diagrama deactividades de UML)Se asignan actividades a los actores externos einternos. Los resultados de las actividades (lainformación que fluye) se representan comoobjetosPermite la reorganización de los flujos de trabajoEjemplo Restaurante:pedidos a proveedores.El encargado del restaurante, cada martes y juevesconfecciona los pedidos a los proveedores con todoaquello que está bajo mínimos y en función de losmenús de la próxima semana.Dispone de una ficha por cada producto y una vezhecho el pedido (fax o teléfono), guarda una copia58hecho el pedido (fax o teléfono), guarda una copiaen la carpeta de pendientes.Cuando un pedido llega al almacén, el almacenistacomprueba el albarán de entrada y si es correcto selo pasa al encargado.Al final de cada día, el encargado actualiza las fichasde producto y la carpeta de pendientes con losalbaranes revisados.Descripción de la actividady condiciones de disparoPuesto deTrabajoFrecuencia yduraciónEntrada SalidaHacer pedidocada jueves 9:00Encargado 10 min Ficha,MenúsPedido,Pedidos ptes.Recepción de pedidos ycontrol cuando llegaAlmacén 2 ó 3 diarias,45’Albarán AlbaránrevisadoDocumentación de actividades59control cuando llegaAlbarán45’ revisadoActualizar pendientes yfichas, al final del díaEncargado 30’ Albarán rev,Ficha,Pedidos ptes.Ficha,Pedidos ptes.Control facturas,cuando llega facturaEncargado 2 ó 3 diarias,5’Factura,Pedidos ptes.Pedidos ptes.Orden depagoPagar,los días 1, 10 y 20 del mesContable 10-12 cada vez Orden depagoTransferenciaMatriz de FlujosDe …. A Proveedor Encargado Almacén ContableProveedor factura albaránEncargado Pedido Pedidos ptes orden de60Encargado Pedido Pedidos ptes.Fichas productoorden depagoAlmacén AlbaránrevisadoContable Transferen-cia
  11. 11. 11Proveedor Almacén EncargadoHacer pedido[Ficha Producto][Menu]juevesServir Pedido[Pedido]actor externo61[Pedidos Ptes.][Albarán] Recepción[Albarán Rev.] Actualizar ptes y ficha[Ficha Producto]final del día[Pedidos Ptes.]Ejemplo Restaurante:pagos a proveedores.Las facturas llegan directamente de losproveedores al encargado.El encargado comprueba las facturas y,si son correctas da la orden de pago al62si son correctas, da la orden de pago alcontable, que hace la transferenciaefectiva.PagosProveedor Encargado ContableFacturar[Factura][Pedidos Ptes.]Control facturas[Orden de pago] Pagodias 1, 10, 20A ctor externo63[Transferencia]Escenarios y casos de usoLas actividades representan los requisitosfuncionales… pero no están detalladasLos escenarios son descripciones de cómo sel á l l á ( l64utilizará el sistema en la práctica (completano sustituyen los requisitos funcionales)Las personas comprenden mejor lossupuestos que presentan situaciones en lasque se interacciona con el sistemaCasos de UsoLos casos de uso son una técnica deescenarios incorporada en UML que describela interacción entre los actores y el sistema65Un conjunto de casos de uso describe todaslas posibles interacciones con el sistemaDescriben lo que puede ir mal y cómomanejar el problemaRequisitos de InformaciónSe trata, aquí, de recopilar todos losdatos con los que trabaja laorganización y que soportaninformación66informaciónHay que distinguir muy claramente loque es documento (es soporte deinformación) de lo que es dato (es lainformación)
  12. 12. 12Documento y datosImporte: 999.999Fecha 99/99/99XXXXXXXXXXXCIF 99999999Factura Ref. : XXX67Iva: 999.999Total: 999.999Nombre del proveedorCIF del proveedorNúmero de referenciaFecha facturaImporte facturaIVA facturaTotal facturaDiccionario de DatosNombre Nombre ProveedorDefinición Es el nombre del proveedor que suministra losproductos.Estructura Cadena de 40 caracteres alfanuméricos.Tipo Elemental68Tipo ElementalCuantificación ~ 100Ejemplos Coca-Cola, Carrefour,...Comentarios Problemas de duplicaciónrestriccioneslista de valoresreglas de cálculo (si el dato es calculado)controlesvarias definiciones (sinónimos, polisemias)2.4 Validación y gestión derequisitosValidación de requisitosSe trata de demostrar que los requisitosdefinen el sistema que el cliente realmentedeseaL d l l i i70Los costes de los errores en los requisitos sonaltos; la validación es muy importanteLa detección de un error de los requisitos despuésde la entrega del producto puede llegar a costarhasta 100 veces el coste de la detección de unerror en la implementaciónControles sobre los requisitosValidez.¿El sistema proporciona las funciones quesoportan las necesidades de los clientes?C l t71Completos.¿Están recogidas todas las funciones solicitadas?Consistencia.¿Hay conflictos, contradicciones, en los requisitos?Verificabilidad.¿Pueden comprobarse los requisitos?Controles sobre los requisitosComprensibilidad.¿Se ha comprendido adecuadamente el requisito?Trazabilidad.¿El origen del requisito está claramentee t ble ido?72establecido?Adaptabilidad.¿Se puede cambiar el requisito sin un granimpacto en otros requisitos?Realismo.¿Pueden implementarse los requisitos con latecnología y conocimientos actuales?
  13. 13. 13Gestión de los requisitosLa gestión de los requisitos es el proceso demanejar los requisitos que cambian duranteel desarrollo del sistemaLos requisitos son, inevitablemente,inconsistentes e incompletos73inconsistentes e incompletosEmergen nuevos requisitos durante el proceso, lasnecesidades del negocio cambian, hay una mejorcomprensión del sistemaDiversos puntos de vista afloran diversosrequisitos que pueden ser contradictoriosPlanificación de la gestión de losrequisitosDurante el proceso de la ingeniería derequisitos, hay que planear:La identificación de los requisitos74Un proceso de gestión de los cambiosPolíticas de trazabilidadLa cantidad de información sobre las relaciones entre losrequisitos que se mantieneSoporte de herramientas CASELa herramienta de soporte necesaria para ayudar amanejar los requisitos que cambianTrazabilidadSe refiere a las relaciones entre los requisitos,sus fuentes y el diseño del sistemaTrazabilidad de las fuentesEnlace desde los requisitos a los participantes que75q p p qlos propusieronTrazabilidad entre requisitosEnlace entre requisitos dependientesTrazabilidad del diseñoEnlace desde los requisitos al diseñoTrazabilidad76Soporte de herramientas CASEAlmacenamiento de los requisitosLos requisitos se deben almacenarse en unalmacén seguroGestión de los cambios77Gestión de los cambiosGestión de la trazabilidadRecuperación automatizada de los enlacesentre los requisitos2.5 El documento derequisitos
  14. 14. 14El documento de requisitosEl documento de requisitos es la declaraciónoficial de lo que se necesita construir. Sedenomina Documento de Especificación deRequisitos del Software (ERS)Incluye tanto los requisitos del usuario como79Incluye tanto los requisitos del usuario comola especificación detallada de los requisitosdel sistema.NO es un documento de diseño:Debe indicar QUÉ es lo que el sistema debe hacer.No debe indicar CÓMO va a hacerlo.Características de una ERSNo ambigua.Completa.Fácil de verificar.C i t t80Consistente.Fácil de modificar.Facilidad para identificar el origen y lasconsecuencias de cada requisito.Facilidad de utilización durante la fase deexplotación y mantenimiento.Estándar IEEE para la ERSIntroducciónDescripción generalRequisitos específicos.Cubren los requisitos funcionales, no funcionales y deinterfaz.81Documentan las interfaces externas, describen lafuncionalidad y el rendimiento del sistema, detallan losrequisitos lógicos de la base de datos, las restricciones deldiseño, las propiedades emergentes del sistema y lascaracterísticas de calidad.ApéndicesÍndiceEstructura del Documento deRequisitos (1)1 Visión1.1 Introducción:Ámbito y alcance del Proyecto. Describe la necesidad de crear elsistema, las funciones y cómo trabajará con otros sistemas.1.2 Participantes en el proyectoTanto desarrolladores de software como clientes y usuarios821.3 Objetivos del sistemaLos usuarios (y los sistemas externos) necesitan un sistema parasatisfacer sus objetivos1.4 Visión general del productoPresenta una visión global de alto nivel de la arquitectura previstadel sistema[1.5 Glosario de términos]Define los términos técnicos utilizados en el documento.2 Resumen de entrevistasEstructura del Documento deRequisitos (2)3 Catálogo de requisitos del sistemaServicios que se proveen al usuario y los requisitos no funcionales delsistema3.1 Requisitos funcionales3.1.1 Diagrama de casos de uso3 1 2 Definición de actores833.1.2 Definición de actores3.1.3 Casos de uso del sistema3.2 Requisitos no funcionales3.3 Requisitos de informaciónDiccionario de datos3.4 Reglas de negocio (Requisitos del dominio )Restricciones impuestas[4 Matrices de rastreabilidad]5 Modelo del DominioModelo inicial de clasesEjemplo Larman: Visión1.1 Introducción:Prevemos una aplicación de punto de venta (PDV) tolerantea fallos de próxima generación, PDV NuevaEra, conflexibilidad para poder soportar variación en las reglas delnegocio del cliente, múltiples mecanismos de terminal einterfaz de usuario, y la integración con múltiples sistemas84interfaz de usuario, y la integración con múltiples sistemasde terceras partes.Oportunidad del negocio:Los productos PDV existentes no son adaptables al negociodel cliente, ... Además, no permiten su extensión de maneraadecuada cuando se incrementan los terminales y crece elnegocio. Y ninguno permite trabajar en línea odesconectados, adaptándose dinámicamente dependiendode los fallos. ...
  15. 15. 15Ejemplo Larman: Visión1.2 Participantes en el proyectoDescripción del personal involucradoEntrevistas:Resumen del personal involucrado (No usuarios)...Resumen de Usuarios...1 3 Objetivos del sistema851.3 Objetivos del sistemaObjetivo de alto nivel: “El sistema deberá procesar lasventas de modo rápido, robusto e integrado”Objetivos secundarios: Los usuarios (y los sistemasexternos) necesitan un sistema para satisfacer sus objetivos:Cajero: procesar las ventas, gestionar las devoluciones, abrir ycerrar caja.Administrador del sistema: gestionar los usuarios, gestionar laseguridad, ...Director: poner en marcha, suspender operación.Sistema de actividad de ventas: analizar los datos de lasventas....Ejemplo Larman: Visión1.4 Visión general del productoEl PDV NuevaEra residirá, normalmente, en tiendas; si seutilizan terminales móviles se encontrarán muy próximos ala red de la tienda, en el interior o en el exterior.Proporcionará servicios al usuario, y colaborará con otrossistemas86Ejemplo Larman: VisiónResumen de las características del sistemaEntrada de ventas.Autorización de pagos (crédito, débito, cheque).Administración del sistema de usuarios, seguridad, código ytablas de constantes, etcProcesamiento automático de ventas sin conexión cuandofallen los componentes.87pTransacciones en tiempo real, basadas en estándaresindustriales, con sistemas de terceras partes, que incluye losservicios de inventario, contabilidad, recursos humanos,impuestos, y autorización de pagos.Ejemplo Larman: Visión1.5 Glosario de términosArtículoUn artículo o servicio en venta.Autorización de pagoValidación llevada a cabo por un servicio externo de autorizaciónde pago, que hará o garantizará el pago al vendedor.88Solicitud de autorización de pagoUn compuesto de elementos enviados electrónicamente a unservicio de autorización, normalmente como un array decaracteres. Los elementos comprenden: ID de la tienda, número decuenta del cliente, cantidad y fecha.Código Universal de ProductoCódigo de 12 dígitos que identifica un artículo. Normalmente serepresenta mediante un código de barras en los artículos. Diríjase ahttp://www.uc-council.org para ver más detalles.Ejemplo Larman: Catálogo derequisitos del sistema3.1 Requisitos funcionales3.1.1 Diagrama de casos de uso3.1.2 Definición de actores3.1.3 Casos de uso del sistema893.2 Requisitos no funcionales3.3 Requisitos de información3.4 Requisitos del dominioEjemplo Larman: Catálogo derequisitos del sistema3.2 Requisitos no funcionalesSeguridadTodo uso requiere la autenticación de los usuarios.NFR-0001 SeguridadVersión 1 0 ( 18/10/2006 )90Versión 1.0 ( 18/10/2006 )Autores •Craig LarmanFuentes •CajeroDependencias • [OBJ-0001] Procesamiento de ventasDescripción El sistema deberá requerir la autenticación de losusuarios.Importancia vitalUrgencia inmediatamente
  16. 16. 16Ejemplo Larman: Catálogo derequisitos del sistema3.2 Requisitos no funcionalesFacilidad de usoEl cliente será capaz de ver la información en un gran monitor del PDV.Se debe ver el texto fácilmente a una distancia de 1 metro. El cajeroestá mirando a menudo al cliente o los artículos, no a la pantalla delordenador. Por tanto, se deben comunicar las señales y avisos consonidos, en lugar de sólo mediante gráficos.91so dos, e uga de só o ed a te g á cosFiabilidadCapacidad de recuperaciónSi se produce algún fallo al usar un servicio externo (autorización depago, sistema de contabilidad,...) intentar solucionarlo con unasolución localRendimientoComo se mencionó en los factores humanos, los compradores quierencompletar el proceso de ventas muy rápido. Un cuello de botellapotencial es la autorización de pagos externa. El objetivo es conseguirla autorización en menos de 1 minuto, el 90% de las vecesEjemplo Larman: Catálogo derequisitos del sistema...3.2 Requisitos no funcionalesRestricciones de ImplementaciónLa dirección de NuevaEra insiste en una solución utilizando lastecnologías JavaComponentes adquiridos92p qEl sistema de cálculo de impuestos. Debe soportar sistemas decálculo conectables de diferentes países.Interfaces hardwareMonitor con pantalla táctilEscáner láser de código de barrasImpresora de recibosLector de tarjetas de crédito/débitoLector de firmas (pero no en la primera versión)Ejemplo Larman: Catálogo derequisitos del sistema3.3 Requisitos de informaciónIRQ-0001 productoDescripción El sistema deberá almacenar lainformación correspondiente aproducto. En concreto:93Datos específicos•código universal de producto•nombre del producto•precio unitario del productoTiempo de vida Medio Máximo8 mes(es) 5 año(s)Ocurrencias simultáneas Medio Máximo400 1000Importancia vitalEjemplo Larman: Catálogo derequisitos del sistema3.4 Reglas del negocioREGLA 1, firmaSe requiere la firma para pagos a crédito. Lapolítica de las compañías de autorización de crédito.94CRQ-0001 pagos firmadosVersión 1.0 ( 18/10/2006 )Dependencias NingunoDescripción La información almacenada por el sistema deberásatisfacer la siguiente restricción: se requiere lafirma del cliente para pagos a crédito.Importancia PDUrgencia PDEjemplo Larman: Catálogo derequisitos del sistema3.4 Reglas del negocioREGLA 2, impuestosHay que añadir el IVAREGLA 3, devoluciones95Las devoluciones de los pagos a crédito sólo puedenefectuarse como crédito en las cuentas de crédito de loscompradores, no en efectivo. La política de lascompañías de autorización de créditoREGLA 4, Fijación de preciosLos artículos tienen un precio original, y opcional mente,un precio rebajado.Bibliografía RecomendadaSommerville, I. "Ingeniería del software" Pearson, 2005 (7ª ed.)Larman, C. “UML y Patrones. Introducción al Análisis y DiseñoOrientado a Objetos y al Proceso Unificado ”. Prentice Hall, 2004. cap.4, 5 y 7.Lecturas complementarias96Lecturas complementariasPressman, Roger S. "Ingeniería del software : un enfoque prácticoMacGraw-Hill", 2005 (6ª ed) Pressman, Roger S. "Ingeniería delsoftware : un enfoque práctico MacGraw-Hill", 2005 (6ª ed)Amador Durán Toro, Beatriz Bernárdez Jiménez, "Metodologíapara la Elicitación de Requisitos de Sistemas Software", Versión 2.3,Informe Técnico LSI–2000–10 (revisado), Universidad de Sevilla

×