TÉCNICAS PARA EL ANALISIS DE REQUERIMIENTO

1.  Instituto Vygotsky
 Licenciatura: Tecnologías y Sistemas de
Información
 Materia: Sistemas de Información
 Profe: Lucio Cesar Román Rafael
 Alumno: Guillermo Alexis Hernández
Miranda
 6° Cuatrimestre
Sistemas de Información

2. 3.1 TÉCNICAS ESTRUCTURADAS PARA EL
ANÁLISIS DE REQUERIMIENTOS
Las técnicas son un método que aplica herramientas y reglas específicas
para completar una o más fases del ciclo de vida del desarrollo de
Sistemas. Las técnicas estructuradas utilizadas en el desarrollo de los
Proyectos de Sistemas, buscaron superar el fracaso en muchos
desarrollos convencionales, como son las siguientes técnicas:
* Análisis estructurado
* Diseño estructurado
* Programación estructurada
* Desarrollo TOP-DOWN
* Equipos de programación
* Revisiones estructuradas

3. 3.1.1 CARACTERÍSTICAS DEL ANÁLISIS
ESTRUCTURADO
El desarrollo de un sistema de información, independientemente de su
tamaño y complejidad, requieren muchas actividades coordinadas y el
empleo de una diversidad de herramientas y de modelos. La metodología
de desarrollo de sistemas es una forma estándar de organizar y coordinar
estas actividades.
El análisis de sistemas llega a la raíz del problema o a la necesidad y define
los requerimientos de los usuarios de las siguientes características:
1 clarificación de requerimientos
2 estudio de factibilidad
3 aprobaciones de requerimiento

4. 3.1.2 ESPECIFICACIÓN FORMAL DE DATOS
Los métodos formales para el desarrollo de software, se utilizan para todas las
etapas del ciclo de desarrollo de software y que tienen la característica que
usan formalismos matemáticos para la representación o derivación de los
elementos involucrados en cada etapa.
Algunas de las ventajas que podemos nombrar sobre una especificación formal
son las siguientes:
Prototipito: las especificaciones formales pueden llegar a ser ejecutables.
Corrección del programa: verificación automática y formal de que el programa
funciona correctamente.
Reusabilidad: posibilidad de usar la especificación formal en distintos ámbitos.
En cuanto a la notación, una descripción formal constara de cuatro partes
+NOMBRE. Nombre genérico
+CONJUNTOS. Conjuntos de datos que intervienen en la definición.
+SINTAXIS. Signatura de las operaciones definidas nombre operación
+SEMANTICA. Indica el significado de las operaciones.

5. 3.1.2.1 DIAGRAMA DE FLUJO Y CONTROL DE
DATOS
Para comprender el mejor movimiento lógico de los datos en un negocio, el
analista de sistemas traza diagramas de flujo de datos. El diagrama de flujo
de datos son análisis estructurados y herramientas de diseño que permiten
que el analista comprenda visualmente el sistema y subsistemas como un
juego de flujos de datos interrelacionados. La representación gráfica de
movimientos, almacenamiento y transformación de datos es trazada con el
uso de cuatro símbolos: un rectángulo redondeado para indicar
procesamientos o transformaciones de datos, cuadrado doble para indicar
una entidad de datos externa (origen o receptor de datos), una flecha para
mostrar el flujo de datos un rectángulo de extremo abierto para mostrar un
almacén de datos.

6. 3.1.2.2 DICCIONARIO DE DATOS
Un diccionario de datos es un conjunto de metadatos que contiene las
características lógicas de los datos que se van a utilizar en el sistema que se
programa, incluyendo nombre, descripción, alias, contenido y organización.
Identifica los procesos donde se emplean los datos y los sitios donde se
necesita el acceso inmediato a la información, se desarrolla durante el análisis
de flujo de datos y auxilia a los análisis que participan en la determinación de
los requerimientos del sistema, su contenido también se emplea durante el
diseño.
En un diccionario de datos se encuentra la lista de todos los elementos que
forman parte del flujo de datos de todo el sistema. Los elementos más
importantes son flujos de datos, almacenes de datos y procesos.
El diccionario de datos guarda los detalles y descripción de todos estos
elementos.

7. 3.1.3 ESPECIFICACIÓN DE PROCESOS
Es una herramienta modelado de sistemas, que permite definir que sucede en
los procesos o funciones de un sistema. El objetivo es definir qué debe hacerse
para transformar ciertas entradas en ciertas salidas. No hay una única forma de
realizar la especificación de procesos; existen múltiples herramientas que
facilitan esta tarea, a un que debería emplearse a aquella que permite fácil
comprensión.
Algunas herramientas utilizadas para generar especificaciones de procesos son:
Lenguaje estructurado: se emplea un lenguaje natural limitado en palabras y
construcciones, dándole más precisión y claridad, evitando ambigüedades (el
lenguaje natural humano carece de precisión y es muy ambiguo). Definen un
algoritmo.
Uso de pre- condiciones: describe la función del proceso, sin detallar un
algoritmo específico.
Otras: tablas de decisiones, lenguaje narrativo, diagrama de flujo, diagrama
NassiShneiderman gráficas, etc.

8. 3.1.3.1 LENGUAJE NATURAL
El lenguaje natural se refiere a la utilización del lenguaje ordinario usado en
la vida diaria como técnica para que el desarrollador del sistema extraiga los
requisitos que desea el cliente, es la técnica más comúnmente usada para la
extracción de requisitos. Su objetivo principal es lograr el entendimiento y
especificación correcta por parte del desarrollar sobre las necesidades que
posee el cliente para el comportamiento del sistema. Esta técnica es usada
durante la etapa de análisis del proceso de desarrollo de un sistema. Más
específicamente, dentro del proceso de Ingeniería de requisitos, se utiliza el
lenguaje natural puro durante la etapa de especificación.
El proceso de esta técnica en si no está definido, por el contrario, se trata de
una comunicación sin reglas ni acuerdos previos, que puede llevar acabo de
forma oral o escrita.

9. 3.1.3.2 LENGUAJE ESTRUCTURADO
El lenguaje estructurado es un lenguaje natural limitado en palabras y
construcciones, lo que le da más precisión y claridad, evitando ambigüedades
(el lenguaje natural humano carece de precisión y es muy ambiguo).
El lenguaje estructurado puede utilizarse para especificar un algoritmo. Luego,
para que la computadora pueda procesarlo, deberá transformarse o
“traducirse” a un lenguaje de programa específico.
El lenguaje estructurado es una herramienta que puede utilizarse en la
especificación de procesos, en el desarrollo de sistemas.

10. 3.1.3.3 TABLAS DE DECISIÓN
La tabla de decisión es una matriz de renglones y columnas que indican
condiciones y acciones.
Las reglas de decisiones establecen el procedimiento a seguir cuando
existen ciertas condiciones. Este método se emplea desde mediados de la
década de los 50, cuando fue desarrollado por General Electric para el
análisis de funciones de la empresa como control de inventarios, análisis de
ventas, análisis de créditos y control de transporte y rutas. Se utiliza la tabla
de decisión cuando existen muchas combinaciones.
La tabla de decisión está integrada por cuatro secciones:
+ Identificación de Condiciones
+ Entradas de condiciones
+ Identificación de acciones
+ Entradas de acciones

11. 3.1.3.4 ARBOLES DE DECISIÓN
El árbol de decisión es un diagrama que representan en forma secuencial
condiciones y acciones; muestra qué condiciones se consideran en primer
lugar, en segundo lugar y así sucesivamente. Este método permite mostrar
la relación que existe entre cada condición y el grupo de acciones
permisibles asociado con ella.
Un árbol de decisión sirve para modelar funciones discretas, en la que el
objetivo es determinar el valor combinado de un conjunto de variables, y
basándose en el valor de cada una de ellas, determinar lección de ser
tomada.
Los arboles de decisión son normalmente construidos a partir de la
descripción de la narrativa de un problema. Ellos prevén una visión grafica
de la toma de decisiones necesaria, especifican las variables que son
evaluadas, que acciones deben ser tomadas y el orden en la cual la toma de
decisiones será efectuada.

12. 3.2 TÉCNICAS ORIENTADAS A OBJETOS PARA
ANÁLISIS DE REQUERIMIENTOS
El análisis y diseño orientados a objetos empieza (DOO) a destacar en los
80’s. La programación orientada a objetos (POO) es la implementación del
DOO, y a su vez, el DOO es la abstracción del AOO. La programación
estructurada parte del diseño Top-Down. En esta se presta atención al
conjunto de acciones que manipulan el flujo de datos. El enfoque principal de
la POO se centra en las estructuras de datos y las acciones a realizar sobre
ellos.

13. 3.2.1 CARACTERÍSTICAS ANÁLISIS ORIENTADO
A OBJETOS
El objetivo del análisis orientado a objetos es desarrollar una serie de modelos
que describan el software de computadora al trabajar para satisfacer un
conjunto de requisitos definidos por el cliente. El AOO como los métodos de
análisis convencionales descritos, forma un modelo de análisis mutilarte para
satisfacer este objetivo. El modelo de análisis ilustra información,
funcionamiento y comportamiento dentro del contexto de los elementos del
modelo de objetos.

14. 3.2.2 ESPECIFICACIÓN FORMAL DE OBJETOS
No hay duda de que el modo de especificación tiene mucho que ver en la
calidad de la solución. Los ingenieros del software se han visto forzados a
trabajar con especificaciones incompletas, inconsistentes o engañosas han
experimentado la frustración y condición que variablemente provocan. La
calidad la fecha de entrega y el alcance del software son las que sufren las
consecuencias.
Principios de las especificaciones
La especificación independiente del modo como la relacionemos, puede verse
como un proceso de representación. Los requisitos se presentan de manera
que como fin último lleven el éxito de la implementación del software.

15. 3.2.2.1 CASOS DE USO
Un caso de uso es una técnica para la captura de requisitos potenciales de un
nuevo sistema o una actualización de software. Cada caso de uso
proporciona uno o varios escenarios que indican cómo debería interactuar el
sistema con el usuario o con otro sistema para conseguir un objetivo
específico.
En ocasiones se utiliza un usuario sin experiencia junto a los analistas para el
desarrollo de casos de usos. En otras palabas un caso de uso es una
secuencia de transacciones que son desarrolladas por un sistema en
respuesta a un evento que inicia un acto sobre el propio sistema. Los
diagramas de caso de uso sirven para especificar la funcionalidad y el
comportamiento de un sistema mediante su interacción con los usuarios y/o
otros sistemas.

16. 3.2.2.2 MODELADO DE CLASES
RESPONSABILIDADES Y COLABORACIONES
Una vez que se han desarrollado los escenarios de uso básicos para el
sistema, es el momento de identificar las clases candidatas e indicar sus
responsabilidades y colaboraciones. El modelado de clases-
responsabilidades colaboraciones (CRC) aporta un medio sencillo de
identificar y organizar las clases que resulten relevantes al sistema de
requisitos del producto.
Un modelo CRC es realmente una colección de tarjetas índice estándar que
representan clases. Las tarjetas están divididas en tres secciones. A lo largo
de la cabecera de la tarjeta usted escribe el nombre de la clase. En el cuerpo
se listan las responsabilidades de la clase izquierda y a la derecha los
colaboradores.

17. 3.2.2.3 DEFINICIÓN DE ATRIBUTOS
Atributo es un carácter de un archivo o carpeta que lo hace oculto, de sistema,
de solo lectura, etc.
Por ejemplo se podría tener una entidad llamada alumno. Esta entidad puede
ser constituida por uno o más atributos, que son propiedades de la entidad
alumno, que interesan para almacenarse en la base de datos.
Por ejemplo la entidad alumno podría tener los atributos: nombre, apellido, año
de nacimiento, etc.
La elección de los atributos de una entidad depende del uso que se le dará a la
base de datos. El alumno puede tener una religión, pero sino interesa al final de
la base no es necesario almacenar en un atributo

18. 3.2.2.4 DEFINICIÓN DE SERVICIOS
El servicio es llevado acabo por una organización o personal encargado
de atender una necesidad pública o privada. La definición de servicio es el
primer paso del análisis del sistema, en este proceso en analista se reúne
con el cliente y /o usuario (un representante institucional departamental o
cliente particular), e identificar las metas globales, se analizan las
respectivas del cliente, sus necesidades y requerimientos , sobre la
planificación temporal y presupuestal, líneas de mercado y otros puntos
que pueden ayudar a la identificación y desarrollo del proyecto; así como
la identificación de los servicios que va a presentar el sistema a cada
usuario participante.

19. 3.2.3 PROTOTIPOS RÁPIDOS EN
DETERMINACIÓN DE REQUERIMIENTOS
Los prototipos son una visión preliminar del sistema futuro que se implantara.
La elaboración de prototipos de un sistema de información es una técnica
valiosa para la recopilación rápida de información específica a cerca de los
requerimientos de información de los usuarios.
Los prototipos efectivos deben hacerse tempranamente en el ciclo de vida
del desarrollo de sistemas, durante la fase de determinación de
requerimientos.
En esta forma el analista está buscando las reacciones iniciales de los
usuarios y de la administración hacia el prototipo, sugerencias de los
usuarios sobre cambios o limpieza del sistema para el que construye un
prototipo, posibles innovaciones y planes de revisión que detallan que parte
del sistema necesita realizarse primero.
Tipos de información que busca el analista durante la Elaboración de
Prototipos.
+ Reacciones del usuario.
+ Innovaciones.
+ Sugerencias del usuario.
+ Plan de revisión.

20. 3.3 TÉCNICAS BASADAS EN COMPONENTES
Un componente es un grupo de objetos o componentes más pequeños que
interaccionan entre ellos y se combinan para dar un servicio. Un
componente es similar a una caja negra, en la cual los servicios del
componente se especifican por su interface o interfaces, sin ofrecer
conocimiento del diseño e implementación internas del componente. El
desarrollo basado en componentes es el proceso de ensamblar la
combinación correcta de componentes en la configuración correcta para
llevar acabo la funcionalidad deseada para un sistema. Los componentes se
representan en el diagrama de clases de UML especificando la interfaz de
una clase o paquete. Hay dos notaciones para mostrar una interfaz - una es
mostrar la interfaz como una 'regular class symbol' con el estereotipo
"interfaz", con una lista de operaciones soportadas por esta interfaz,
detalladas en el “operation department” (departamento de operación). “ The
alternate, shortcut notation” es mostrar la interfaz como un circulo pequeño
junto con la clase con una línea sólida, con el nombre de la interfaz en el
círculo

21. 3.3.1 INGENIERÍA DEL DOMINIO
La ingeniería de dominio se puede definir como el proceso clave que se
necesita para el diseño sistemático de una arquitectura y de un conjunto de
elementos software reutilizable que pueden ser usados en la construcción de
una familia de aplicaciones relacionadas o subsistemas. La ingeniera se
carga de la definición y búsqueda de nuevos componentes, y de la
realización de ensayos de investigación y validación.
El objetivo fundamental de la ingeniería de dominio es la optimización del
proceso de desarrollo del software en un aspecto de multiplanes aplicaciones
que representan un negocio común o problema de dominio.
Una ingeniería de dominio deficiente puede resultar en malas absorciones de
los procesos de soporte problemas inesperados y procesos erróneos
pérdida de oportunidades y mala utilización de recursos reducción de los
niveles de calidad.

22. 3.3.2 IDENTIFICACIÓN CLASIFICACIÓN
COMPONENTES REUTILIZABLES
Clasificación De Componentes:
El tamaño de los componentes puede ser medido por medio de las métricas
utilizadas en diseño orientado a objetos. Esto significa que la medición del
tamaño de un componente puede ser medido a través de:
 Líneas de Código (LCD)
 Orientado a Función
 Complejidad: En algunas ocasiones, son utilizadas matrices de tamaño para
evaluar la complejidad, pero es recomendable hacer uso de otro tipo de
métricas.
 Métricas de Complejidad: “Complejidad Ciclo matica”, este método mide el
número de decisiones lógicas en un segmento de código:
 CPC: mide la complejidad del componente por medio de la suma de clases,
clases abstractas e interfaces, la complejidad de clases y métodos.
 Reusabilidad: La reusabilidad de un componente se puede medir a partir de
dos diferentes perspectivas, estas son: reutilizado y re – usado.

23. 3.3.3 CARACTERIZACIÓN DE COMPONENTES
 Identificable: Debe tener una identificación que permite acceder fácilmente
sus servicios y que permita su clasificación
 Auto contenido: Un componente no debe requerir de la utilización de otros
para finiquitar la función para la cual fue diseñado.
 Puede ser remplazado por otro componente: Se puede remplazar por
nuevas versiones u otros componentes que lo remplace y mejore.
 Con acceso solamente a través de su interfaz: debe asegurar que estas no
cambiaran a lo largo su implementación.
 Sus servicios no varían pero su implementación sí.
 Bien documentado: Un componente debe estar correctamente
documentado para facilitar su búsqueda si se quiere actualizar, integrar con
otros, adoptarlo, etc.
 Es genérico: Sus servicios debe servir para varias aplicaciones.
 Reutilizados dinámicamente: puede ser cargado en tiempo de ejecución en
una aplicación
 Independiente de la plataforma: Hardware, Software, SO

24. 3.4 OTRAS TÉCNICAS
La ingeniería de requisitos puede ser un proceso largo y arduo para él
requiere de habilidades psicológicas. Los nuevos sistemas cambian el
entorno y las relaciones entre la gente, así que es importante identificar a
todas las personas implicadas, considerar sus necesidades y asegurar que
entienden las implicaciones de los nuevos sistemas. Los analistas pueden
emplear varias técnicas para obtener los requisitos del cliente.
Históricamente, esto ha incluido técnicas tales como las entrevistas, o
talleres con grupos para crear listas de requisitos. Técnicas más modernas
incluyen prototipos, y utilizan casos de uso. Cuando sea necesario, el
analista empleara una combinación de estos métodos para establecer los
requisitos exactos de las personas implicadas, para producir un sistema que
resuelva las necesidades del negocio de esta es una prueba.

25. 3.4 OTRAS TÉCNICAS
Análisis estructurado:
El desarrollo de un sistema de información, independientemente de su
tamaño y complejidad, requiere muchas actividades coordinadas y el
empleo de una diversidad de herramientas y modelos. La metodología de
desarrollo de una forma estándar de organizar y coordinar estas
actividades.
El análisis de sistemas llega a la raíz del problema o a la necesidad y define
los requerimientos de los usuarios.