3.1Actividades de Reflexión inicial.

Tomando como punto de partida las actividades

realizadas en su proyecto formativo y la necesidad de poder conocer de una forma
precisa que se requiere a nivel de recursos físicos y lógicos para el éxito del desarrollo
del SI de su proyecto, lo invito a investigar y/o indagar lo siguiente:
• ¿Qué tipos de propuestas de trabajo conoce para presentar los requerimientos de una
empresa?
RTA/ existen informes o documentos con estructura técnica en los cuales se estipulan
previamente a través de una recolección de información los requerimientos necesarios
para la satisfacción o solución de la problemática de información que contiene el
desarrollo a implementar.

• ¿Describa las formas de representar soluciones a problemas planteados?

RTA/ Se pueden representar a través de:
un informe de requerimientos en los cuales se estipulan las soluciones
específicas a las problemáticas presentadas.
Un diagrama donde se especifique cada problema y la posible solución.
Un cuadro comparativo donde se especifique las ventajas y desventajas del
proceso actual con el nuevo cambio que se quiere implementar.

• ¿Describa metodologías, herramientas que permitan representar soluciones a

problemas planteados?
Las herramientas y técnicas cualitativas y no cuantitativas son las siguientes:
1. Recolección de datos.
Es una recolección de datos para reunir y clasificar las informaciones según
determinadas categorías de un evento o problema que se desee estudiar.
2. Lluvia/Tormenta de ideas (Brainstorming).
Técnica que consiste en dar oportunidad, a todos los miembros de un grupo
reunido, de opinar o sugerir sobre un determinado asunto que se estudiar.
3. Diagrama de Pareto.
Gráfico cuyas barras verticales están ordenadas de mayor a menor importancia,
estas barras representan datos específicos correspondientes a un problema
determinado, la barra más alta está del lado izquierdo y la más pequeña, según
va disminuyendo de tamaño, se encuentra hacia la derecha.
4. Diagrama de Ishikawa. (Causa Efecto)
 Técnica de análisis de causa y efectos para la solución de problemas, relaciona
un efecto con las posibles causas que lo provocan.
5. Diagrama de flujo.
Esquematiza todo el proceso de solución de un problema de manera secuencial.
6. Matriz de relación.
Consiste en un Gráfico de filas y columnas que permite priorizar alternativas de
solución, en función de la ponderación de criterios que afectan a dichas
alternativas.
7. Diagrama de comportamiento
Herramienta que permite graficar los puntos del comportamiento de una
variable, de acuerdo a como se van obteniendo.
8. Diagrama de Gantt.
Gráfico que establece el orden y el lapso en que deben ejecutarse las acciones
que constituyen un proyecto.
9. Entrevistas.
Técnica que permite reunir información directamente con el involucrado en el
proceso.
10. Listas chequeables.
Método, lista u hoja de información para lograr que nada se nos olvide ni se
omita, en la cual la información consignada es de fácil análisis y verificación.

• ¿Mencione al menos cuatro diferencias entre los requisitos funcionales, y los no

funcionales?

Funcionales No funcionales
Estos refieren directamente a las
funciones específicas que entrega el
son declaraciones de los servicios que sistema, sino a las propiedades
proveerá el sistema emergentes de éste como la fiabilidad, la
respuesta en el tiempo y la capacidad de
almacenamiento
surgen de la necesidad del usuario,
debido a las restricciones en el
presupuesto, a las políticas de la
declaran explícitamente lo que el sistema organización, a la necesidad de
no debe hacer. interoperabilidad con otros sistemas de
software o hardware o a factores externos
como los reglamentos de seguridad, las
políticas de privacidad, entre otros

Deber ser completa y ser consistente
expresa una capacidad de acción del
mismo
es una característica ya sea del sistema,
del proyecto o del servicio de soporte
Son las reglas del negocio.

• ¿Menciones cuáles son las características deseables de una buena especificación de

Requerimientos?
Rta/
El requerimiento debe cumplir con ciertos criterios y características
1. Correcta
2. No ambigua
3. Completa
4.Consistente
5. Calificada de acuerdo a la importancia y/o estabilidad
6.Verificable
7.Modificable
8.Rastreable

1. Correcta
Esta cumple este criterio si y solo sí, cada requisito especificado es un requisito que el
software debe cumplir.
2. No ambigua
No es ambigua sí y solo sí cada requisito especificado tiene sólo una interpretación.
3. Completa
Debe incluir los siguientes elementos:
a) Todos los requisitos significativos, ya sea que se relacionen a funcionalidad,
desempeño, restricciones de diseño, atributos o interfaces externas. En particular
cualquier requisito externo impuesto por una especificación del sistema debe ser
reconocido y tratado.
b) Definición de las respuestas del software a todos los tipos posibles de clases de
datos de entrada en todos los tipos posibles de clases de situaciones. Notar que
es importante especificar las respuestas tanto para valores de entrada
válidos como inválidos.
c) Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la
especificación de requerimientos, así como la definición de todos los términos y
unidades de medida.
 4. Consistente
Es consistente, sí y solo sí, no se contradice a sí misma, es decir, si ningunos
subconjuntos de requisitos ahí descritos se contradicen o entran en conflicto.
5. Jerarquizada de acuerdo a la importancia y/o estabilidad
Una SRS está calificada de acuerdo a la importancia y/o estabilidad si cada requisito
tiene un identificador que indique la importancia o estabilidad del requisito.
6. Verificable

es verificable, sí y solo sí, cada requisito especificado es verificable. Un requisito es

verificable sí y solo sí existe un proceso finito de costo-efectivo con el cual una
persona o una máquina puede verificar que el producto de software cumple el
requisito. En general cualquier requisito ambiguo no es verificable.
7. Modificable
es modificable, sí y solo sí, su estructura y estilo son tales que, cualquier cambio a
los requisitos pueden ser hechos fácil, completa y consistentemente sin perder la
estructura y el estilo. La modificabilidad generalmente requiere que una
especificación de requerimientos tenga:
 Tenga una organización coherente y fácil de usar con una tabla de
contenido, un índice y referencias cruzadas explícitas.
 No sea redundante (esto es, el mismo requisito no debe aparecer en más
de una parte en las especificaciones de requerimientos).
 Expresa cada requisito de manera separada, en vez de hacerlo mezclado
con otros requisitos.
8. Rastreable

Es rastreable si el origen de cada uno de sus requisitos es claro y si facilita la referencia

de cada requisito en el desarrollo futuro o mejora de la documentación.
Se recomiendan los siguientes dos tipos de rastreabilidad:
 Rastreabilidad hacia atrás (esto es, a estados previos del desarrollo). El requisito
tiene referencias explícitas a sus fuentes en documentos anteriores.
 Rastreabilidad hacia enfrente (esto es, a todos los documentos
derivados del SRS). Depende de que cada requisito tenga un nombre único o
número de referencia. Es particularmente importante cuando el software entra
en operación y mantenimiento. Cuando el código y los documentos de diseño
son modificados, es esencial contar con a capacidad para conocer el conjunto
completo de requisitos que pueden ser afectados por esas modificaciones.
3.2 Actividades de contextualización e identificación de conocimientos necesarios para el
aprendizaje.

Realice una investigación sobre los siguientes conceptos:

 Requerimientos, Informe de Requerimientos

Rta/
¿Qué es Requerimiento?

Puede definirse como un atributo necesario dentro de un sistema, que puede

representar una capacidad, una característica o un factor de calidad del sistema
de tal manera que le sea útil a los clientes o a los usuarios finales.

Es simplemente una declaración abstracta de alto de nivel de un servicio que

debe proporcionar el sistema o una restricción de este.

 Requerimientos del usuario

Son las declaraciones, en lenguaje natural y en diagramas de los
servicios que se esperan que el sistema proporcione y de las restricciones
bajo las cuales debe funcionar
 Requerimientos del sistema
Establece con detalle las funciones, servicios y restricciones operativas
del sistema, el documento de requerimientos del sistema debe ser preciso
y debe definir exactamente qué es lo que se va a implementar.

Para ser mejor comprendidos estos requerimientos se pueden clasificar en

 Requerimientos funcionales
Son declaración de los servicios que debe proporcionar el sistema, de la manera
en que este debe reaccionar a entradas particulares y de cómo se debe comportar
en situaciones particulares, también puede declarar lo que el sistema no debe
hacer.
 Requerimientos no funcionales

Son restricciones de los servicios o funciones ofrecidas por el sistema. Incluyen

restricciones de tiempo, sobre el proceso de desarrollo y estándares.
Se aplican a características o servicios individuales del tema.

 Requerimientos de dominio
Estos reflejan las características y restricciones del dominio de aplicación
del sistema.

Para la construcción y definición de los requerimientos se debe tener en

cuenta:
Verificación de Requisitos

Para la verificación de requisitos se deben añadir criterios de aceptación por cada

requisito, una tarea de la calidad es asegurarse de que cada requisito cumple con los
criterios asignados, este criterio es una medida del requisito que lo hace entendible y
con capacidad de ser probado.

Una vez ya identificado los requerimientos, documentados y verificados se procede a

realizar la revisión de los mismos con base a la información recolectada con los usuarios
del sistema, en esta revisión participa los analistas del equipo de trabajo y los usuarios
necesarios para esta revisión de debe chequear que:
 Los requisitos estén en su totalidad
 Están resultas las diferencias entre los requisitos solicitados y definitivos
 Los requisitos son claros y cumplibles por parte de la organización
 Se tiene documentado todo lo solicitado.
 Se tiene registro de los cambios.
 Se tienen los diferentes roles del sistema.

Preparar plan de revisión:

En la preparación del plan de reunión de debe planear quienes deben asistir que se va a
hablar y cuánto tiempo se va a gastar.

Documentos de requisitos a revisar:

Identificar cuáles son los documentos de especificación de requisitos que se va a revisar.

Preparar reunión:

Se debe confirmar el lugar en el cual realizará la reunión y se deben prepara los

materiales necesarios para la reunión (lápices, hojas, elementos visuales… etc).

Realizar reunión:
Se revisa el entendimiento de la especificación por parte de los interesados y se valida
que lo especificado si cumple con la necesidad del cliente y con lo solicitado.

Identificar de defectos de la especificación:

Si revisa si se encuentran defectos con respecto a lo solicitado o si hace falta alguna
especificación requerida.

Realización de correcciones a los documentos:

Si en la etapa anterior se encuentran defectos en la especificación el analista del sistema
debe realizan las debidas correcciones al documento.

Informar modificaciones a los interesados:

Una vez los defectos en la especificación han sido subsanados, se debe enviar un breve
resumen informando las tareas realizadas para la corrección de los documentos
especificados junto con los documentos corregidos a los participantes en la reunión para
dar su aprobación.
Cierre de los requerimientos:

Por último, se da por cerrado y entendido el requerimiento se firma la aprobación por

parte de los interesados y se procede a enviarse un correo con la aprobación del
requerimiento.

Informe de requerimientos
CONTENIDO DEL DOCUMENTO DE REQUERIMIENTOS

Introducción

Alcance
En esta sección se delimita el alcance del documento de requerimientos.

Propósito
Esta sección se refiere al compromiso propuesto, a las metas fijadas en el
contrato y no al documento de requerimientos.

Documentos aplicables
En esta sección se listan referencias, normas y demás documentos que sean
apropiados para la tarea propuesta.

Información técnica y requerimientos

 Cuáles son las características deseables de una buena especificación de

Requerimientos.

 Dominio del Sistema, Requisito Funcional, requisito No Funcional y Reglas del

negocio
 Procesos, identificando y aclarando los tipos de procesos, así como sus
características, metodologías.

Información fundamental
Esta sección es usada típicamente para describir alguna solución existente al
problema y proveer información adicional que sea relevante. En algunos casos esta
información puede ser muy extensa y podría estar contenida en volúmenes
separados o estar citada como referencia.

Definición del sistema

Es una descripción del sistema deseado desde el punto de vista de entradas,
funciones y salidas. El propósito de esta sección es informar sobre el ambiente en el
cual debe funcionar el sistema. Los siguientes ítems son típicos de la clase de
información que debe incluirse normalmente en esta sección.
  Diagrama jerárquico o de bloques que describa la estructura del sistema.
 Diagrama de flujo de datos para el sistema.
 Descripción de la base de datos, si existe, que el sistema debe mantener.
 Definición y descripción de todas las variables controladas
Requerimientos técnicos
Contiene la información técnica que será usada para determinar una solución aceptable,
de acuerdo con las necesidades que dieron origen al contrato. Define claramente las
tareas que se van a ejecutar.
Requerimientos de confiabilidad y mantenimiento
Detalla los requerimientos de confiabilidad y mantenimiento para el sistema propuesto.

Procedimientos para pruebas de aceptación

Se ocupa de los procedimientos usados para determinar si el sistema completo cumple
sus especificaciones

Estas especificaciones tienen el objetivo de que el usuario de este sistema continúe en el

futuro con el desarrollo de más aplicaciones que ayuden al mejor funcionamiento del
producto que tiene como función mantener al cliente actualizado sobre el estado del
equipo que llevo para su mantenimiento, así como el administrador apuntar sus
observaciones sobre el equipo recibido y sus especificaciones.

Estas especificaciones tienen el objetivo de detallar de forma concisa cada necesidad

planteada mediante la recoleccion de informacion, para así poder garantizar la
construccion de un sistema óptimo.A su vez garantizara formalmente que todas las
necesidades expuestas sean expresadas y solucionadas mediante la implementacion,
contruccion y ejecucion del aplicativo.
https://sites.google.com/site/metodologiareq/capitulo-iii
https://www.wikiteka.com/apuntes/que-es-un-requerimiento/
https://books.google.es/books?hl=es&lr=&id=gQWd49zSut4C&oi=fnd&pg=PR14&dq=
requerimientos+software&ots=s745pqtBqf&sig=Svvafq6p1rHuDbbo5MxAkwHbxis#v=
onepage&q=requerimientos%20software&f=false