Clase 3_B

8/18/2019 Clase 3_B

http://slidepdf.com/reader/full/clase-3b 1/31

8/18/2019 Clase 3_B


2

Requisitos del software

Obtención de los requisitos

Síndromes en la obtención de los requisitos

Cuatro son los principales desafíos para el analista de requisitos:

Sí… pero no exactamente así.

¡Vaya!, pues esto no debería ser así.

¿Ya está todo? Usuarios contra desarrolladores

8/18/2019 Clase 3_B


3



¡Vaya!, pues esto no debería ser así.

Este es un problema inherente al desarrollo de software.

Los usuarios no ver el sistema hasta que lo empiezan a usar, y es normalque sea entonces cuando descubran que algunas partes no se adecuanexactamente a sus expectativas.

El software no es físico ni tangible. Al cliente de una vivienda se le puedemostrar una maqueta o un plano. Un proyecto de mobiliario se puededibujar, pero nuestro producto no es físico, es difícil de representar, deconceptualizar de forma concreta y objetiva.

Si el analista de requisitos no comprende bien lo que el cliente necesita,éste se dará cuenta de la disparidad de criterios cuando ya sea tarde,cuando el sistema esté en sus manos; de forma que habremos producidoalgo que no cumple sus expectativas.

Por esta razón, inherente a la intangibilidad del software, la obtención derequisitos es la fase más importante de un desarrollo.

El ingeniero de requisitos debe tener en cuenta que este síndrome es un riesgo consustancial con su trabajo, y que sumisión es anticipase para que al final del desarrollo produzca el menor efecto posible.

Los medios para reducir su efecto son:

Evitar quedarse con las primeras descripciones genéricas. No dar nada por supuesto. Evitar las ambigüedades. Conocer el entorno y las necesidades del cliente. Dedicar esfuerzo y tiempo para la obtención de requisitos, adecuado al tamaño y complejidad del sistema.

8/18/2019 Clase 3_B


4




Este síndrome es similar al anterior, porque tiene el mismo resultado:el descubrimiento tardío por parte del cliente de que determinadaspartes del sistema no solucionan adecuadamente su problema, pero adiferencia del anterior, su origen no está en omisiones oambigüedades en el proceso de obtención, sino en la inmadurez de losprocesos a los que el nuevo sistema debe dar soporte, o en eldesconocimiento o actitud por parte de los interlocutores del cliente.

Aunque tenga el mismo efecto que el síndrome anterior, identificarque tienen causas diferentes interesa en la medida en que requierensoluciones, o formas de trabajo distintas.

El ingeniero de requisitos debe identificar mayores probabilidades deriesgo si en el contexto adquieren relevancia las siguientessituaciones:

El sistema no sustituye o modifica a otro existente, sino que se desarrolla para dar soporte a procesos de negocionovedosos para la organización que lo solicita.

Los interlocutores nombrados por el cliente no son conocedores expertos de los procesos cubiertos por el sistema.

Faltan representantes de partes implicadas por procesos importantes del nuevo sistema.

Escasa implicación del cliente, que por falta de recursos, tiempo o incluso por pereza intelectual no se sienta con elingeniero de requisitos a desmenuzar las particularidades de sus procesos, dando por válidos los requisitos finalmenteobtenidos, sin prácticamente mirarlos.

8/18/2019 Clase 3_B


8/18/2019 Clase 3_B


6




Deberá también aportar asesoría profesional al cliente informándoledel riesgo alto que encierra el proyecto de producir versiones que sedemostrarán inadecuadas para la realidad de sus procesos, y de laconveniencia de profundizar el máximo posible en el conocimiento delos procesos antes de elaborar los requisitos, así como de empleartécnicas de prototipado en la obtención de requisitos, y ciclos dedesarrollo en cascada. Resultan más aconsejables desarrollos

incrementales o evolutivos, con ciclos en espiral y seguimiento porparte del cliente.

Si el analista se encuentra con problemas de comunicación o deactitud por parte del cliente deberá conducir la situación y adaptar suregistro de actuación de forma que sin perder la asertividad, logreestablecer una implicación adecuada del cliente y un flujo decomunicación productivo.

8/18/2019 Clase 3_B




¿Ya está todo?

Cuándo se puede dar por terminado un trabajo?

Cuando ya no queda más por hacer.

¿Cómo sabe el ingeniero de requisitos que ha descubiertotodos los requisitos necesarios?.

Esta incertidumbre es también inherente al trabajo delingeniero de requisitos, porque nunca tendrá la certeza dehaber descubierto todas las necesidades y restricciones, ysobre todo porque siempre puede dar por descontado quealgo se queda sin descubrir.

La única forma de afrontar esta circunstancia es dedicar tiempo suficiente a la obtención y análisis,e identificar a todos los participantes o partes implicadas en el proyecto.

Aunque nunca podrá afirmar haber localizado todos los requisitos, el objetivo en este caso esalcanzar el convencimiento de haber descubierto lo suficiente, y que las posibles omisionespertenecerán a cuestiones menores, que pueden surgir durante la gestión de los requisitos, o a lolargo del mantenimiento del futuro sistema.

8/18/2019 Clase 3_B




Usuarios contra desarrolladores

No es posible saber qué necesita el cliente, si no disponemos decomunicación fluida con los interlocutores de su organización; y pordesgracia es demasiado frecuente que los desarrolladores y losusuarios, se relacionen sobre la base de la desconfianza mutua, yempleen idiomas distintos.

Tanto la actitud de los desarrolladores como la de los usuarios no

suele ser favorable para trabajar unos con otros. Los primerosprefieren concentrar su trabajo en el entorno técnico, y olvidarse de “hablar con los clientes”.Los usuarios, por su parte, esperan su nuevo programa, con la mismaactitud que podrían esperar un coche tras haberlo encargado en elconcesionario.Los analistas y los usuarios pertenecen a dos comunidades que

desconfían mutuamente.

Los usuarios ven a los desarrolladores como personas incapaces de conseguir sistemas que funcionen correctamentesin la necesidad de estar constantemente “parcheándolos”.

Los desarrolladores se ven solos y desamparados como únicos responsables de todo cuando ocurra o tenga relación conel sistema.

Por supuesto, nosotros no esperamos que los usuarios cambien, pero tenemos que conocer estos problemas, y elingeniero de requisitos debe estar preparado para encontrarse con estas dificultades y minimizar sus consecuencias.

Se supone que durante la obtención de los requisitos, tanto los usuarios como los desarrolladores comparten el mismoobjetivo: definir cómo ha de ser el nuevo sistema, pero lo cierto es que cada uno tiene objetivos diferentes.

Por nuestra parte estamos interesados en desarrollar una buena descripción de requisitos, completa y correcta.Queremos especificar un sistema técnicamente viable, que integre la funcionalidad necesaria de forma eficiente sobre

un diseño limpio y robusto.

8/18/2019 Clase 3_B




Usuarios contra desarrolladores

Por su parte los usuarios (cuando se implican) centran su interés endefinir el sistema con que esperan trabajar, sin querer saber nada deagendas, viabilidad, prioridades, etc.

Para abordar con las mayores garantías de éxito este problema, pornuestra parte:

Debemos sumergirnos en la organización del cliente; estudiar, analizar

y comprender los procesos y problemas a los que tiene que darcobertura el nuevo sistema.

En las comunicaciones de requisitos, así como en la descripción delsistema, tenemos que emplear un lenguaje natural, sin tecnicismos; yadoptar la terminología habitual del entorno del cliente.

Mantener un enfoque y unidad de criterio común por todas laspersonas de nuestra organización, de cara al cliente.

Por parte del cliente:

Debe facilitar interlocutores conocedores de los procesos y problemas que debemos conocer, con tiempo y motivaciónsuficiente para trabajar con nosotros.

Los interlocutores deben ser concretos y específicos en sus descripciones, revisar y validar los documentos de requisitosgenerados.

8/18/2019 Clase 3_B




Problemas frecuentes en la obtención de requisitos

Los problemas más frecuentes pertenecen a 3 categorías: Delimitación confusa del ámbito del sistema. Comprensión Inestabilidad

Problema: delimitación confusa del ámbito del sistemaAntes de entrar en la obtención de requisitos con detalle es necesario conocer cuáles son losobjetivos y los límites del sistema.

Si no controlamos los límites y objetivos esperados del sistema, el sistema noscontrolará a nosotros

Los contextos que es necesario conocer para centrar apropiadamente el sistema en su entornoson:

Organización Entorno Proyecto

8/18/2019 Clase 3_B




Para evitarlo deben analizarse y conocerse los tres ámbitos señalados

ORGANIZACIÓNPara llevar a cabo la obtención de requisitos es preciso conocer y comprender la organizaciónen la que trabajará el sistema, y los objetivos que se pretenden conseguir.

ENTORNOLos factores del entorno del sistema influyen de forma determinante en el proceso deobtención de requisitos. Los más importantes son:

Restricciones: de hardware, sobre el software o sobre los procesos de desarrollo. Madurez de los procesos del entorno de operación. Grado de certidumbre de los interfaces con otros sistemas.

PROYECTOEl contexto en el que se desarrolla el proyecto también afecta a los procesos de obtención de

requisitos, que deberá adecuar los métodos y técnicas de obtención a las características delproyecto:

Características específicas de cada grupo de agentes implicados en el proyecto(usuarios, cliente, desarrolladores, normativas, etc.)

Restricciones impuestas por las partes implicadas en la obtención de los requisitos(agenda, coste, parámetros de calidad deseados, etc.)

Problema: delimitación confusa del ámbito del sistema

8/18/2019 Clase 3_B




El 56% de los errores deslizados en los sistemas desarrollados se deben a deficiencias en lacomunicación “usuario – analista” durante la obtención de los requisitos, y este tipo de errores sonlos más caros de corregir porque llegan a consumir hasta el 82% del tiempo de desarrollo[1].

Los problemas de comprensión producen requisitos incompletos, con ambigüedades,inconsistentes; y en definitiva incorrectos, porque no definen las necesidades reales de losusuarios.

Estos problemas se pueden agrupar en tres categorías:

Dar por supuesto lo desconocido.

Lenguaje.

Información desestructurada.

[1] Goodrich, Victoria, and Olfman, Lorne. An experimental Evaluacion of Task annd Methodology Variables for RequirementsDefinition Phase Success. In Bruce D. Shriver (editor), Proceedings of the twenty-third Annnual Hawaii International Conference on

System Sciences, p. 201-209. IEEE Computer Society, January 1990

Los requisitos son inestables y cambian durante el desarrollo y tras la entrada en servicio delsistema.

La solución para evitar problemas radica en el proceso de gestión de requisitos.

Problema: comprensión

Problema: inestabilidad

8/18/2019 Clase 3_B


13



Técnicas de obtención de requisitos

TÉCNICAS

ENTREVISTAS

ESCENARIOS

PROTOTIPOS

OBSERVACIÓN

Reuniones JAD, cuestionariosreuniones de grupoentrevista, lluvia de ideas

Casos de uso, tarjetas CRCdiagramas de flujo, escenarios

Prototipos rápidosprototipos evolutivos

Introspecciónanálisis de protocolodocumentación, otros sistemas

E6

8/18/2019 Clase 3_B


14


Clasificación de los requisitos

TIPOS DE REQUISITOS

FUNCIONALES

REQUISITO

RESTRICCIÓN

NO FUNCIONALES

DE INTERFAZ

REQUISITO

RESTRICCIÓN

REQUISITO

RESTRICCIÓN

Requisitos funcionales

Definen el comportamiento del sistema.

Describen las tareas que el sistema debe realizar.

Al definir un requisito funcional es importante mantener el equilibrio entre la excesiva generalidad,insuficiencia de detalle o ambigüedad, y el exceso de detalle con precisiones o descripcionesinnecesarias o redundantes.

8/18/2019 Clase 3_B


15



Requisitos no funcionales

Definen aspectos, que sin ser funcionalidades, (tareas que el sistema debe realizar) resultandeseables desde el punto de vista del usuario. Generalmente comprenden atributos de calidad:

Tiempos de respuesta. Características de usabilidad. Facilidad de mantenimiento. etc.

Requisitos de interfaz

Definen las interacciones del sistema con su entorno:

Usuarios Otros sistemas

8/18/2019 Clase 3_B


16



Restricciones

Los requisitos, en su definición purista definen el QUÉ, y no el CÓMO; pero en el conjunto denecesidades que debe cubrir un sistema, no sólo hay que tener en cuenta QUÉ cosas hay quehacer, sino también en ocasiones CÓMO deben hacerse.

La clasificación entre requisitos puros (QUÉ) y restricciones (CÓMO) la debe considerar el analistapara que el equipo de trabajo sepa hasta qué punto determinados aspectos limitan sus opciones detrabajo, y poder mantener así la trazabilidad con su origen (necesidad apuntada por el usuario,normativa legal, limitación técnica, etc.)

Con carácter general las restricciones imponen limitaciones:

En la libertad de los analistas al realizar el diseño del sistema. En los procesos o formas de trabajar que se emplearán en el desarrollo del sistema.

El analista del sistema elige entre todas las opciones tecnológicamente posibles aquellas que segúnsu criterio profesional y las circunstancias del sistema, aportan mejor solución para laimplementación de los requisitos funcionales y no funcionales.

La indicación por parte del cliente de instrucciones como:

Debe emplearse base de datos Oracle.Los procesos de desarrollo deben ser conformes a Métrica 3.El sistema final debe ejecutarse sobre la plataforma libre Linux.Debe desarrollarse empleando Java.El interfaz de comunicación con un programa externo de contabilidad debe hacerse de la siguienteforma...

8/18/2019 Clase 3_B


17



Problemas de clasificación y nivel de rigor necesario

Para nosotros la base teórica de clasificación es un marco de referencia con la definición de loscriterios de clasificación.

En la relación de requisitos de un sistema, no resulta interesante entrar en análisis puristas paradeterminar si cada requisito lo es de interfaz, funcional, etc.

La diferencia entre:

“El sistema comprueba la autentificación y autorización del usuario y le da acceso a una pantalla con el menú general o en caso de error le redirige a la pantalla de usuario ycontraseña otra vez”

Y:

“RS. 3 El sistema sólo permite el acceso al menú principal a usuarios autorizados.

RT.3.1 El sistema identifica al usuario solicitando a través de la pantalla de operaciónsu nombre y contraseña de acceso.”

En el segundo caso, el equipo de trabajo sabe que debe descartar opciones de identificación através de tarjetas, o dispositivos biométricos, o cualquier otra opción posible.

Se trata por tanto de conocer y comprender el concepto de restricción, para aplicarlassólo cuando son necesarias, dejando así el mayor margen posible de libertad para eldiseño de la solución de software.

8/18/2019 Clase 3_B


18


Calidad de la documentación

Características de las buenas descripciones de requisitos

Posibles

Necesarios

Priorizados

Concretos

Verificables

Completa

Correcta

Consistente

Modificable

Trazable

Requisitos Especificación

8/18/2019 Clase 3_B


19


Propiedades de los buenos requisitos

Cada requisito debe poder implementarse dentro de las capacidades y limitaciones conocidasdel sistema y su entorno. El director técnico deberá comprobar la viabilidad de los requisitosantes de comprobar el documento.

Posibles

Un requisito es necesario si es algo:

que el cliente realmente necesita requerido para la conformidad con un requisito requerido para la conformidad con un interfaz,

externo o estándar.

Para evitar requisitos innecesarios,el cliente debe valorar cadafuncionalidad y como afectaráal sistema si esta o no.

Necesarios

Valor

Coste

Alto

Alto

8/18/2019 Clase 3_B


20



Los requisitos de una SRS deben incluir una indicación de la importancia del requisito en elconjunto del sistema.

Normalmente todos los requisitos de un producto de software no son igual de importantes.Algunos resultan esenciales, y otros son deseables.

Cada requisito debe identificar estas diferencias de forma clara, de esta forma ayuda a:

Los clientes tengan una consideración más adecuada de cada requisito, y a menudoclarifica asunciones que pudieran estar ocultas.

Que los desarrolladores tomen decisiones de diseño correctas y dediquen niveles deesfuerzo apropiado a las diferentes partes del producto.

Que el gestor del proyecto pueda establecer prioridades de ejecución, y disponga deinformación adicional en caso de problemas de agenda.

Requisitos priorizados

8/18/2019 Clase 3_B


21



Un requisito es concreto si tiene una única interpretación. Como mínimo esto requiere que cadacaracterística del producto final se describa empleando un término único. En los casos en losque el término puede tener diferentes significados según el contexto, éste debe incluirse en elglosario de la SRS con el significado con el que se emplea.

Concretos

Ambigüedad

Puntoóptimo

C o m p r e n s i ó n

Punto óptimo: Mayor grado de comprensión con lamenor ambigüedad

Modos eficaces de evitar la ambigüedad:

Inspecciones formales de los documentos de requisitos. Escritura de casos de prueba Elaboración de casos de uso. Elaboración de diagramas.

8/18/2019 Clase 3_B


22



Un requisito es verificable si, y sólo si a través de un proceso concreto y finito es posiblecomprobar si el software lo cumple. En general los requisitos ambiguos no son verificables.

Los requisitos no verificables incluyen sentencias como “que trabaje eficientemente”,”interfaz deusuario amigable”, “debe responder rápidamente”. Estos requisitos no son verificables porque noes posible definir los términos “eficiente”, “amigable”, “rápido”. La sentencia “el programa no

debe entrar nunca en un bucle infinito” tampoco es verificable porque un nivel de pruebasabsoluto es teóricamente imposible.

Un ejemplo de requisito verificable es:

“El tiempo de respuesta para la compra de un billete sencillo no debe superar los 2 segundos el90% de las veces, y una transacción de compra de un billete sencillo nunca debe tardar más de5 segundos.”

Esta sentencia es verificable porque emplea términos concretos y magnitudes medibles ycomprobables.

Si no es posible establecer un método para comprobar si el software cumple con undeterminado requisito, el requisito debe eliminarse o revisarse

Verificable

8/18/2019 Clase 3_B


23


Propiedades de la documentación

Una SRS es completa si, y sólo si incluye los elementos siguientes:

Todos los requisitos significativos, relativos a funcionalidad, rendimientos, restriccionesde diseño, atributos e interfaces externos.

Definición de las respuestas del software a todas las posibles entradas de datos en todaclase de situaciones. Es importante especificar las respuesta tanto para datos deentrada válidos, como inválidos.

Referencias a todas las imágenes, tablas y diagramas y definición de todos los términospropios y unidades de medida no normalizadas.

No puede considerarse completa una SRS si en la descripción de algunos requisitos se incluye lafrase “A determinar” o la expresión inglesa “TBD” (to be determined).

Si excepcionalmente se indica que un requisito se concretará más adelante es necesario indicartambién:

Descripción de las causas por las que no se ha concretado el requisito.Descripción de qué debe realizarse para poder eliminar el “TBD”, quién es la personaresponsable de llevarlo a cabo, y cuándo debe eliminarse

Completa

8/18/2019 Clase 3_B


24



Completos

A

Este bloque pertenece alos requisitos queconocemos y sabemosque son aplicables al

problema

B

Este bloque pertenece alos requisitos queconocemos pero no

conocemos, es decir quesabemos que existen pero

no hemos realizado suanálisis.

DEste bloque pertenece a

los requisitos que noconocemos y tampoco

sabemos que noconocemos

CEste bloque pertenece a

los requisitos quesabemos que son

aplicables al problemapero que no entendemos

No Entendemos

Entendemos

Conocemos No Conocemos

Prototipado y

casos de uso

Prototipado

Entrevistas y revisiones

8/18/2019 Clase 3_B


25



Una especificación de requisitos de software es correcta si, y solo si todos y cada uno de losrequisitos indicados son los que debe cubrir el software del sistema.

No hay ninguna herramienta que pueda garantizar la corrección. Una SRS debe compararse conlas especificaciones de rango superior del proyecto (Descripción del sistema, documentaciónreferenciada, etc.) para comprobar que cumple sus indicciones.

También es recomendable que la parte cliente determine si la especificación de requisitos de

software refleja sus necesidades actuales

Correcta

C

A

B

Necesidades

del Usuario

Requisitos

Especificados

BRequisitos

Correctos

Revisión y aprobaciónB

Requisitos

Correctos

8/18/2019 Clase 3_B


26



El atributo de consistencia se refiere a consistencia interna no a conformidad o congruencia condocumentos superiores (ej. descripción del sistema). La ausencia de esta congruencia supondríaun problema de corrección y no de consistencia.

Una documentación es internamente consistente si, y solo si, no se establecen conflictos entrerequisitos individuales o grupos de requisitos. Los tres tipos de conflictos posibles son:

Consistente

Conflictos

Objetos Lógicos Términos

C=A+B

C=A*B

RF 10 Informe A

“cierre de caja”

RF 50 Informe A

“cierre diario de operaciones”

8/18/2019 Clase 3_B


27



Un documento de requisitos es modificable si, y sólo si su estilo y estructura permiten quepuedan llevarse a cabo modificaciones en los requisitos manteniendo la estructura y el estilo, deforma fácil, completa y consistente. La modificabilidad generalmente requiere en ladocumentación:

Que tenga una organización coherente y fácil, con una tabla de contenidos y un índice..

Que no sea redundante. (p. ej. que el mismo requisito no aparezca en dos lugares deldocumento)

Exprese cada requisito por separado, mejor que mezclados con otros requisitos.

La redundancia, por sí misma no es un error, pero puede acarrearlos. En ocasiones laredundancia puede hacer un SRS más legible, pero puede generar errores al actualizar eldocumento, y generar inconsistencias si sólo se actualiza una de las apariciones, olvidando laotra.

Modificable

8/18/2019 Clase 3_B


28



Un SRS es trazable si establece de forma clara el origen de cada requisito, y facilita sureferencia en las futuras etapas del desarrollo, o en las actualizaciones de la documentación. Serecomiendan los dos tipos siguientes de trazabilidad:

Trazabilidad remota (hacia fases previas del desarrollo). Para ello se debe referenciar la fuentedel requisito.

Trazabilidad futura (hacia fases posteriores del desarrollo). Para ello cada requisito debe tenerun nombre o referencia única.

La trazabilidad remota es importante cuando el producto de software entra en la fase deoperación y mantenimiento. Al modificar el diseño y el código es esencial poder determinartodos los requisitos que quedan afectados por una modificación

Trazable

8/18/2019 Clase 3_B


29


Conclusiones

OBJETIVO

Desarrollar software Desarrollar unasolución

Tomar requisitosdel usuario

Comprender el entornoy necesidades del usuario

Realizar procesosnormalizados para el

desarrollo de requisitos

Descripción de requisitos

correcta

8/18/2019 Clase 3_B


30


Conclusiones

MEDIOS FIN

Aplicar técnicasy procesos

Conseguirel objetivo

8/18/2019 Clase 3_B


Clase 3_B

Documents

Transcript of Clase 3_B