El análisis de requerimientos es de vital importancia en el desarrollo de los sistemas debido a que permite identificar y entrevistar al usuario, con la información obtenida se podrá definir, refinar, modelar, verificar y especificar las solicitudes que el mismo realizo. Con el pasar de los años el análisis de requerimientos se volvió muy utilizado a nivel mundial lo que motivo a que se establecieron varios estándares de los cuales el mas conocido es ANSI, IEEE 830-1993.

1. Análisis de Requisitos para un
sistema
JOSE ENRIQUE FERNANDEZ M
ESCUELA 47
INSTITUTO UNIVERSITARIO POLITÉCNICO SANTIAGO
MARIÑO

2. Introducción
El análisis de requerimientos es de vital importancia en el desarrollo de los
sistemas debido a que permite identificar y entrevistar al usuario, con la
información obtenida se podrá definir, refinar, modelar, verificar y
especificar las solicitudes que el mismo realizo.
Con el pasar de los años el análisis de requerimientos se volvió muy
utilizado a nivel mundial lo que motivo a que se establecieron varios
estándares de los cuales el mas conocido es ANSI, IEEE 830-1993.

3. Objetivos de la Ingeniería de Requisitos
• Definir, con la mejor calidad posible, las características de un sistema
software que satisfaga las necesidades de negocio de clientes y usuarios
y que se integre con éxito en el entorno en el que se explote. La
definición de dicho sistema se realiza mediante lo que se conoce como
una especificación de requisitos.
• Gestionar las líneas base y las peticiones de cambios que se vayan
produciendo en la especificación de requisitos, manteniendo la
trazabilidad entre los requisitos y otros productos del desarrollo.

4. Realizar
plan de
Fase
Repartir
requerimientos de
usuario en el
equipo de trabajo
Extraer los
requerimientos
Funcionales y No
Funcionales
Realizar
Particionamiento de
los requerimientos
Verificar anchura y
profundidad de los
requerimientos
¿Requerimie
nto ok?
NORealizar
Diagrama de
estados
Realizar
Diagrama de
Actividades
SI
Realizar
diagrama de
casos de uso
Especificar casos
de uso en fase
fachada
Verificar casos
de uso en fase
fachada
¿CU OK?
NO
Conciliar casos
de uso
Realizar diagrama
de casos de uso del
proyecto
(completo)
Repartir casos
de uso en el
equipo de
trabajo
Especificar casos
de Uso dase
Terminados
Validar casos de
uso terminados
¿CU OK? NO
Almacenar CU
Terminados
SI
Almacenar REQ Fun y
NF
Definir base de
Requerimientos
Caso de uso:
fase terminado
Especificciones
requerimientos
funcionales y
no funcionales
Especificciones
requerimientos
funcionales y
no funcionales
Listado de
requerimientos
funcionales y
NO funcionalesPlan de Fase
Diagrama de Actividades y de
estados
Análisis de
Requerimientos

5. Requerimientos
El resultado de esta tarea o actividad no es estático, ya que a lo largo
del proyecto pueden aparecer nuevos requerimientos, ampliaciones,
incluso eliminaciones o modificaciones de los existentes. Cuanto más
tarde descubramos requisitos nuevos o haya desviaciones entre los
requisitos y el producto, mucho mayor impacto tendrá en tiempo y
coste.

6. Requerimientos
Se tiene que considerar la trazabilidad de los requerimientos como
aspecto fundamental en la gestión de un proyecto. Es decir, actualizar
los requerimientos del proyecto conforme se vayan produciendo tales
cambios, pero sin olvidar la actualización , el impacto y la coherencia
de la documentación asociada al mismo: análisis del sistema, diseño,
pruebas de validación, etc.

7. • Este gráfico refleja las
dependencias que se
establecen entre la
definición de requisitos y
su gestión de proyectos,
el desarrollo del mismo y
la documentación de
soporte que se genera.

8. Tipos de Requerimientos
Normalmente el conjunto de requisitos software se clasifican en
requisitos funcionales, requisitos no funcionales y requisitos del
dominio. Todos ellos son requisitos del sistema, pero ¿Cuáles la
diferencia entre ellos?

9. Tipos de Requerimientos
• Requerimientos funcionales: contienen información relativa a los servicios
que el sistema debe prestar. Además en muchas ocasiones también
engloban aspectos relativos a lo que el sistema no debe hacer.
• Requerimientos no funcionales: Se aplican al sistema en su totalidad, y
estos reflejan las limitaciones de las tareas ofrecidas por el sistema.
• Requerimientos del dominio: pueden ser funcionales o no funcionales y
manifiestan propiedades y limitaciones del dominio del sistema.

10. Debido a la gran cantidad de tipos de requisitos no
funcionales existentes, seguidamente se muestra una
clasificación de ellos:

11. Requerimientos del usuario
La definición de los requisitos de usuario consiste en explicar
requisitos funcionales y no funcionales para que sean comprendidos
por los usuarios del sistema sin poseer estos un conocimiento técnico.
Es por esto, que a la hora de redactar dichos requisitos, han de
utilizarse tablas y diagramas sencillos así como también un lenguaje
sencillo.

12. Clasificación de los Requerimientos de Usuario
• Equivocación de requisitos: debido a que no se diferencian claramente la
información existente para el diseño, los requisitos funcionales y no
funcionales y los objetivos del sistema.
• Falta de claridad: en ocasiones es difícil usar el lenguaje de forma rigurosa y no
ambigua sin realizar el documento poco breve y complicado de leer.
• Unión de requisitos: varios requisitos distintos pueden ser declarados como un
solo requisito.

13. Requerimientos de Sistema
Existe una versión ampliada y detallada de los requerimientos de
usuario, que se corresponden con los llamados requerimientos del
sistema y son usados por los ingenieros de software como inicio para el
diseño del sistema. En estos básicamente se especifica la manera en que el
sistema debe proveer los requerimientos del usuario. En ningún momento
los requisitos del sistema detallan como debe ser el diseño ni la
implementación del sistema, sino que informan acerca del
comportamiento y restricciones operativas de este.

14. Diseño
El proceso de diseño permite la definición de los componentes de software que
deben ser implementados para satisfacer las necesidades de los usuarios. Tiene
en cuenta los requerimientos funcionales y no funcionales definidos y acordados
con el cliente.
La base para la definición del proceso de diseño es el área de procesos Technical
Solution (TS) del modelo CMMI Development versión 1.3 (Capability Maturity
Model Integration), que define un conjunto de prácticas que permiten diseñar el
producto y los componentes de producto adecuadamente.

15. Desarrollo
El proceso de desarrollo proporciona los lineamientos para la adecuada
generación del código y las verificaciones necesarias para minimizar los
errores técnicos inherentes a los procesos de desarrollo de software.
La base para la definición del proceso de desarrollo es el área de procesos
Technical Solution (TS) del modelo CMMI Development versión 1.3
(Capability Maturity Model Integration), que define un conjunto de
prácticas que permiten realizar la construcción del software, partiendo del
diseño realizado.

16. Pruebas
El proceso de Pruebas garantiza que el producto final cumpla con los requerimientos
establecidos por el cliente.
La base para la definición del proceso de Pruebas es el área de procesos Verification
(VER) del modelo CMMI Development versión 1.3 (Capability Maturity Model
Integration), que reúne un conjunto de prácticas que orientan y garantizan la correcta
ejecución de las pruebas durante la ejecución de un proyecto de desarrollo de software.
El resultado final del proceso de Pruebas es un producto que cumple con los parámetros
de calidad definidos en el proyecto.

17. Bibliografía
• https://www.icesi.edu.co/i2t/driso/process/proceso_desarrollo_sw
/
• http://www.juntadeandalucia.es/servicios/madeja/contenido/subsi
stemas/ingenieria/ingenieria-requisitos
• https://www.slideshare.net/SergioRios/unidad-13-analisis-de-
requerimiento

18. Agregar un título de
diapositiva (1)