Actividad de aprendizaje 1

Unidad de formación: Análisis de requisitos

Docente: Manuel Alexander Valbuena Henao

Objetivo: Comprender las actividades que se llevan a cabo en la fase de análisis de un sistema de
información, a partir de los insumos obtenidos con la ingeniería de requisitos.

1. Visualiza el video que encuentras en el enlace que se comparte más adelante y elabora una
definición para la etapa del análisis de un sistema de información.

https://www.youtube.com/watch?v=Koz1H08-KtY

2. Consulta uno de los libros que se presentan en el Mufor de la unidad de formación y

complementa la definición elaborada anteriormente. Agrega las actividades y el perfil de un
analista de sistemas.

3. Elabora un mapa conceptual sobre las siguientes metodologías de análisis de sistemas de

información: modelos basados en el escenario, modelos de clase, modelos basados en el
comportamiento y modelos de flujo. Emplea los libros de la bibliografía de la unidad de
formación y/o libros adicionales que encuentres en la base de datos institucional

4. Recuerda las definiciones de requisito, requerimiento, requisito funcional y requisito no

funcional mediante la presentación que se adjunta y el video que puedes visualizar en la
siguiente dirección: https://www.youtube.com/watch?v=tF88eNhNSb4

5. Consulta sobre categorías que orienten la especificación de requisitos no funcionales y

elabora tres especificaciones para el Proyecto Pedagógico Integrador que estás realizando.

6. Revisa las especificaciones de los requisitos funcionales que elaboraste para la tercera ficha
del PPI en la unidad de formación definición de requisitos para determinar si cumplen con
las ocho características que sugiere la norma IEEE Std. 830.

7. Consulta sobre otras normas existentes para la especificación de requisitos y los aportes
que brinda en el proceso de la ingeniería de requisitos.
Solucion

1.La realización de un sistema sin la adecuada planeacion puede conducir a

grandes frustraciones y causar que el sistema sea subutilizado, o peor aún deje de
ser usado al no cumplir con las expectativas que le dieron origen. El análisis de un
sistemas es una guía que permite estructurar el proceso de desarrollo de sistemas
de información.
Tal proceso siempre representará un esfuerzo, inversión de tiempo y recursos por
parte de la organización. Acometer tal esfuerzo de manera casual, presenta un alto
grado de riesgo al no garantizar la culminación del proyecto con éxito. Este
procedimiento permite reducir al mínimo el riesgo de fracaso de nuevos proyectos,
pues es común que muchos errores surjan al utilizar nuevos sistemas de
información, bien por no adaptarse correctamente a las necesidades reales o por
desempeñarse de forma inadecuada.

2.El diseño y construcción de software de computadora es difícil, creativo y

sencillamente divertido. En realidad, elaborar software es tan atractivo que muchos
desarrolladores de software quieren ir directo a él antes de haber tenido el
entendimiento claro de lo que se necesita. Argumentan que las cosas se aclararán a
medida que lo elaboren, que los participantes en el proyecto podrán comprender
sus necesidades sólo después de estudiar las primeras iteraciones del software,
que las cosas cambian tan rápido que cualquier intento de entender los
requerimientos en detalle es una pérdida de tiempo, que las utilidades salen de la
producción de un programa que funcione y que todo lo demás es secundario. Lo
que hace que estos argumentos sean tan seductores es que tienen algunos
elementos de verdad.1 Pero todos son erróneos y pueden llevar un proyecto de
software al fracaso.La ingeniería de requerimientos proporciona el mecanismo
apropiado para entender lo que desea el cliente, analizar las necesidades, evaluar la
factibilidad, negociar una solución razonable, especificar la solución sin
ambigüedades, validar la especificación y administrar los requerimientos a medida
de que se transforman en un sistema funcional [Tha97]. Incluye siete tareas
diferentes: concepción, indagación, elaboración, negociación, especificación,
validación y administración. Es importante notar que algunas de estas tareas
ocurren en paralelo y que todas se adaptan a las necesidades del proyecto.

El perfil del analista en sistemas es el encargado de interactuar con los actores de

la organización en sus diferentes niveles,para obtener atraves de ellos la
información necesaria para el análisis ,diseño y desarrollo del sistema de
información con el fin de conocer quienes necesitan y en que grado la
información.hay que tener en claro que el analista de sistemas evalúa de manera
sistemática el ejercicio de un negocio mediante el examen de entrada y el
procesamiento de datos y su consiguiente producción de información (salida)con el
propósito de mejorar los procesos de una organización donde elabora.
 3- metodologías de análisis de sistemas de información

modelos basados modelos de clase

modelos basados en
en el escenario
el comportamiento

El modelado basado en clases

representa los objetos que
Los escenarios describen manipulará el sistema, las
situaciones teniendo en La notación de modelado que hemos
operaciones (también llamadas
cuenta aspectos de estudiado hasta el momento representa
métodos o servicios) que se
uso.permitiendo:conocer el elementos estáticos del modelo de
aplicarán a los objetos para
problema.unificar requerimientos. Es hora de hacer la
efectuar la manipulación, las
clientes/usuarios,organizar los transición al comportamiento dinámico
relaciones (algunas de ellas
detalles involucrados y del sistema o producto. Para hacerlo,
jerárquicas) entre los objetos y
entrenar a nuevos dicho comportamiento se representa
las colaboraciones que tienen
participantes. como función de eventos y tiempo
lugar entre las clases definidas.
específicos. El modelo de
Los elementos de un modelo
Este modelo en simples comportamiento indica la forma en la que
basado en clases incluyen las
palabras sirve para una responderá el software a eventos o
clases y los objetos, atributos,
interacción mas amena entre estímulos externos. Para generar el
operaciones, modelos clase-
el usuario y el sistema,por lo modelo deben seguirse los pasos
responsabilidad-colaborador
tanto el modelo de análisis siguientes: 1. Evaluar todos los casos de
(CRC), diagramas de
con uml comienza con la uso para entender por completo la
colaboración y paquetes. En las
creación de escenarios en la secuencia de interacción dentro del
secciones siguientes se presenta
forma de” los casos de sistema. 2. Identificar los eventos que
una serie de lineamientos
uso,diagrama de actividad y conducen la secuencia de interacción y
informales que ayudarán a su
diagrama de carril.” que entienden el modo en el que éstos
identificación y representación
se relacionan con objetos específicos. 3.
modelos de flujo Crear una secuencia para cada caso de
uso. 4. Construir un diagrama de estado
para el sistema. 5. Revisar el modelo de
comportamiento para verificar la
Aunque algunos ingenieros de software perciben el modelado orientado al flujo exactitud y consistencia.
como una técnica obsoleta, sigue siendo una de las notaciones más usadas
actualmente para hacer el análisis de los requerimientos.1 Si bien el diagrama de
flujo de datos (DFD) y la información relacionada no son una parte formal del UML,
se utilizan para complementar los diagramas de éste y amplían la perspectiva de
los requerimientos y del flujo del sistema. El DFD adopta un punto de vista del tipo
entrada-proceso-salida para el sistema. Es decir, los objetos de datos entran al
sistema, son transformados por elementos de procesamiento y los objetos de
datos que resultan de ello salen del software. Los objetos de datos se representan
con flechas con leyendas y las transformaciones, con círculos (también llamados
burbujas). El DFD se presenta en forma jerárquica. Es decir, el primer modelo de
flujo de datos (en ocasiones llamado DFD de nivel 0 o diagrama de contexto)
representa al sistema como un todo.
 5.profesor en este punto no lo puedo realizar ya que tengo un
inconveniente con el ppi.

6.revisando la ficha del ppi si están cumplen con las ocho

características que sugiere la norma IEEE Std. 830.

7.
Completa. Todos los requerimientos deben estar reflejados en ella y todas
las referencias deben estar definidas.

Consistente. Debe ser coherente con los propios requerimientos y también

con otros documentos de especificación.

Inequívoca. La redacción debe ser clara de modo que no se pueda mal

interpretar.

Correcta. El software debe cumplir con los requisitos de la especificación.

Trazable. Se refiere a la posibilidad de verificar la historia, ubicación o

aplicación de un ítem a través de su identificación almacenada y
documentada.

Priorizable. Los requisitos deben poder organizarse jerárquicamente según

su relevancia para el negocio y clasificándolos en esenciales, condicionales
y opcionales.

Modificable. Aunque todo requerimiento es modificable, se refiere a que

debe ser fácilmente modificable.

Verificable. Debe existir un método finito sin costo para poder probarlo.
Existen numerosas metodologías, estándares y normas en el ámbito de la gestión de
requisitos. Algunas de las normas más conocidas son: ISO 29148, ISO 15288, ISO
24766...

ISO 29148 – Systems and software engineering – Life cycle processes – Requirements
engineering: Contiene destrezas para los procesos y productos relacionados con la
ingeniería de requisitos para los sistemas y productos de software y servicios a lo largo
del ciclo de vida.

Define la construcción de un buen requisito, proporciona atributos y características de

los requisitos, y analiza la aplicación iterativa y recursiva de los procesos de requisitos
a lo largo del ciclo de vida.

ISO 29148 proporciona una orientación adicional en la aplicación de los procesos de

requisitos de ingeniería y gestión de las actividades de los requisitos relacionados en la
norma ISO 15288. Además, define los elementos de información aplicables a la
ingeniería de requisitos y su contenido.

ISO 15288 - Systems and software engineering – System life cycle processes: Establece
un marco común de procesos para describir el ciclo de vida de la Ingeniería de
Sistemas.

Define un conjunto de procesos y la terminología asociada desde un punto de vista de

la ingeniería. Estos procesos se pueden aplicar en cualquier nivel de la estructura
jerárquica de un sistema. Algunos conjuntos seleccionados de estos procesos se
pueden aplicar en todo el ciclo de vida de la gestión y la realización de las etapas del
ciclo de vida de un sistema. Esto se logra a través de la participación de todas las
partes interesadas, con el objetivo de lograr la satisfacción del cliente.

ISO 24766 – Information technology – Systems and software engineering – Guide for
requirements tool capabilities: La ingeniería de requisitos es un proceso esencial de los
sistemas y los ciclos de vida del software de ingeniería. La ingeniería de requisitos se
ha establecido como un proceso del ciclo de vida estándar ISO tanto en la norma ISO
15288, como en la norma ISO IEC 12207.

Esta norma proporciona una orientación sobre las capacidades deseables que debería
aportar una herramienta de Ingeniería de Requisitos. Normalmente la norma ISO 24766
es utilizada como complemento de la norma ISO 14102, “Information technology –
Guideline for the evaluation and selection of CASE tools”

Otras normas y estándares sobre la gestión de requisitos son:

IEEE Std 1233 – IEEE Guide for Developing System Requirements Specifications