Este documento presenta una introducción a la ingeniería de requerimientos para el desarrollo de software. Define requerimientos, explica el proceso de ingeniería de requerimientos y clasifica los requerimientos en funcionales y no funcionales. Además, describe la especificación y documentación formal de requerimientos funcionales y no funcionales para guiar el desarrollo de software.

1. INGENIERIA DE REQUERIMIENTOS
INTEGRANTES:
Jose Ahías Vargas Pacheco
Henry Vargas Ortiz
Gabriel Nuñez Juarez
Randall Madrigal Leiva
GRUPO 3

2. Definiciones de Requerimientos
Son descripciones de lo que el sistema debe hacer:
• el servicio que ofrece
• las restricciones en su operación
Requerimientos
Ingeniería de
Requerimientos
Proceso de descubrir, analizar, documentar y verificar los servicios
ofrecidos y las restricciones de operación.
Requerimientos
del usuario
Requerimientos
del sistema
Enunciados en lenguaje natural junto con diagramas, acerca de qué
servicios esperan los usuarios del sistema y de las restricciones con las
cuales éste debe operar.
Descripciones más detalladas de las funciones, servicios y las
restricciones operacionales del sistema de software.

3. Clasificación de los Requerimientos
Requerimientos
funcionales
Requerimientos
no funcionales
Enunciados acerca de servicios que el sistema debe proveer y de cómo
debería reaccionar a entradas particulares y situaciones específicas.
Según Campderrich (2003), los requisites funcionales describen qué
debe realizar el software para sus usuarios: aceptar, verificar y registrar
datos, transformarlos, presentarlos, etc.
Limitaciones sobre servicios o funciones que ofrece el sistema.
Consisten en restricciones impuestas por el entorno y la tecnología,
especificaciones sobre tiempo de respuesta o volume de información
tratado por unidad de tiempom requisitos en cuanto a interfaces,
extensibilidad, facilidad de mantenimiento, etc. (Campderrich, 2003)

4. Requerimientos Funcionales
Nivel de detalle
Ejemplos
Los requerimientos funcionales varían desde requerimientos generals
que cubren lo que tiene que hacer el sistema, hasta requerimientos
muy específicos que reflejan maneras locales de trabajar o los sistemas
existentes de una organización.
Requerimiento 1: Un usuario podrá buscar listas de citas en todas las
clínicas de la Caja Costarricense del Seguro Social.
Requerimiento 2: El sistema elaborará a diario para cada clínica, listas
de pacientes que se esperan asistan a cita ese día.
Requerimiento 3: Cada miembro del personal que usa el sistema debe
identificarse de manera individual con su número de 8 dígitos.

5. Requerimientos Funcionales
Especificación de
requerimientos
funcionales
Inexactitud en la
especificación
Causa muchos problemas en la ingeniería de software que pueden provocar
aplazamiento de la entrega del sistema y aumento de costos.
Debe ser:
• completa: deben definirse todos los servicios requeridos por el usuario.
• consistente: los requerimientos tienen que evitar definiciones
contradictorias.
En sistemas complejos grandes es casi imposible lograr la consistencia y
totalidad:
• por la facilidad con que se cometen errors y omisiones al escribir
especificaciones.
• por la existencia de muchos participantes con diferentes necesidades

6. Requerimientos No Funcionales
Requerimientos de sistemas amplios, derivados de políticas y
procedimientos en la organización del cliente y del desarrollador.
Ejemplos: requerimientos ambientales, operacionales y de desarrollo.
Requerimientos
del producto
Requerimientos
de la empresa
Requerimientos
externos
Especifican o restringen el comportamiento del software. Ejemplos:
requerimientos de eficiencia, confiabilidad, seguridad y usabilidad.
Se clasifican en:
Aquellos derivados de factores externos al sistema y su proceso de
desarrollo. Ejemplos: requerimientos regulatorios, éticos y legales.

7. Requerimientos No Funcionales
Facilidad de uso
Transacciones/Segundo procesadas, tiempo de respuesta usuario/evento, tiempo de
regeneración de pantalla.
Métricas para especificar requerimientos no funcionales:
Portabilidad
Fiabilidad
Robustez
Tamaño
Rapidez
Mbytes, número de chips ROM.
Tiempo de capacitación, número de cuadros de ayuda.
Tiempo medio para falla, probabilidad de indisponibilidad, tasa de ocurrencia de
falla, disponibilidad.
Tiempo de reinicio después de falla, porcentaje de eventos que causan falla,
probabilidad de corrupción de datos en falla.
Porcentaje de enunciados dependientes de objetivo, número de sistemas objetivo.

8. Especificación de Requerimientos
Proceso de escribir, en un documento de requerimientos los:
• requerimientos del usuario: en lenguaje natural, complementando con
diagramas y tablas.
• requerimientos del sistema: también en lenguaje natural, pero se utilizan otras
notaciones como las siguientes:
Definición
Enunciados en
lenguaje natural
Lenguaje natural
estructurado
Lenguaje de
descripción de diseño
Anotaciones gráficas
Especificaciones
matemáticas
Cada enunciado debe expresar un requerimiento.
Usa lenguajes como los de programación, pero con características más abstractas para especificar los
requerimientos al definer un modelo operacional del sistema.
Se escriben en lenguaje natural en una forma o plantilla estándar. Cada campo ofrece información de un
aspecto del requerimiento.
Los modelos gráficos, complementados con anotaciones de texto sirven para definer los requerimientos
funcionales del sistema; se emplean los casos de uso del UML y los diagramas de secuencia.
La anotaciones se basan en conceptos matemáticos como máquinas o conjuntos de estado finito.

9. Documento de Requerimientos de Software
Según el sitio bicubic.cl, el documento de requerimientos es la declaración
oficial de qué es lo que deben implementar los desarrolladores:
• requerimientos del usuario para el sistema
• especificación detallada de los requerimientos del sistema
Definición
Es la documentación que implementa en los software sobre sus
requerimientos, pero con más detalle y el cual puede ir orientado a varios
usuarios , si la documentación llega a ser muy extensa, se separa en
secciones. El document es tan necesario para el cliente como para los
desarolladores para poder orientarse a las necesidades del cliente y viceversa
donde el cliente entederá sobre el nuevo sistema (la documentación siempre
debe ser desarrollada en lenghuaje ordinario sin tecnicismo para su completo
entendimiento para el cliente).

10. Clientes del
sistema
Este documento se orienta al cliente, donde este podrá verificar si el
software cumple con lo deseado, y así podría hacer modificaciones si
hubiera la necesidad
Administra-
dores
Este documento contiene información del sistema a nivel de costos y
su proceso de desarrollo
Ingenieros
de prueba
del sistema
Usan el documento para verificar los requerimiento que se desean y
validarlos
Ingenieros
de sistema
El documento los guía a desarrollar el sistema en base a los
requerimientos deseados por el cliente y que los desarrolladores de
software crean
Ingenieros de
mantenimiento
del sistema
Se encargar de revisar el documento, e identifican como se relacionan
los componentes con el sistema

11. Estructura del Documento de Requerimiento del Sistema
Prefacio Es un resumen de las versiones, del porque la nueva versión del sistema
Introducción Muestra todas las funciones del sistema y sus requerimiento de forma resumida, también
información empresarial y estadísticas del sistema
Glosario Acá se agregan las definiciones de las palabras técnicas del documento
Definición de
requerimientos del
usuario
Se explica en lenguaje natural de los servicios que se le dan al cliente, también pueden usar
diagramas y observaciones.También se incluyen los requerimientos no funcionales
Arquitectura del
sistema
Esta sección muestra como esta formado el sistema, por medio de módulos de sistema, donde
también se ven las partes que se reutilizaron del sistema
Especificación de
requerimientos de
sistema
Se detallan con mucho mas detalle los requerimientos funcionales y no funcionales
Modelos de sistema En este se muestra como funciona los componentes y su relación con los sistemas con gráficos.
Evolución de sistema Este es donde se registra la bases del sistema también cualquier cambio que se esperaba ya sea
por alguna modificación que quisiera el cliente o por las mejoras a nivel de hardware

12. Apéndice En el apéndice va a ir la información detalla de la aplicación,
como la información del hardware (como los requisitos mínimos o
los necesarios para obtener un rendimiento optimo)y la base
datos, muestra la relación del sistema y sus componentes
Índice Acá muestra un índice(lista de las secciones del documento de
requerimientos) el cual puede ser alfabético, diagrama….

13. Especificación de Requerimientos
Es donde se explica los requerimientos de usuario y sistema, pero se deben seguir siempre
ciertas reglas para desarrollar este documento.
El documento se debe de desarrollar con lenguaje natural y no técnico, ya que su lectura será
totalmente para el cliente, este puede que no manejo lenguaje técnico, causado que el no
pueda entender lo cual hace este documento no sirva para su propósito.
• Los requerimientos de usuario es un documento el cual explica los componentes
funcionales y no funcionales del sistema, normalmente se usan tablas o alguna otra forma
que sea muy sencilla de explicación.
• Y los requerimientos de sistema son versiones extendidas del de usuarios, este si incluye
estructura del sistema, es mas que todo el que se agrega para aceptar el contrato donde
viene explicado con detalle lo que el sistema hace y necesita, que si esta de acuerdo con lo
establecido.

14. Tipos de Lenguajes
1. Especificación en lenguaje natural: es el utilizado para detallar los requerimientos de
software por su sencillez aunque ambiguo y se usan muchas palabras de entendimiento
universal, resaltar con negrita o cursiva información importante, también pueden dar una
razón para el requerimiento para sacar de cualquier duda al lector, evitar palabras
inmisarias como (debe) y si es muy necesario usar un (debería).
2. Especificaciones estructuradas: los requerimientos de sistemas acá usan lenguaje natural
pero tal vez si especifique mas con detalle y tecnicismo por esa motivo se usa una
estructura la cual pueda ayudar al lector, como material de apoyo. Se a estandarizado que
se uso en modo de tarjeta para los requerimientos de sistema para poder dar un toque
sencillo a este y así facilitar su compresión al lector. El uso de tablas, graficos es muy
importante ya que son de a gran ayuda para las explicaciones; si se llegara detallar
funciones de sistemas deben incluir (descripción de funciones, entrada de sistema, salida
y donde llegara, acciones que se tomaran, efecto colaterales).

15. Procesos de Ingeniería de Software
El procesos se basan en las decisiones que tomaron sobre los requerimientos de
software, cuales se validaron y modificaron. Con esto se emplea un método por etapas
el cual se ejecutara paso a paso , este método representado en forma grafica es una
espiral .

16. En una organización, la adquisición y el análisis de requerimientos pueden involucrar a
diversas clases de personas. Un participante en el sistema es quien debe tener alguna
influencia directa o indirecta sobre los requerimientos del mismo. Los participantes incluyen
a usuarios finales que interactuarán con el sistema, y a cualquiera en una organización que
resultará afectada por él. Otros participantes del sistema pueden ser los Ingenieros que
desarrollan o mantienen otros sistemas relacionados, administradores de negocios,
expertos de dominio y representantes de asociaciones sindicales.
Adquisición y Análisis de Requerimientos

17. Actividades del Proceso
La comprensión de los requerimientos por parte del analista mejora con cada ronda del
ciclo. El ciclo concluye cuando está completo el documento de requerimientos.

18. Descubrimiento de Requerimientos
Es el proceso de recopilar información sobre el sistema requerido y los sistemas
existentes, así como de separar, a partir de esta información, los requerimientos del
usuario y del sistema.
Las fuentes de información durante la fase de descubrimiento de requerimientos incluyen
documentación, participantes del sistema y especificaciones de sistemas similares. La
interacción con los participantes es a través de entrevistas y observaciones, y pueden
usarse escenarios y prototipos para ayudar a los participantes a entender cómo será el
sistema.

19. El equipo de ingeniería de requerimientos formula preguntas a los participantes sobre el
sistema que actualmente usan y el sistema que se va a desarrollar. Los requerimientos se
derivan de las respuestas a dichas preguntas.
La información de las entrevistas se complementa con otra información del sistema de
documentación que describe los procesos empresariales o los sistemas existentes, las
observaciones del usuario, etcétera. En ocasiones, además de los documentos del sistema,
la información de la entrevista puede ser la única fuente de datos sobre los requerimientos
del sistema.
Entrevistas

20. • Entrevistas cerradas, donde los participantes responden a un conjunto de preguntas
preestablecidas.
• Entrevistas abiertas, en las cuales no hay agenda predefinida. El equipo de
ingeniería de requerimientos explora un rango de conflictos con los participantes del
sistema y, como resultado, desarrolla una mejor comprensión de sus necesidades.
Tipos de Entrevistas

21. Los escenarios son particularmente útiles para detallar un bosquejo de descripción de
requerimientos. Se trata de ejemplos sobre descripciones de sesiones de interacción. Cada
escenario abarca comúnmente una interacción o un número pequeño de interacciones
posibles. Se desarrollan diferentes formas de escenarios y se ofrecen varios tipos de
información con diversos niveles de detalle acerca del sistema.
Un escenario comienza con un bosquejo de la interacción. Durante el proceso de
adquisición, se suman detalles a éste para crear una representación completa de dicha
interacción.
Escenarios

22. • Una descripción de qué esperan el sistema y los usuarios cuando inicia el escenario.
• Una descripción en el escenario del flujo normal de los eventos.
• Una descripción de qué puede salir mal y cómo se manejaría.
• Información de otras actividades que estén en marcha al mismo tiempo.
• Una descripción del estado del sistema cuando termina el escenario.
Un Escenario Puede Incluir

23. Un caso de uso identifica a los actores implicados en una interacción, y nombra el tipo de
interacción. Entonces, esto se complementa con información adicional que describe la
interacción con el sistema. La información adicional puede ser una descripción textual, o
bien, uno o más modelos gráficos como una secuencia UML o un gráfico de estado.
Los casos de uso se documentan con el empleo de un diagrama de caso de uso de alto nivel.
El conjunto de casos de uso representa todas las interacciones posibles que se describirán
en los requerimientos del sistema.
Casos de Uso

24. Ejemplo Diagrama de Caso de Uso

25. Es una técnica de observación que se usa para entender los procesos operacionales y ayudar
a derivar requerimientos de apoyo para dichos procesos. Un analista se adentra en el
ambiente laboral donde se usará el sistema. Observa el trabajo diario y toma notas acerca
de las tareas existentes en que intervienen los participantes. El valor de la etnografía es que
ayuda a descubrir requerimientos implícitos del sistema que reflejan las formas actuales en
que trabaja la gente, en vez de los procesos formales definidos por la organización.
Etnografía

26. La Etnografía Puede Combinarse con la Creación de
Prototipos
La etnografía informa del desarrollo del prototipo, de modo que se requieren menos ciclos
de refinamiento del prototipo.

27. Validación de Requerimientos
• Definición: es el proceso de verificar que los requerimientos definan realmente el
sistema que en verdad desea el cliente .
• Importancia: ayuda a reducir los errores durante y después del desarrollo de un sistema
y de esta forma evita grandes costos por tener que rehacer el proyecto.

28. Tipos de Comprobaciones de Requerimientos
• Comprobaciones de Validez: se debe identificar y analizar las funciones adicionales o
diferentes que se requieran en el sistema.
• Comprobaciones de Consistencia: los requerimientos en el documento no deben estar
en conflicto.
• Comprobaciones de Totalidad: el documento debe incluir requerimientos que definan
todas las funciones y restricciones para el sistema.
• Comprobaciones de Realismo: se debe comprobar los requerimientos para garantizar
que la implementación del sistema este dentro del presupuesto.
• Verificabilidad: Los requerimientos del sistema deben escribirse de manera verificable
para reducir disputas entre cliente y contratista

29. Tipos de Comprobaciones de Requerimientos
• Revisiones de requerimientos: los requerimientos se analizan sistemáticamente
para verificar errores e inconsistencias.
• Creación de prototipos: se muestra un modelo ejecutable del sistema en cuestión
a los usuarios finales y a los clientes.
• Generación de casos de prueba: los requerimientos deben ser comprobables y la
prueba de diseño debe ser fácil para que los requerimientos sean fáciles de
implementar.

30. Administración de Requerimientos
Los requerimientos para los grandes sistemas de software siempre cambian, ya que los
requerimientos para muchos sistemas por lo general se encuentran incompletos lo que
obliga a estar en un constante cambio de requerimientos para corregir los problemas que
se presenten.
Algunas razones de porque es inevitable los cambios son:
1. Por las modificaciones de las instalaciones del ambiente empresarial.
2. Por las diferencias entre el individuo que paga un sistema y los usuarios de dicho
sistema.
3. Los sistemas grandes están compuesto por comunidades de usuarios que a menudo
tienen diferentes requerimientos y prioridades.

31. Planeación de Administración de Requerimientos
En esta etapa se establece el nivel de detalle que se requiere en la administración
de requerimientos y hay que decidir sobre:
Identificación de requerimientos.
Un proceso de administración del cambio.
Políticas de seguimiento.
Herramientas de apoyo.

32. Administración de Cambios de Requerimientos
Identificación del
Problema
Análisis del
problema y cambio
de especificación
Análisis del cambio
y estimación del
costo
Implementación del
cambio
Revisión de
requerimientos

33. Bibliografía
Bicubic, Documento de requerimientos. (nd) extraído el 8 de marzo del 2014 desde
http://www.bicubic.cl/portal/es/tecnicos/documento-de-requerimientos.html
Campderrich, B. (2003). Ingeniería del software. Barcelona: Editorial UOC.
Sommerville, I. (2011). Ingeniería del software (9a. ed.). México: Pearson Educación.