sesion 02 los_requerimientos

Ingeniería de Software Ingeniería de Requerimientos

Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.

1

El Concepto de Requerimiento

Estandares de Programacion Unida I, Prof. Contreras, UTEC 2015


Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal

2



Una declaración abstracta de alto nivel de un servicio que debe proveer el sistema o una restricción de éste.

3



Una definición matemática detallada y formal de una función del sistema

4



Es un aspecto del contenido o comportamiento del producto, requerido o deseado por el cliente

5




Característica o restricción de un sistema

6


No son obvios.

1

Inconvenientes para definir Requerimientos


Provienen de diversas y variadas fuentes.

2



Existen muchos tipos de requerimientos y diferentes niveles de detalle

3



La cantidad de requerimientos puede hacer un proyecto inmanejable

4



Nunca son iguales. Algunos son más difíciles, más riesgosos o más importantes que otros

5



Los requerimientos están relacionados unos con otros, y a su vez están sujetos a un contexto

6



Un requerimiento puede cambiar a lo largo del ciclo de desarrollo (son inestables)

7




Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

8


Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

Características Deseables de un Requerimiento

1. Necesario


Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan aconsultarlo en un futuro.


2. Conciso


Un requerimiento es consistente si no es contradictorio con otro requerimiento.


3. Consistente


Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje, técnica o representación usado en su definición, no debe causar confusiones al lector.


4. No Ambiguo


Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de métodos de verificación como inspección, análisis, demostración o pruebas.


5. Verificable


Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.


6. Completo


Un requerimiento es trazable cuando el desarrollo para lograr su satisfacción admite etapas que puedan ser verificadas.


7. Trazable


Un requerimiento es representable si puede ser escrito en lenguaje natural o mediante algún otro medio que permita comunicar su sentido.


8. Representable


Un requerimiento es legible cuando es fácil de comprender.


9. Legible


Un requerimiento es realizable si con la tecnología disponible y en el marco de un proyecto se puede lograr su satisfacción.


10. Realizable


Ingeniería de Requerimientos

Disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema

1



Proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones

2



Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos

3



Ingeniería de Requerimientos es el proceso de descubrir, analizar, documentar y verificar los servicios y restricciones del sistema

4



Proceso para desarrollar una especificación del software. Implica desarrollar una especificación entendible por los usuarios del sistema y una más detallada para los desarrolladores del sistema

5



Enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto

6



Proceso sistemático utilizado para derivar una definición del sistema de software a ser desarrollado

7



Proceso de descubrimiento, refinamiento, modelado y especificación

8


Pasos :• Preparación• Realización• Documentación

Técnicas Clásicas para obtener requerimientos

1. Entrevista


¿Quién es el usuario?¿Quién es el cliente?¿Porqué se desea resolver el problema?¿Cuál es el valor de la solución exitosa?¿Cómo se resuelve hoy?


1. Entrevista


• Preguntas precisas• Requiere dominio del problema• Se recomienda organizar reuniones

donde se resuelvan en grupo


2. Cuestionarios o Cheklists


• Permite al equipo trabajar con un lenguaje común.

• Más crítico en equipos disciplinarios donde mismas palabras representan conceptos diferentes.


3. Glosarios


• Se escriben en lenguaje natural pero en un formato estricto y debidamente estructurado.


4. Plantillas y Patrones


• Recomendado cuando solo existe el problema pero no una solución.

• Reunión dondo todos opinan ideas sin restricciones en ambiente distendido. Luego se seleccionan y evaluan las factibles.

• Generación de efecto sinérgico.


5. Lluvia de Ideas


Un analista se sumerge por sí solo en el entorno laboral donde el sistema se utilizará. El trabajo diario se observa y se hacen notas de las tareas reales en las que los participantes están involucrados.


6. Etnografía


• Narración del problema y la solución requerida.

Representación de requerimientos

1. Lenguaje Natural


• Son grafos en los que los vértices representan conceptos y las aristas representan posibles relaciones entre dichos conceptos. Estos grafos de relaciones se desarrollan con el usuario y sirven para aclarar los conceptos relacionados con el sistema a desarrollar


2. Mapas Conceptuales



2. Mapas Conceptuales

Auto

PatenteTiene única

Municipalidad

Se obtiene en

Registro de PartesTiene

Infracción

Puede tener

Está registrada


• Consiste en representar sobre papel en forma muy esquemática las diferentes interfaces al usuario (sketches). Estos sketches pueden ser agrupados y unidos por enlaces dando idea de la estructura de navegación (storyboard)


3. Sketches y Storyboards


• La notación Z está basada en la teoría de conjuntos y la lógica matemática; incluye operadores estándar de conjuntos, comprensión de conjuntos, productos cartesianos y conjuntos potencia. La lógica matemática es el cálculo de predicados de primer orden


4. Lenguaje Z


• Guiones y Diálogos.• Tablas y Glosarios.• Modelo de Datos Entidad -

Relación.• Análisis de Puntos de Función.


5. Ancora

Ingeniería de Software Ingeniería de Requerimientos5. Ancora

Ingeniería de Software Ingeniería de Requerimientos5. Ancora

Guión: Plan de NegociosPista : Gestión de Preincubación.

Escena 1:P ingresa a través de FPN los datos correspondientes.Escena 2:AD y T controlan que los datos ingresados estén completos y sean los correctos.Escena 3:Si los datos ingresados son incorrectos, se ingresan observaciones al FPN, por el AD y el T.Escena 4:P actualiza los datos que AD y T estiman que son incorrectos.Escena 5:Si los datos son correctos AD o T aprueban el FPN.

Papeles:P = PreincubadoT = TutorAD = Administrador

Utensilios:FPN = Formulario Plan de Negocios

Condiciones de Entrada:Ingreso Datos al FPN.

Condiciones de Salida:P y AD controla ingreso de información del FPN.


• Software no funcional que muestra las interacciones del producto de software a construir.


6. Prototipos


• Lenguaje Unificado de Modelado


6. UML

sesion 02 los_requerimientos

Engineering