2. Que es Un requerimiento?
• De acuerdo al glosario IEEE: Un requerimiento es una condición o necesidad
para resolver un problema o alcanzar un objetivo, un capacidad que debe
estar presente en un sistemas o componentes de sistema para satisfacer un
contrato estándar, especificación u otro documento formal.
• De acuerdo a Ian Summerville es la siguiente: “Un requerimiento es
simplemente una declaración abstracta de alto nivel de un servicio que debe
proporcionar el sistema o una restricción de éste”.
• Entonces un requerimiento es una descripción de una condición o capacidad
que debe cumplir un sistema, ya sea derivada de una necesidad de usuario
identificada, o bien, estipulada en un contrato, estándar, especificación u
otro documento formalmente impuesto al inicio del proceso.

3. Características generales de un
Requerimiento
• Especificado por escrito.
• Posible de probar o verificar.
• Que sea fácil de leer y entender.
• Completo, que no necesite ampliar detalles en su redacción.
• Consistente, que no contradiga otro requerimiento.

4. Dificultades para definir los Requerimientos.
• No son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras.
• La cantidad de requerimientos en un proyecto puede ser difícil de
manejar.
• Un requerimiento puede cambiar en el proceso de desarrollo.
• El usuario no puede explicar lo que hace, tiende a recordar lo
excepcional y olvidar lo especifico y tiene un lenguaje diferente al de
los desarrolladores.

5. Los requerimientos se enfocan en, qué es lo que el
sistema debería
hacer, son el comportamiento interno del software:
Cálculos, detalles técnicos, manipulación de datos
entre otros.
Estos muestran como los casos de uso serán llevados
a la practica
y a su vez son complementados por los
requerimientos no funcionales.
REQUERIMIENTOS FUNCIONALES

6. Según Gonzales F. Carmen
“Los requerimientos especifican que es lo que el
sistema debe hacer,
sus funciones y propiedades esenciales y deseables.
Expresan el propósito del sistema sin tomar en
cuenta
como se va a implantar.”
REQUERIMIENTOS FUNCIONALES

7. Un requerimiento es una característica que el sistema debe
tener o es una restricción que el sistema debe satisfacer para
ser aceptada por el cliente.
REQUERIMIENTOS FUNCIONALES
Describen la interacción entre el sistema y su
ambiente, el ambiente incluye al usuario y cualquier
otro sistema externo que interactúa con el sistema
independientemente de su implementación.

8. Pueden clasificarse en tres categorías:
•Evidentes: Debe realizarse y el usuario debe estar
consiente de que se realiza.
•Ocultos: Se realiza pero no es visible para el usuario.
•Opcionales: Añadirlos no implica que va añadir costos.
Para realizar la recopilación de requerimientos
se realiza el levantamiento de requerimientos
que hace uso de:
•Escenarios.
•Casos de uso: Describen a los escenarios.

9. Un caso de uso especifica el funcionamiento del sistema,
es la secuencia de interacciones que se desarrollan entre
el sistema y los usuarios en respuesta a un evento
que inicia el usuario principal sobre el sistema.
El termino levantamiento de requerimientos quiere decir
especificar términos del sistema, en un idioma
que el cliente pueda entender para poderlos redactar
el contrato entre el cliente y los desarrolladores.

10. CARACTERÍSTICAS DE LOS
REQUERIMIENTOS.
• Deben ser consistentes.
• Deben estar completos.
• Deben ser realistas.
• Cada requerimiento debe describir algo que es
necesario para el cliente.
• Deben ser verificables.
• Deben ser rastreables.

11. REQUERIMIENTOS FUNCIONALES
Los requerimientos funcionales deben estar redactados
de tal forma que sean comprensibles para usuarios sin
conocimientos técnicos avanzados de Informática.
Deben especificar el comportamiento externo del sistema y
evitar, en la medida de lo posible, establecer características
de su diseño, deben priorizarse (al menos, se ha de distinguir
entre requisitos obligatorios y requisitos deseables).

12. Algunos ejemplos de requerimientos funcionales
son los siguientes:
1.Visualizar información
2.Insertar
3.Modificar
4.Eliminar
5.Descargar
6.Buscar información
7.Escribir
8.Consultar
9.Actualizar
10.Permitir autenticación

13. Típicamente, un analista de requisitos genera requisitos
funcionales luego de diagramar los casos de uso.
Sin embargo, esto puede tener excepciones, ya que el
desarrollo de software es un proceso iterativo
y algunos requisitos son previos al diseño de los casos de uso.
Ambos elementos (casos de uso y requisitos)
se complementan en un proceso bidireccional.
REQUERIMIENTOS FUNCIONALES

14. Un requisito funcional típico contiene un nombre y un número
de serie único y un resumen.
Esta información se utiliza para ayudar al lector a entender
por qué el requisito es necesario, y para seguir al mismo
durante el desarrollo del producto.
REQUERIMIENTOS FUNCIONALES

15. Requerimientos No
Funcionales

16. Requerimientos No Funcionales
• Como su nombre lo especifica son requerimientos que no se
relacionan directamente con los servicios específicos que el sistema
entrega a sus usuarios, pueden relacionarse con propiedades
emergentes del sistema tales como: fiabilidad, tiempo de
respuesta, uso de
almacenamiento, rendimiento, seguridad, accesibilidad, portabilidad
operatividad entre otros, y también pueden definir restricciones
sobre la implementación del sistema, como capacidades de los
dispositivos de entrada y salida o las representaciones de datos
usados en las interfaces de otros programas.
• Por lo tanto se refieren a todos los requisitos que ni definen
información a guardar ni tareas a realizar dentro del sistema.

17. Requerimientos No Funcionales
• Aunque los requerimientos no funcionales no son servicios que ofrece
directamente el sistema al usuario, el fracaso para cubrir estos
requerimientos haría que todo el sistema fuera inútil. Por ejemplo, si
un sistema de control de transacciones de un banco no cubre sus
requerimientos de seguridad no será certificado para su operación, o
si un sistema de control de aeronave no cubre sus requerimientos de
fiabilidad no cera aceptado como un dispositivo seguro y su un
sistema de control embebido fracasa para cubrir sus requerimientos
de rendimiento, no operarían correctamente las funciones de control.

18. Requerimientos No Funcionales
• Existen dos razones de por que la implementación de los
requerimientos no funcionales se propagan a lo largo del sistema:
1. Los requerimientos no funcionales afectan mas la arquitectura
global de un sistema que los componentes Individuales. Por
ejemplo para garantizar que se cumplan los requerimientos de
rendimientos es posible que se deba de organizar el sistema de
manera que se minimice la comunicación entre los componentes.
2. Un requerimiento no funcional individual, como la
seguridad, podría generar algunos requerimientos funcionales
relacionados que definan nuevos servicios del sistema que se
requiera. Además también podrían generar restricciones a los
requerimientos existentes.

19. Tres Tipos de Requerimientos No
Funcionales.
1. Requerimientos del Producto: especifican o restringen
comportamientos del software por ejemplo el rendimiento sobre
que tan rápido se debe ejecutar una tarea y cuanta memoria
requiere.
2. Requerimientos de la organización: requerimientos de sistemas
amplios derivados de políticas y procedimientos en la organización
cliente y el desarrollador, por ejemplo requerimientos de proceso
de desarrollo que define el lenguaje de programación con el que se
va a crear el sistema.
3. Requerimientos externos: incluyen todos los factores externos del
sistema y su proceso de desarrollo, por ejemplo requerimientos
regulatorios que establecen lo que debe hacer el sistema para ser
aprobado por un regulador, o requerimientos legislativos que deben
de seguirse para que opere conforme a la ley.

20. Algunas Medidas Métricas para especificar
Requerimientos No Funcionales
• Rapidez: transacciones por segundo procesadas, tiempo de respuesta
usuario / evento, tiempo de regeneración de pantalla.
• Tamaño: Mega Bytes, Numero de chips ROM.
• Facilidad de Uso: tiempo requerido de capacitación, numero de cuadros de
ayuda.
• Fiabilidad: tiempo medio para falla, probabilidad de indisponibilidad, tasa
de ocurrencia de falla.
• Robustez: tiempo de reinicio después de falla, porcentaje de eventos que
causan falla, probabilidad de corrupción de datos en falla.
• Portabilidad: numero de sistemas objetivo, porcentaje de enunciados
dependientes de objetivo.

21. Importancia del UML

22. ¿Qué es UML?
• El Lenguaje Unificado de Modelado (UML) es un
lenguaje que provee un conjunto estandarizado de
herramientas para documentar el análisis y diseño
de un sistema. Un lenguaje de modelado de
propósito general.

23. ¿Qué es UML?
• Nos permite especificar y detallar la arquitectura y
los elementos de un sistema de información ya sea
sencillo o de gran nivel de complejidad, para poder
abstraer cualquier detalle de este.

24. Beneficios del UML
• Manejo de la complejidad:
• Al trabajar con UML podemos modular un
sistema complejo y así trabajar con sectores de
este y modelarlos para comprender mas
fácilmente el sistema.

25. Beneficios del UML
• Reutilización:
• Cuando se utiliza el Lenguaje Unificado de
Modelado se pueden generalizar los
componentes de un sistema y así poder utilizarlos
en muchas partes del mismo.

26. Herramientas UML
• Ahora existen diferentes herramientas que
toman el estándar definido de UML y nos
permiten generar código a partir de este
como lo esVisual Studio 2013.

27. Entonces ¿Porqué es importante el uso de
UML?
• Estandariza el diseño gráfico de sistemas
• Al usar UML en forma iterativa en el análisis
y diseño se logra una mejor comprensión
entre equipos de trabajo y equipos deTI en
relación con los requerimientos del sistema.

28. Entonces ¿Porqué es importante el uso de
UML?
• Beneficia la reutilización de componentes
del sistema.
• Facilita el manejo de sistemas de gran
complejidad.

29. Bibliografia
• Gonzales F. Carmen. (2011) Notas del curso análisis de requerimientos. [Pagina
web] recuperado el 06 de marzo 2014 de
<Http://web.cua.uam.mx/publicaciones/Notas_Analisis_Requerimiento.pdf>
• Kendall, K., & Kendall, J. (2011). Análisis y diseño de sistemas. México:
Pearson Educación.
• Osorio, L. (Productor). (2013). Importancia delUML [Video].
Disponible en:
http://audiovisuales.uned.ac.cr/mediateca/videos/1007/importancia-
del-uml
• Arias Chavez. M (2005). La ingeniería de requerimientos y su importancia en el
desarrollo de proyectos de software. UCR 5(11). 2 – 4. recuperado de:
http://www.redalyc.org/articulo.oa?id=66661111
• Sommerville, Ian. (2011). Ingenieria de Software. Mexico. Pearson Education.