El documento describe los siguientes puntos sobre requerimientos de software: establecer acuerdos con los clientes, definir el alcance del sistema, proporcionar una base para la planificación y estimación, y definir la interfaz de usuario centrándose en las necesidades de los usuarios. Además, explica conceptos como requerimientos funcionales y no funcionales, y el uso de casos de uso para modelar la funcionalidad del sistema desde la perspectiva del usuario.

1. ING.WILFREDO MONTERO MOGOLLÓN

3.  Establecer y mantener los acuerdos con los clientes y otros stakeholders
acerca de lo que el sistema debe hacer y porqué. Proporcionar a los
desarrolladores del sistema un mejor entendimiento de los requerimientos
del sistema
 Definir la delimitación del sistema
 Proporcionar una base para la planificación de los contenidos técnicos de la
iteraciones.
 Proporcionar una base para estimación de costo y tiempo para desarrollar
el sistema.
 Definir la interfaz de usuario (GUI), enfocándose sobre las necesidades y
objetivos de los usuarios

4.  “Una condición o capacidad la cual el sistema debe
satisfacer”
 Requerimientos Funcionales
 Pensar en lo que el sistema debe hacer a favor de los
usuarios.
 Son las acciones que el sistema debe ser capaz de
ejecutar.
 Expresar el comportamiento del sistema en función de
las entradas y salidas que deben tener los resultados
esperados.

5.  Son características que el sistema debe tener, principalmente
relacionado con la calidad.
 También son todas las características que debe tener el sistema
pero que no forman parte de los requerimientos funcionales.
 Podrían ser requisitos de:
 Utilización: estética, facilidad de uso, documento de Usuario, etc.
 Fiabilidad: tolerancia a fallas, recuperación, precisión, tiempo de
respuesta, tiempo de recuperación, cantidad de memoria.
 Soporte: pruebas, mantenimiento, actualización de versiones.

6.  Stakeholders: Requerimientos vs. Necesidades
 Características del sistema
 Requerimientos de software.

7.  Primero se recolecta los requerimientos de los stakeholders,
lo cual abarca todos los requerimientos y deseos conseguidos
de los usuarios finales, clientes, mercado y otros stakeholders.
 Se utiliza los requerimientos de los stakeholders para
desarrollar el documento de visión contenido el conjunto de
requerimientos clave de los stakeholders y usuarios y las
características de alto nivel del sistema.

8.  Las características del sistema expresan servicios que deben
ser ejecutados por el sistema para satisfacer las necesidades
stakeholders. Se debe traducir las características en
requerimientos detallados de software a un nivel al cual se
pueda diseñar y construir el sistema e identificar casos de
prueba para evaluar el comportamiento del sistema.
 Estos requerimientos se capturan en el Diagrama de Casos de
Uso de Requerimientos (DCUR) y en el documento de
especificaciones suplementarias, el que contiene todos los
requerimientos no modelados en los casos de uso.

9.  Describe cómo modelar la funcionalidad del sistema utilizando
casos de uso. En el UML, los casos de uso son los principales
medios para capturar la funcionalidad del sistema desde la
perspectiva del usuario y muchas veces puede remplazar al
documento "requisitos funcionales".
 La posición o contexto del caso de uso entre otros casos de uso.
Dado que es un mecanismo de organización, un conjunto de casos
de uso coherente, consistente promueve una imagen fácil del
comportamiento del sistema, un entendimiento común entre el
cliente/propietario/usuario y el equipo de desarrollo.

10.  Los Casos de Uso son una técnica para capturar información
de cómo un sistema o negocio trabaja actualmente, o de
cómo se desea que trabaje, estos diagramas no pertenecen
realmente al enfoque orientado a objetos, más bien es una
técnica para el modelado de escenarios en lo cual el sistema
debe operar.

11.  Cualquier sistema externo que interactúe con el
nuestro.
 Un actor es algo con comportamiento, como una
persona (identificada por un rol), un sistema
informatizado u organización, y que realiza algún
tipo de interacción con el sistema.
 Se representa mediante una figura humana
<Actor Name> dibujada con palotes. Esta
representación sirve tanto para actores que son
personas como para otro tipo de actores.
Actor

12.  Un caso de uso es una descripción de la secuencia de
interacciones que se producen entre un actor y el sistema,
 Caso de Uso cuando el actor usa el sistema para llevar a cabo
una tarea específica. El nombre del caso de uso debe reflejar la
tarea específica que el actor desea llevar a cabo usando el
sistema.
 Cada una de las transacciones de los Workers del Negocio
sobre las Entidades del Negocio se pueden transformar en un
caso de uso
Caso de uso

14.  Include: Cada vez que se
“ejecuta” el caso de uso A,
también se “ejecuta” el caso de
uso B.
 Extend: Cuando se “ejecuta” el
caso de uso A, algunas veces se
“ejecuta” el caso de uso B.

15.  No son válidas las asociaciones
entre actores
 No deben quedar Casos de uso
sin asociarse a algún actor u otro
caso de uso.
 No es necesario que todos los
casos de uso estén asociados
entre si.