Você está na página 1de 30

Arquitectura de

Sistemas

ACI 910 REQUERIMIENTOS

Requerimientos

Los

requerimientos

para

un

sistema

son

la

descripción de los servicios proporcionados por el

sistema y sus restricciones operativas.

Los requerimientos reflejan las necesidades de los clientes de un sistema que ayude a resolver algún problema

Tipos de requerimientos

  • Requerimientos del usuario

Declaraciones

en lenguaje

natural en

diagramas, de

los

servicios que se espera que el sistema proporcione y de las

restricciones bajo las cuales debe de funcionar

  • Requerimientos del sistema

Documento

estructurado

que

establece

una

descripción

detallada de los servicios y restricciones operativas del sistema

  • Especificación del Software

Una descripción detallada del software que es una base para el diseño e implementación. Esta orientada para ser leída por los desarrolladores

Lectores de requerimientos

Definición de

Requerimientos

Gerencia de Cliente Usuarios Finales del Sistema Ingenieros de Clientes Arquitectos del Sistema

Requerimientos de

especificación

Usuarios Finales del Sistema Ingenieros de Cliente Arquitectos del Sistema Desarrolladores de Software

Especificación de Software

(Quizá) Ingenieros de Clientes Arquitectos del Sistema Desarrolladores de Software

Requerimientos funcionales

  • Describen la funcionalidad o los servicios del sistema

  • Dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software

  • Los requerimientos funcionales para el usuario son declaraciones de alto nivel, los describen en forma general. Sin embargo, los requerimientos funcionales del sistema describen los servicios del sistema en detalle

Requerimientos NO funcionales

  • Definen propiedades y restricciones del sistema

  • Expresa una acción que debe ser capaz de realizar el sistema

  • También restricciones físicas sobre los funcionales

  • Ejemplo :

    • Usabilidad: factores humanos, ayuda, documentación

    • Confiabilidad: frecuencia de fallas, tiempo de recuperación

    • Performance: tiempo de respuesta, tasa de procesamiento, precisión, capacidad de carga

    • Soportabilidad: adaptabilidad, mantenibilidad, configurabilidad, internacionalización

Clasificación de requerimientos NO

funcionales

  • Requerimientos del producto

    • Éstos especifican el comportamiento del producto, por ejemplo, rapidez de ejecución, fiabilidad, etc.

  • Requerimientos organizacionales

    • Estos requerimientos son una consecuencia de las políticas y procedimientos de la organización, por ejemplo, estándares usados en los procesos, los requerimientos de implementación, etc.

  • Requerimientos externos

    • Son requerimientos que se originan por factores externos al sistema y de su proceso de desarrollo, por ejemplo, requerimientos legales, éticos, etc.

Métricas para los requerimientos no funcionales

Propiedad

Medida

 

Rapidez

Transacciones procesadas por segundo Tiempo de respuesta al usuario y a eventos Tiempo de actualización de la pantalla

Tamaño

KB

RAM

Facilidad de uso

Tiempo de capacitación Menú y manuales de ayuda

Fiabilidad

Tiempo promedio entre fallas Probabilidad de no disponibilidad Tasa de ocurrencias de las fallas Disponibilidad

Robustez

Tiempo de reinicio después de fallas Porcentaje de eventos que provocan fallas Probabilidad de corrupción de los datos después de las fallas

Portabilidad

Porcentajes de declaraciones dependientes del objetivo

Número de sistemas objetivo

8

Caso de Uso en requerimientos

  • Un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.

  • Los personajes o entidades que participarán en un caso de uso se denominan actores.

Caso de Uso en requerimientos  Un caso de uso es una secuencia de interacciones que

Documento de requerimientos

En la práctica es común describir los requerimientos en un documento llamado Especificación de Requerimientos del Software (SRS -Software Requirements Specification)

Documento de requerimientos En la práctica es común describir los requerimientos en un documento llamado Especificación

Documento de requerimientos

Documento de requerimientos

¿Para qué sirve un SRS?

  • Comunicar de manera precisa los requerimientos, objetivos y presunciones del dominio

  • Contrato

    • legal, documento interno o a modo de memorando

  • Base para estimación (tamaño, costo, tiempo) y planificación del proyecto

  • 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 evoluciona

  • Orientación Técnica de un SRS

    • Clientes y Usuarios

      • Interesados en validar objetivos del sistema y descripción de alto nivel de la funcionalidad

      • 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

    Orientación General un SRS

    • Gerentes

      • Medir y controlar el proceso desarrollo

    • Equipo de soporte de usuario

      • Desarrollo de plan de capacitación

      • Generación de manuales de usuario

      • Procedimientos de soporte online

    Contenido General de un SRS

    • Funcionalidad. ¿Que es lo que el software hace?

    • Interfaces externas. Como debe interactuar con gente, con el hardware del sistema, con demás hardware y con demás software?

    • Atributos de Calidad.

      • Disponibilidad, tiempo de respuesta, tiempo de recuperación despué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…

  • Cualidades de un SRS

    • Completitud

    • Pertinencia

    • Consistencia

    • Medibilidad

    • Precisión (No ambiguo)

    • Factibilidad

    • Entendibilidad

    • Trazabilidad

    • Buena Estructura

    • Modificabilidad

    Documento de requerimientos

    • 1. Introducción:

      • 1. Entorno, Estándares, Documentación.

    • 2. Definición de requerimientos del Usuario y Software

    • 3. Requerimientos de Calidad, Ambiente , Testing.

      • 1. Requerimientos Funcionales.

      • 2. Requerimientos de Testing

      • 3. Requerimientos de Calidad

      • 4. Requerimientos de Ambiente

    • 1. 2. Documento de requerimientos
      3.

    a

    2

    1

    • 4. Restricciones

      • 1. Restricciones Hardware

      • 2. Restricciones Software

      • 3. Restricciones de Interfaz

  • 5. Arquitectura del sistema

    • 1. Modelo Arquitectónico

  • 6. Especificación de los requerimientos del sistema

  • 7. Requerimientos de Desarrollo

    • 1. Requerimientos Participación Cliente

    • 2. Requerimientos de Comunicación

    • 3. Requerimientos de Infraestructura

  • 8. Requerimientos Post Desarrollo

    • 1. Requerimientos de Entrenamiento

  • Documento de requerimientos

    1.- Introducción

    • Entorno

    Debe contener cualquier información de entorno que el lector deba conocer. Esto incluye típicamente existencia de productos similares, datos históricos de otros proyectos similares, etc.

    • Estándares

    Se especifican los estándares que serán utilizados durante el desarrollo, por ejemplo estándares de codificación

    • Documentación

    Esta sección debe identificar los documentos relacionados con el proyecto que ya

    existen, y aquellos que serán generados o modificados como parte del desarrollo.

    Documento de requerimientos

    3.- Requerimientos Software

    • Requerimientos Funcionales

    Esta sección lista los requerimientos funcionales de alto nivel. Cada requerimiento debe tener un identificador único, el que será parte de la matriz de trasabilidad y el que será utilizado como referencia. Los siguientes puntos deben ser tomados en cuenta al definir los requerimientos.

    ¿Está claramente definido el requerimiento? (si hay más de una interpretación, el

    requerimiento es ambiguo). ¿Es testable el requerimiento? ¿Se puede demostrar con uno o varios casos de prueba que el requerimiento se cumple?

    SR1

    [Requerimiento funcional 1]

    SR2

    [Requerimiento funcional 2]

    SR3

    [Requerimiento funcional 3]

    SR4

    [Requerimiento funcional 4

    Documento de requerimientos

    3.- Requerimientos de Testing

    Se debe identificar los requerimientos de testing para cada uno de los requerimientos funcionales. Puede haber más de un test para validar un requerimiento funcional. Los requerimientos de testing deben ser definidos a alto nivel pero deben validar claramente los requerimientos del software. Al igual que los requerimientos funcionales, los requerimientos de testing deben tener un identificador único.]

    ST1

    [Requerimiento de testing 1]

    ST2

    [Requerimiento de testing 2]

    ST3

    [Requerimiento de testing 3]

    ST4

    [Requerimiento de testing 4]

    El acto de diseñar tests es uno de los mecanismos conocidos más efectivos para prevenir errores…

    El proceso mental que debe desarrollarse para crear tests útiles puede descubrir y

    eliminar problemas en todas las etapas del desarrollo”

    Documento de requerimientos

    • Matriz Requerimientos Funcionales vs. Requerimientos de Testing

    En esta sección se debe especificar la matriz que mapea los requerimientos funcionales con los requerimientos de testing.

       

    Requerimientos de test

     

    Requerimiento funcional

    ST1

    ST2

    ST3

    ST4

    ST5

    ST6

    FSR1

    X

    X

     

    X

       

    FSR2

     

    X

     

    X

       

    FSR3

    X

    X

     

    X

     

    X

    FSR4

    X

    X

     

    X

       

    FSR5

     

    X

    X

     

    X

     

    Documento de requerimientos

    3.- Requerimientos de Calidad

    Se identifica todos los requerimientos de calidad que han sido especificados por el cliente. Para cada requerimiento de calidad se debe especificar lo siguiente:

    Escala: dimensión de la medición Prueba: como se realizará la medición

    Peor Caso:

    El peor valor aceptable (bajo este valor se considera falla)

    Plan:

    valor planificado

    Autoridad:

    quien valida el requerimiento]

    Documento de requerimientos

    3.- Requerimientos de Ambiente

    • Requerimientos de Ambiente de Desarrollo

      • Hardware de Desarrollo

      • Desarrollo de Software

  • Requerimientos de Ambiente de Testing

    • Hardware de Testing

    • Software de Testing

  • Documento de requerimientos

    4.- Restricciones

    • Restricciones Hardware

    Esta sección debe identificar todas las restricciones hardware que puedan tener un impacto en la funcionalidad, tamaño o rendimiento del software.

    • Restricciones Software

    Se debe identificar todas las restricciones software que puedan tener un impacto en la funcionalidad, tamaño o rendimiento del software.

    • Restricciones de Interfaz

    Esta sección debe incluir todas las consideraciones de interfaz, tales como interfaz con otros productos, interfaz usuario, etc.

    Documento de requerimientos

    5.- Arquitectura del Software

    En esta sección se debe presentar la arquitectura del software en la forma de un diagrama de bloques. Se pueden hacer múltiples diagramas si es necesario. Si se considera que el producto será mejorado a futuro, las mejoras deben aparecer en la arquitectura desde el principio.

    1

    [Descripción del componente 1]

    2

    [Descripción del componente 2]

    3

    [Descripción del componente 3]

    Documento de requerimientos

    • Matriz Requerimientos Funcionales vs. Componentes de la Arquitectura

       

    Componente de la arquitectura

     

    Requerimiento

    C1

    C2

    C3

    C4

    C5

    C6

    funcional

    SFR1

    X

             

    SFR2

     

    X

           

    SFR3

       

    X

       

    X

    SFR4

         

    X

       

    SFR5

     

    X

       

    X

     

    Documento de requerimientos

    • Requerimientos de Desarrollo

      • Requerimientos Participación Cliente

      • Requerimientos de Comunicación

      • Requerimientos de Infraestructura

    Documento de requerimientos

    • Requerimientos Post Desarrollo

      • Requerimientos de Entrenamiento

    Se describen los requerimientos de entrenamiento del cliente incluyendo detalles como audiencia requerida, lugar del entrenamiento, material, etc.

    • Requerimientos de Mantención

    Esta sección describe los requerimientos de mantención del software tales como el modo de reportar los problemas, persona de contacto, etc.

    Actividad

    • Según el tema de la semana pasada o una nueva necesidad de software

    Desarrollar la primera parte de un documentos de requerimientos, este

    documento debe contener:

    • Introducción, Requerimientos funcional, Calidad, Ambiente , Testing .

    • Además debe desarrollar un caso de uso.