Your SlideShare is downloading. ×
El Documento de Requerimientos¿De qué trata el Documento de Requerimientos?¿Para qué sirve?¿Qué diferencia tiene este docu...
LaFHIS - Uchitel 3¿Para qué sirve un SRS?• Comunicar de manera precisa los requerimientos, objetivos ypresunciones del dom...
LaFHIS - Uchitel 5Más lectores de un SRS• Equipo de Operaciones– Deberán dimensionar equipos y procedimientos de rutina.• ...
LaFHIS - Uchitel 7Adaptado de IEEE-STD-830Contenido de un SRS• Un SRS deberá abarcar:– Funcionalidad. Que es lo que el sof...
LaFHIS - Uchitel 9IEEE STD Sección 3 (ejemplo)3.1 External InterfaceRequirements3.1.1 User Interfaces3.1.2 Hardware Interf...
LaFHIS - Uchitel 11Cualidades de un SRS (1)• Completitud– con respecto a los objetivos (ver Jackson):• Req, Dom |= G• Corr...
LaFHIS - Uchitel 13Cualidades de un SRS (3)• Precisión (No ambiguo)– No hay vocabulario ambiguo: cada término está definid...
LaFHIS - Uchitel 15Contraejemplos (1)• Omisión de objetivos y requerimientos faltantes– No hay un requerimiento sobre esta...
LaFHIS - Uchitel 17Contraejemplos (3)• Poca Modificabilidad– Uso de literales para valores cuantificables.• Opacidad– Un r...
LaFHIS - Uchitel 19Una complicación: Contratación• ¿Cuándo licitar/contratar?– Temprano (etapa conceptual)• sólo se pueden...
LaFHIS - Uchitel 21Resumen• Documento de Especificación deRequerimientos– Propósitos y audiencias– Cualidades esperadas, e...
LaFHIS - Uchitel 23¿Qué es un Modelo?• Una descripción (de un problema o solución)...– precisa– abstracta– manipulable for...
LaFHIS - Uchitel 25Lenguaje Natural• La técnica más popular• Ventajas– No hay límite en cuanto a poder expresivo– No hay u...
LaFHIS - Uchitel 27Lenguaje Natural Controlado• Restricciones gramaticales y de presentaciónque buscan forzar el uso de te...
LaFHIS - Uchitel 29Ejemplo: Estructura Gramatical• Especificación de requerimientos debe tener lasiguiente estructura:– Lo...
LaFHIS - Uchitel 31Tablas de Decisión“El sistema reportará al operador todas las fallas que se originanen funciones crític...
LaFHIS - Uchitel 33Diagramas: Árboles de DecisiónOrigen en funciones críticasOcurre durante ejecuciónde secuencia críticaN...
LaFHIS - Uchitel 35Diagramas: SADT• “Structured Analysis and Design Technique” (Ross & Schoman, 1977)• Precursor en diagra...
LaFHIS - Uchitel 37SADT: Algunas Observaciones• Diagramas semánticamente ricos (ej. más que DFDs)– Distingue responsables,...
LaFHIS - Uchitel 39Diagramas Estructurales del Dominio• Ej. Diagramas de clase, modelos entidad relación• Conceptos: Entid...
LaFHIS - Uchitel 41Diagramas de Transición de Estados• Conceptos: Estados, Eventos, Guardas y TransicionesRecolectando Dat...
LaFHIS - Uchitel 43Especificaciones Formales- Lógica de Primer Orden -• Sintaxis– Operadores booleanos (disyunción, conjun...
LaFHIS - Uchitel 45Especificaciones Formales• Beneficios– Tienden a facilitar la reducción de problemas clásicos deespecif...
Upcoming SlideShare
Loading in...5
×

3. dercas -_el_documento_de_requerimientos

1,373

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,373
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
56
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "3. dercas -_el_documento_de_requerimientos"

  1. 1. El Documento de Requerimientos¿De qué trata el Documento de Requerimientos?¿Para qué sirve?¿Qué diferencia tiene este documento con un modelo?¿Qué técnicas de documentación pueden usarse?¿Cuáles son sus limitaciones?Unidad 3LaFHIS - Uchitel 2elicitacióny modeladoespecificaciónstakeholdersdocumentossistemasexistentesanálisisy validaciónModelos de RequerimientosDocumento deRequerimientosnegociación ypriorizaciónDocumento de RequerimientosEn la práctica es común describir los requerimientos en un documentollamado Especificación de Requerimientos del Software (SRS -Software Requirements Specification)
  2. 2. LaFHIS - Uchitel 3¿Para qué sirve un SRS?• Comunicar de manera precisa los requerimientos, objetivos ypresunciones del dominio• Contrato– legal, documento interno o a modo de memorando• Base para estimación (tamaño, costo, tiempo) y planificación deproyecto• Base para evaluación de producto final– verificación y validación– Debería tener suficiente información para decidir si el producto final es aceptable(satisface los requerimientos)• Base para el control de cambios– Requerimientos cambian, software evoluciona, el entorno evolucionaLaFHIS - Uchitel 4Lectores de un SRS• Clientes y Usuarios– Interesados en validar objetivos del sistema y descripción de alto nivel de lafuncionalidad– Generalmente no interesados en los requerimientos detallados del sistema.• Analistas (de sistemas, de requerimientos),– Escribirán especificaciones de otros sistemas que interactúan con este.– El SRS sirve mas allá de la puesta en producción!• Desarrolladores (ej. arquitectos, diseñadores,programadores, ...)– Deben implementar los requerimientos• Testers (V&V’ers)– Deben determinar la satisfacción de los requerimientos• Gerentes– Medir y controlar el proceso desarrollo
  3. 3. LaFHIS - Uchitel 5Más lectores de un SRS• Equipo de Operaciones– Deberán dimensionar equipos y procedimientos de rutina.• Equipo de soporte de usuario– Desarrollo de plan de capacitación– Generación de manuales de usuario– Procedimientos de soporte online• Legales– Los que firman los contratos• Subcontratistas• Entes reguladores• ...¿Cómo se escribe un documento que lesirva a una audiencia tan variada?LaFHIS - Uchitel 6¿Qué es un SRS apropiado?• Consideremos dos proyectos:A) Proyecto chico, 1 programador, 6 meses de trabajoprogramador habla con el cliente y escribe un memo de 5 hojasB) Proyecto grande, 50 programadores, 2 años de trabajoUn equipo de analistas modelan los requerimientos y luego losdocumentan en un SRS de 500 paginas
  4. 4. LaFHIS - Uchitel 7Adaptado de IEEE-STD-830Contenido de un SRS• Un SRS deberá abarcar:– Funcionalidad. Que es lo que el software hace?– Interfases externas. Como debe interactuar con gente, con elhardware del sistema, con demás hardware y con demássoftware?– Atributos de Calidad.• Disponibilidad, tiempo de respuesta, tiempo de recuperacióndespués de fallas, etc..• Consideraciones de portabilidad, correctitud, precisión,mantenibilidad, seguridad y mas...– Restricciones de diseño. Existen estándares a cumplir,lenguaje de programación, recursos, sistemas operativos,etc...?LaFHIS - Uchitel 81 IntroductionPurposeScopeDefinitions, acronyms,abbreviationsReference documentsOverview2 Overall DescriptionProduct perspectiveProduct functionsUser characteristicsConstraintsAssumptions and Dependencies3 Specific RequirementsAppendicesIndexStandard de IEEE para un SRS1 IntroductionPurposeScopeDefinitions, acronyms,abbreviationsReference documentsOverview2 Overall DescriptionProduct perspectiveProduct functionsUser characteristicsConstraintsAssumptions and Dependencies3 Specific RequirementsAppendicesIndexIdentifica el producto yel dominio de la aplicaciónDefine el contenido y estructuradel resto del documentoDescribe todas las interfaces externas:sistema, usuario, hardware, softwareResumen de funcionesprincipalesCualquier cosa que limitará lasopciones del desarrollador (ej.regulaciones, limitaciones dehardware, etc)La parte principal del documento. IEEESTD provee 8 esqueletos diferentespara esta secciónAdaptado de IEEE-STD-830
  5. 5. LaFHIS - Uchitel 9IEEE STD Sección 3 (ejemplo)3.1 External InterfaceRequirements3.1.1 User Interfaces3.1.2 Hardware Interfaces3.1.3 Software Interfaces3.1.4 Communication Interfaces3.2 Functional Requirementsthis section organized by mode, userclass, feature, etc. For example:3.2.1 User Class 13.2.1.1 Functional Requirement 1.1…3.2.2 User Class 23.2.1.1 Functional Requirement 1.1…...3.3 PerformanceRequirements3.4 Design Constraints3.4.1 Standards compliance3.4.2 Hardware limitationsetc.3.5 Software SystemAttributes3.5.1 Reliability3.5.2 Availability3.5.3 Security3.5.4 Maintainability3.5.5 Portability3.6 Other RequirementsLaFHIS - Uchitel 10Ejemplos de Organización de Requerimientos Funcionales- Sección 3.2. -• …Estímulo o estado del mundo externo– ej. Soporte de aterrizaje de aviones: viento, poca nafta, pista corta,...• …Funcionalidad de alto nivel (top-down)– ej. llamado en espera, desvío de llamado, llamado en conferencia,contestador...• …Output del sistema– ej. generar recibos de sueldo, reportes de costo, estado de cuentas...• …Objeto externo– ej. para una biblioteca, organizar por tipo de libro• …Tipo de usuario– ej. Sistema de admin. de proyectos: gerente, técnicos, admines, ...• …Modo de operación– ej. un procesador de palabras: page layout, outline, normal, ...• …Subsistema– ej. Auto: control, manejo de datos, comunicaciones, entretenimientos, ...
  6. 6. LaFHIS - Uchitel 11Cualidades de un SRS (1)• Completitud– con respecto a los objetivos (ver Jackson):• Req, Dom |= G• Correspondencia entre el mundo real y G,• Correspondencia entre el mundo real y Dom• Completitud de G con respecto al mundo real– con respecto a inputs: el comportamiento requerido delsoftware ha sido especificado para todos los inputs posibles.– con respecto a estructura: no hay secciones rotuladas: “Acompletar...”LaFHIS - Uchitel 12Cualidades de un SRS (2)• Pertinencia– Cada requerimiento y presunción se necesita para lasatisfacción de objetivo– El SRS no contiene elementos que no están relacionados conla definición de requerimientos (ej. decisiones de diseño oimplementación)• Consistencia– No hay contradicciones en la formulación de objetivos,requerimientos y presunciones• “Medibilidad”– Los requerimientos han sido formulados de manera tal que susatisfacción pueda ser evaluada de manera no ambigua
  7. 7. LaFHIS - Uchitel 13Cualidades de un SRS (3)• Precisión (No ambiguo)– No hay vocabulario ambiguo: cada término está definido y esusado consistentemente.– No hay aserciones ambiguas: Objetivos, requerimientos ypresunciones deben estar escritos de manera tal que nopermiten interpretaciones distintas– No hay responsabilidades ambiguas: la separación deresponsabilidades entre el mundo y el software debe estarindicado claramente.• Factibilidad– Los objetivos y requerimientos deberían ser realizablesdentro del presupuesto y cronogramas dispuestosLaFHIS - Uchitel 14Cualidades de un SRS (4)• “Entendibilidad”– debe ser entendible por todos los lectores potenciales.• Trazabilidad– debe identificar las fuentes de los objetivos, requerimientos, ypresunciones– debe relacionar requerimientos y presunciones con los objetivos– debe facilitar referenciar de requerimientos en documentaciónfutura (diseño, test, casos de test)• Buena Estructura– Ítems definidos antes de ser usados, índices, formateo, etc...• Modificabilidad– Debe ser fácil de adaptar, extender, o achicar con modificacioneslocales.– Impacto de modificar un ítem debería ser fácil de estimar
  8. 8. LaFHIS - Uchitel 15Contraejemplos (1)• Omisión de objetivos y requerimientos faltantes– No hay un requerimiento sobre estado de las puertas en casode emergencia• Omisión de una reacción a un input– Qué pasa si la alarma de emergencia es activada mientras laspuertas se cierran• Requerimientos inadecuados– “Si un libro no es devuelto a la semana del tercer aviso dedevolución, el usuario negligente será notificado y deberápagar una multa de x$”vs.– “Si un libro no es devuelto a la semana del tercer aviso dedevolución, x$ serán descontados a modo de multa de la cuentacorriente del usuario.”LaFHIS - Uchitel 16Contraejemplos (2)• Ruido– “Cada vagón estará equipado con un panel de informacióncontrolado vía software y con carteles de prohibido fumar encada ventana”• Relleno– Contenido sin información relevante. Ej. contenido con elobjeto de cumplir estándares.• Mala Estructura– Mezclar proceso de compra y préstamo de libros– Referencias hacia adelante: Múltiples usos de “participante”para luego introducir la definición de participante.– Definiciones incidentales: “El sistema enviará minutas a losparticipantes (aquellos que asistieron aunque sea parcialmente)de la reunión.
  9. 9. LaFHIS - Uchitel 17Contraejemplos (3)• Poca Modificabilidad– Uso de literales para valores cuantificables.• Opacidad– Un requerimiento como:“el comando de velocidad del tren deberá ser siempre al menos12kph por encima de la velocidad real del tren”sin información contextual de por qué, la fuente y el impactosobre otros requerimientos.• No medibilidad– Los paneles de información serán proveerán información demanera clara y precisaLaFHIS - Uchitel 18Una complicación: Contratación• Un ‘SRS’ puede ser escrito por...– …el contratante:• el SRS sirve para llamar a licitación• Debe ser suficientemente general para lograr suficientes pliegos…• … y suficientemente específico para obviar pliegos no razonables.– …los proveedores potenciales:• Representa una propuesta para implementar un sistema que satisfaga algúnllamado a propuestas.• Debe ser suficientemente especifico para demostrar factibilidad ycompetencia técnica...• …pero suficientemente general para no comprometerse demasiado.– …el desarrollador seleccionado:• refleja el entendimiento que tiene el desarrollador de las necesidades delcliente.• forma la base de una evaluación contractual de la performance deldesarrollador.– …o por un con consultor independiente en IR.
  10. 10. LaFHIS - Uchitel 19Una complicación: Contratación• ¿Cuándo licitar/contratar?– Temprano (etapa conceptual)• sólo se pueden evaluar las propuestas sobre la aparentecompetencia técnica– Tarde (etapa de especificación de requerimientosdetallados)• mas trabajo para el contratante; experiencia en IR nonecesariamente existe dentro de la organización– IEEE recomienda que el SRS sea desarrolladoconjuntamente por el contratante y el desarrolladorLaFHIS - Uchitel 20Algunas Observaciones• El SRS será imperfecto– contendrá inconsistencias y imprecisiones– omitirá información, hará simplificaciones• Mejorar la especificación tal vez no sea efectivo (costovs. beneficio)– Análisis de requerimientos tiene un costo– Para diferentes proyectos, el costo-beneficio es diferente.• Análisis reduce el riesgo de que las imperfeccionescausen problema serios.• Estas son muchas veces malas excusas para no invertiren Ingeniería de Requerimientos
  11. 11. LaFHIS - Uchitel 21Resumen• Documento de Especificación deRequerimientos– Propósitos y audiencias– Cualidades esperadas, errores y falencias– Dificultades inherentes a la construcción de un SRSde calidad– Concepciones erróneas sobre el SRS– ContrataciónLaFHIS - Uchitel 22Una Observación Importante• Siendo el SRS el entregable más importante,suele tomar un protagonismo desproporcionado– El SRS no es el fin último de un proceso de IR• Entendimiento del dominio de aplicación, identificación losproblemas reales existentes, elaboración los sistemas quelos resuelven, etc..– El SRS no es el único soporte físico a producir• También los modelos juegan un rol– El SRS no se comienza a escribir el primer día.• Hay muchas actividades previas a la generación de la primerversión de un SRS– El SRS no es el elemento central para hacer análisis• Más bien es un documento de referencia, enciclopédico.
  12. 12. LaFHIS - Uchitel 23¿Qué es un Modelo?• Una descripción (de un problema o solución)...– precisa– abstracta– manipulable formalmente– interpretable en el mundo real• Una descripción cuyo fin es lograr mayorentendimiento• Una entidad que puedo– observar desde múltiples ángulos– Hacerle preguntas (y obtener respuestas)El Documento de Requerimientos¿De qué trata el Documento de Requerimientos?¿Para qué sirve?¿Qué diferencia tiene este documento con un modelo?¿Qué técnicas de documentación pueden usarse?¿Cuáles son sus limitaciones?Unidad 3
  13. 13. LaFHIS - Uchitel 25Lenguaje Natural• La técnica más popular• Ventajas– No hay límite en cuanto a poder expresivo– No hay una barrera evidente de comunicación.– Ningún entrenamiento especial es necesario• Limitaciones:– Falta de estructura favorece ruido, referencias futuras,opacidad, definiciones incidentales, ...– Información específica puede ser difícil de encontrar– Ambigüedad : ”Frenado total será activado por cualquier trenque recibe un comando de aceleración o que entra al sector deestación a mas de X kmh y cuando el tren que lo precede está amenos de Y metros”– Análisis automatizado es imposible– Provee poco soporte metodológicoLaFHIS - Uchitel 26Algunas Recomendaciones Generales• Existen muchas recomendaciones generales orientadas a mejorarla calidad de una especificación en lenguaje natural. Ejemplos:– Oraciones cortas– No incluir en una oración mas de un requerimiento o presunción– Evitar acrónimos– Usar ecuaciones para relacionar información cuantitativa– Usar ejemplos para clarificar aserciones abstractas– Introducir un glosario/diccionario de datos para tener referencias einterpretaciones únicas y concisas, además de precisión técnica– Evitar combinaciones complejas de condiciones (ej. anidamiento yasociatividad ambigua)– Introducir figuras para proveer pantallazos– Ayudar texto con diagramas• No proveen una forma rigurosa de atacar los problemas de fondo
  14. 14. LaFHIS - Uchitel 27Lenguaje Natural Controlado• Restricciones gramaticales y de presentaciónque buscan forzar el uso de texto simple con elobjeto de– aumentar entendibilidad– reducir ambigüedad– permitir algunos análisis simples de maneraautomática– reducir el uso inconsistente de términosLaFHIS - Uchitel 28Ejemplo: Indentación• El sistema proveerá información comparativa que es oportuna,itemizada en suficiente detalle como para que variacionesindividuales de importancia no se pierdan entre otras variaciones,identificación de la fuente de cada variación sea posible, y seaidentificable el área de investigación que maximizará losbeneficios globalesvs.• El sistema proveerá información comparativa– La información comparativa será oportuna,– La información comparativa será itemizada en suficiente detalle comopara que• Variaciones individuales de importancia no se pierdan entre otrasvariaciones,• Identificación de la fuente de cada variación sea posible• Sea identificable el área de investigación que maximizará los beneficiosglobales
  15. 15. LaFHIS - Uchitel 29Ejemplo: Estructura Gramatical• Especificación de requerimientos debe tener lasiguiente estructura:– Localización– Actor– Acción– Objeto/Dueño– Restricción.• Ejemplo: Cuando tres o más seguidores de estrellaspierden su estrella de referencia, la naveinmediatamente alineará su eje principal con el eje sol-tierra salvo que la tapa de los instrumentos ópticos nose encuentre abiertaLaFHIS - Uchitel 30Ejemplo: Templates/Plantillas• Cada aserción deberá ser estructurada con lossiguientes campos:– Identificador– Categoría– Especificación– Criterio de aceptación– Fuente– Justificación– Interacción (positiva/negativa) con otras aserciones– Prioridad– ...
  16. 16. LaFHIS - Uchitel 31Tablas de Decisión“El sistema reportará al operador todas las fallas que se originanen funciones críticas o que ocurren durante la ejecución de unasecuencia crítica y para las cuales no existen respuestas derecuperación de fallas.”(adaptado de la especificación de la base espacial internacional)TTTFFFFFReportar a Operador?TTTTFFFFNo hay respuesta de recuperación de fallasTTFFTTFFOcurre durante ejecución de secuencia críticaTFTFTFTFOrigen en funcione críticaLaFHIS - Uchitel 32Diagramas y Modelos Gráficos• Altamente estructurados• Permiten análisis automáticos superficiales– Eg. Reglas de consistencia sintáctica• Facilitan comunicación aunque requieren distintos grados decapacitación previa• Proveen descripciones concisas y abstractas• Se complementan en cuanto a foco– Lógica de control– Flujo de datos– Flujo de control– Estructura– Estados y cambios de estado– Comunicación– ...
  17. 17. LaFHIS - Uchitel 33Diagramas: Árboles de DecisiónOrigen en funciones críticasOcurre durante ejecuciónde secuencia críticaNo hay respuesta derecuperación de fallasFTFNo Reportara OperadorNo Reportara OperadorTNo hay respuesta derecuperación de fallasReportar aOperadorF TNo Reportara OperadorReportar aOperadorF TLaFHIS - Uchitel 34Diagramas: Flujo de Datos (DFDs)• Modelado de operaciones del sistema y sus dependencias de datos– Operaciones modifican datos. Sus inputs y outputs son declarados conflechas entrantes y salientes– Componentes son iniciadores o terminadores de flujos de datos• Error común: Inferir control de flujo a partir del de datosIniciadorParticipante ParticipanteVerificarpedidoConsultarrestriccionesRecolectarrestriccionesFusionarrestriccionesFijarcronogramaRestricciones departicipantesPedido dereuniónCopia derestriccionesPedidoinválidoPedidoválidoRestriccionespara la reuniónPedido derestriccionesRestriccionespersonalesNotificaciónde reunión
  18. 18. LaFHIS - Uchitel 35Diagramas: SADT• “Structured Analysis and Design Technique” (Ross & Schoman, 1977)• Precursor en diagramas para requerimientos• Dos diagramas que son vistas duales/complementarias entre siActividadDatos deentradaDatosde salidaComponenteresponsableDatos y eventosde controlDatosActividadesproductorasActividadesconsumidorasRecursos necesariospara procesamientoActividades de controlde integridadActigram DatagramLaFHIS - Uchitel 36Ejemplo SADTGestionar derestriccionesConsultarrestricciones Informar derestriccionesFusionar derestriccionesPedido de reuniónRestriccionespara reuniónRango defechasRango defechasPedido dereuniónSchedulerPedido derestriccionesParticipanteRestriccionespersonalesSchedulerRestriccionespara reuniónplazomáximotodas lasrestriccionesrecibidasRango defechasRestriccionespara reuniónFusionar de restriccionesPlanificar reuniónRepositorio de restriccionesControlar validez
  19. 19. LaFHIS - Uchitel 37SADT: Algunas Observaciones• Diagramas semánticamente ricos (ej. más que DFDs)– Distingue responsables, dato, restricciones de integridad, etc...• Criterios de consistencia inter-diagrams.– Ej. Una actividad del control de un datagrama debe aparecer comoactividad en un actigrama• Noción de refinamiento gráfico– Los datos de E/S de una actividad deben aparecer como E/S dealguna sub-actividad• Diagramaticamente deficientes– Dirección absoluta de flechas (o posición absoluta de elementos) sueleno tener relevancia semántica en diagramas modernosLaFHIS - Uchitel 38Iniciador Scheduler Participantepedido de reuniónnotificaciónpedido de restriccionesnotificaciónrestricciones personalesDiagrama de Contexto• Visto previamente...
  20. 20. LaFHIS - Uchitel 39Diagramas Estructurales del Dominio• Ej. Diagramas de clase, modelos entidad relación• Conceptos: Entidades y Relaciones entre entidades (asociaciones,subclases, etc)LaFHIS - Uchitel 40Diagramas de Secuencia• Conceptos:– Tiempo, comunicación o interacción entre agentes– Descripción basada en ejemplos.
  21. 21. LaFHIS - Uchitel 41Diagramas de Transición de Estados• Conceptos: Estados, Eventos, Guardas y TransicionesRecolectando Datosde ReuniónPedido DenegadoValidando Datosde ReuniónRestriccionespedidasPlanificando Reunión planificadaReunión notificadaResolución deconflictos[no autorizado][autorizado]pedido OKpedido KO[todas disponibles][hayconflictos]pedido de debilitar restricciones[no hayconflictos]cronogramafijadonotificaciónLaFHIS - Uchitel 42Descripciones Gráficas: Limitaciones• No describen cual es el propósito. Se quedan en el “qué” y “cómo”• Requerimientos implícitos– Justificación de requerimientos implícita o inexistente– Relación entre requerimientos implícita• Falta de distinción entre descripción y prescripción• Imposibilidad de representar múltiples opciones• Poca guía para el análisis y elaboración– ¿Criterios de verificación y validación? ¿Grado de completitud?¿Las descripciones gráficas que hemos visto,son adecuadas para describir requerimientos?
  22. 22. LaFHIS - Uchitel 43Especificaciones Formales- Lógica de Primer Orden -• Sintaxis– Operadores booleanos (disyunción, conjunción, negación, implicación)– Variables tipadas– Cuantificación universal y existencial sobre el universo de instancias– Predicados booleanos y Funciones• Ejemplo– !tr1, tr2: Tren: SigueA(tr1, tr2) -> Dist(tr1, tr2) < Dist-Frenado(tr1)– SigueA(tr1, tr2) " tr1.via() = tr2.via() && tr1.dirección = tr2.dirección– DistFrenado(tr) " ....tr1.velocidad()....tr1.peso()...., tr.modelo(), ....• Semántica– Dado una valuación para elementos atómicos de la lógica, tenemos unmecanismo preciso para decidir si una fórmula es verdadera• Técnicas de manipulación sintáctica que preserven la semántica– modus ponens, ecadenamiento, instanciación, ...LaFHIS - Uchitel 44Especificaciones Formales- Lógicas Temporales -• Sintaxis– [] P : siempre en el futuro vale P.– <> P : en algún momento en el futuro vale P.– P U Q : siempre en el futuro vale P hasta que valga Q.– X P : En el próximo estado vale P.• Ejemplos– Presunción: “Una persona esperada a una reunión efectivamente participará dela reunión si la fecha y lugar de reunión le es conveniente y ha sido notificadode la reunión”! p: persona, r: reunión: Esperado(p, r) && Notificado(r, m) &&Conveniente(r, p) -> <> Participa(p, r)– Q vale después de que P valga pero antes de que R valga:[] !P || <>(P && !R U (Q || []!R)))• Semántica– Dado una secuencia de valuaciones para elementos atómicos de lalógica, tenemos un mecanismo preciso para decidir si una fórmula esverdadera
  23. 23. LaFHIS - Uchitel 45Especificaciones Formales• Beneficios– Tienden a facilitar la reducción de problemas clásicos deespecificación de requerimientos como• ambigüedad, ruido, referencias a futuro, aserciones no medibles– Proveen mecanismos de análisis más sofisticados: Animación,verificación de correctitud vía deducción o exploración exhaustiva– Permiten la generación automática de contraejemplos, casos de falla,casos de prueba, modelos/vistas alternativas y fragmentos de código– El proceso de formalización puede ayudar a tener un mejorentendimiento informal del problema• Desventajas– Tienen poder expresivo limitado. Ej. aspectos cuantitativos– Son difíciles de escribir y de leer. Obtención de especificacionesconsistentes y adecuadas requiere mucho entrenamiento. Inaccesiblepara clientes, usuarios, etc.– Integración limitada de especificaciones con prácticas convencionalesLaFHIS - Uchitel 46Lo que se viene...• Un modelo que trata de ...– resolver limitaciones y combinar beneficios de algunas de lastécnicas de especificación mencionadas– estructurar conocimiento de una manera alternativa, parafacilitar las actividades de Ingeniería de Requerimientos• ... el modelo de objetivos

×