L

UNIVERSIDAD DEL ISTMO

MATERIA:

ADMINISTRACION DE REQUERIMIENTOS DE SOFTWARE

INGIENERIA DE REQUERIMIENTOS

PROFESOR:

ALEJANDRO RAMOS

INTEGRANTES:

JOSE MACÍAS

FECHA DE ENTREGA:

23/abril/2020
 ÍNDICE
Introducción.......................................................................................................................................3
Definición...........................................................................................................................................4
Requisito............................................................................................................................................4
Importancia de La Ingeniería de Requisitos.......................................................................................5
Característica de los requerimientos..................................................................................................6
Procesos utilizados en Ingeniería de Requerimientos........................................................................6
métodos de Análisis de Requisitos.....................................................................................................7
Técnicas y herramientas utilizadas en la Ing. de requerimientos.....................................................10
Herramientas Case Para La Ingeniería De Requisito.........................................................................11
El límite de la Ingeniería de Requerimientos....................................................................................13
Conclusión........................................................................................................................................14
Referencias.......................................................................................................................................15

2
 Introducción

La comprensión de los requisitos de un problema y los requerimientos de un

producto o servicio están entre las tareas más difíciles que enfrenta un ingeniero
de Software. El Cliente no siempre sabe lo que se requiere, los usuarios finales no
siempre entienden bien las características que les proporcionarán un beneficio y
muchas veces los requisitos pueden cambiar durante el proyecto como también
suelen cambiar los requerimientos a medida que se va desarrollando el producto o
el servicio.

Es por ello que es la ingeniería de requisitos y requerimientos es una parte

fundamental a la hora de desarrollar no solamente un software si no cualquier
problema planteado.

3
Definición

La ingeniería de requisitos es la rama de la ingeniería del software o ingeniería de

sistemas que se encarga de la realización de actividades en el intento de entender
las necesidades exactas de los usuarios de un sistema y traducir éstas a precisas
funciones y acciones que subsecuentemente serán usadas en el desarrollo del
sistema. Loucopoulos, P (1995). System Requirements Engineering. McGraw-Hill.

Un requerimiento es una necesidad documentada sobre el contenido, forma o

funcionalidad de un producto o servicio. Los requerimientos son declaraciones que
identifican atributos, capacidades, características o cualidades que necesita
cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para
el usuario.

Requisito
Según la IEEE un requisito es:

 Una condición o capacidad requerida por un usuario para resolver un

problema o alcanzar un objetivo.
 Una condición o capacidad que debe cumplir o poseer un sistema o
componente de sistema para satisfacer un contrato, estándar,
especificación, o cualquier otro documento impuesto formalmente.
 Una representación documentada de una condición o capacidad de lo
explicado en los puntos 1 o 2.

Los requisitos pueden dividirse en:

 Requisitos de usuario: Son frases en lenguaje natural o descripciones

gráficas (diagramas) de los servicios que se espera que ofrezca el sistema
y de sus restricciones.
 Requisitos de sistema: Una descripción más detallada de los servicios
exactos que se proporcionarán y sus restricciones. Estos requisitos sirven
4
 como contrato con el cliente. A su vez los requisitos de sistema pueden
dividirse en requisitos funcionales, no funcionales y de dominio.

 Requisitos funcionales: Especifican lo que debe hacer o los servicios que

debe proporcionar el sistema. Ejemplo: en un software de gestión de una
biblioteca podrían ser requisitos funcionales dar de alta un cliente, alquilar
un libro, devolver un libro, comprar un libro, etc. Los requisitos funcionales
deben describir también cómo responderá el sistema ante estas distintas
entradas, y su comportamiento frente a situaciones particulares.
 Requisitos no funcionales: Son restricciones de los servicios del sistema o
funciones que ofrece. Ejemplo: en un software de gestión de compras de
una tienda podrían ser requisitos no funcionales un para pagar con tarjeta,
un PC con memoria y espacio en disco para almacenar la base de datos de
ventas, que sea capaz de atender a la vez a varios clientes, que no tarde
más de X tiempo en gestionar una venta, etc.
 Requisitos de dominio: Estos requisitos reflejan características del dominio
de la aplicación. Ejemplo: la forma en la que se comunicarán distintas
partes de la aplicación, el tipo de datos con los que trabajará, etc.

Importancia de La Ingeniería de Requisitos

 Permite gestionar las necesidades del proyecto en forma estructurada

 Mejora la capacidad de predecir cronogramas de los proyectos, así como
sus resultados
 Disminuye los costos y retrasos del proyecto
 Mejora la calidad del software
 Mejora la comunicación entre equipos
 Evita rechazos de los usuarios finales

5
Característica de los requerimientos

 Necesario: un requerimiento es necesario si su omisión provoca una

deficiencia en el sistema a construir.
 Conciso: un requerimiento es conciso si es fácil de leer y entender.
 Completo: un requerimiento está completo si no necesita ampliar detalles
en su redacción.
 Consistente: un requerimiento es consistente si no es contradictorio con
otro requerimiento.
 No ambiguo: para que se cumpla esta característica, el requerimiento debe
tener una sola interpretación.
 Verificable: permite hacer uso de los siguientes métodos de verificación:
inspección, análisis, demostración o pruebas.

Procesos utilizados en Ingeniería de Requerimientos

varían dependiendo del dominio de aplicación, de la gente implicada y de la

organización que desarrolla los requisitos. Sin embargo, hay un número de
actividades genéricas comunes a todos los procesos:

Actividades de la Ingeniería de Requisitos

 Actividades cíclicas que cumplen una buena práctica de ingeniería de

requisitos.
 Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el
nombre comúnmente dado a las actividades involucradas en el
descubrimiento preliminar de los requisitos de usuario.
 Estudio de viabilidad: En esta fase se estima si el problema del usuario se
podrá resolver con la tecnología disponible y si el sistema será rentable
según el presupuesto del que se dispone.
 Análisis: Sobre la base de la extracción realizada previamente, comienza
esta fase en la cual se interactúa con clientes o usuarios para determinar

6
 los requisitos funcionales y no funcionales del sistema, además del dominio
de la aplicación.
 Especificación: En esta fase se documentan los requisitos con mayor
detalle y precisión, de manera que sirva de base para un contrato entre el
desarrollador y el cliente.
 Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar
los requisitos, es decir, verificar todos los requisitos que aparecen en el
documento especificado para asegurarse de que son aceptados por el
cliente. Esto implica verificar que los requisitos sean consistentes, que
estén completos, que sean realistas y que puedan ser verificables.

Durante la etapa de especificación de requerimientos se pueden presentar

muchos inconvenientes los cuales son importantes de identificar y prevenir, a
continuación, se presenta un listado con los problemas más comunes en este
proceso:

a. Los requerimientos no son obvios y vienen de muchas fuentes.

b. Son difíciles de expresar en palabras (el lenguaje es ambiguo).

c. La cantidad de requerimientos en un proyecto puede ser difícil de manejar.

d. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

e. El usuario no puede explicar lo que hace, Tiende a recordar lo excepcional y

olvidar lo rutinario, Hablan de lo que no funciona, los usuarios tienen distinto
vocabulario que los desarrolladores.

métodos de Análisis de Requisitos

 método de Pressman

Para Pressman, en el proceso de análisis de requisitos del software se puede

identificar cinco tareas o etapas fundamentales:

7
  Reconocimiento del problema: Se basa en el estudio inicial de las
especificaciones del sistema y el plan del proyecto del software. El analista
debe establecer un canal adecuado de comunicación con el equipo de
trabajo involucrado en el proyecto. En esta etapa la función primordial del
analista en todo momento es reconocer los elementos del problema tal y
como los percibe el usuario.
 Evaluación y síntesis: Se centra en el flujo y estructura de la información,
definir las funciones del software, determinar los factores que afectan el
desarrollo de nuestro sistema, establecer las características de la interfaz
del sistema y descubrir las restricciones del diseño. Todas las tareas
anteriores conducen fácilmente a la determinación del problema de forma
sintetizada.
 Modelización: Se basa en la creación de modelos del sistema que servirán
para comprender mejor el proceso funcional, operativo y de contenido de la
información. El modelo servirá de pilar para el diseño del software y como
base para la creación de una especificación del software.
 Especificación: Las tareas asociadas con la especificación intenta
proporcionar una representación del software. Esto más adelante permitirá
llegar a determinar si se ha llegado a comprender el software, en los casos
que se lleguen a modelar se pueden dejar plasmados manuales.
 Revisión: Es la etapa final del levantamiento de requisitos y se enfoca en
demostrar que se ha llegado a un buen entendimiento de la forma de
implementar con éxito el software. La documentación del análisis de
requerimientos y manuales, permitirán una revisión por parte del cliente, la
cual posiblemente traerá consigo modificaciones en las funciones del
sistema por lo que deberán revisarse el plan de desarrollo y las
estimaciones previstas inicialmente.

 método de Core

Existen metodologías alternas como el Método CORE (Controlled Requirements

Expression) que plantean un escenario más técnico al realizar una ingeniería de

8
requerimientos sobre un software. Este método es un conjunto de notaciones
textuales y gráficas, con guías especificadas para la captura y validación de
requerimientos del sistema, en las etapas iniciales del diseño del sistema. Es
pensado como puramente una técnica de captura y análisis de requerimientos,
aunque soporta algunos aspectos de diseño tales como estructuras de datos.
CORE está basada en el principio de primero definir el problema a ser analizado y
luego dividirlo en unidades o puntos de vista a considerar.

Esta metodología se basa en 7 aspectos:

 Definición del problema: El propósito de la definición del problema es

identificar los límites del mismo. Contiene detalles de los objetivos de la
empresa de los usuarios del sistema, la base para la necesidad de un
nuevo sistema, limitaciones de costo y tiempo, y quién va a ser el
responsable de la revisión y aceptación de los resultados finales.
 Estructuración del punto de vista: El propósito de esta etapa es
descomponer el ambiente del sistema en los elementos para que el
sistema propuesto pueda ser analizado desde los puntos de vista de
todas las entidades que se comunican con él, la más importante de las
cuales son los usuarios. Durante esta etapa, todas las entidades que
son fuentes potenciales de información deben ser identificadas.
 Colección tabular: Esta etapa es cuando la información sobre los flujos
de datos entre los puntos de vista y el procesamiento de éstos son
reunidos. Esto ayuda a establecer la totalidad y consistencia.
 Estructuración de datos: En la etapa previa, los elementos de
información que pasan entre los puntos de vista son referidos por sus
nombres generales. En esta etapa, se da una vista más cercana al
contenido, a la estructura y a la derivación de datos, al producir
diagramas de estructura de datos.
 Modelación individual de puntos de vista: Esta etapa puede dividirse en
dos partes. Lo único concerniente a la primera es convertir las TCF'S en
una notación diferente para producir los diagramas individuales del

9
 modelo de punto de vista. La segunda parte se refiere a agregar alguna
información nueva perteneciente a flujos de datos internos, control de
acciones y tiempo de acciones.
 Modelación combinada de punto de vista: Esta etapa facilita el análisis
de una secuencia de eventos de más de un punto de vista. Cada
diagrama de modelo combinado de punto de vista producido durante
esta etapa es una representación del procesamiento de información que
ocurre entre puntos de vista.
 Análisis de restricciones: En esta etapa, se consideran restricciones
adicionales tales como desempeño y seguridad. Éstas pueden afectar
los diagramas de puntos de vista ya producidos. Las restricciones se
documentan en una especificación de restricción del sistema

Técnicas y herramientas utilizadas en la Ing. de

requerimientos

 Observación y análisis social: La observación permite a los investigadores

observar lo que los usuarios hacen actualmente en un determinado
contexto.
 Lluvia de Ideas: Son sesiones donde todos los participantes brindan sus
ideas para obtener una solución a una problemática.
 Modelos: Esquema teórico, generalmente en forma matemática, de un
sistema o de una realidad compleja, como la evolución económica de un
país, que se elabora para facilitar su comprensión y el estudio de su
comportamiento. Y muchos más antes mencionados.

10
Herramientas Case Para La Ingeniería De Requisito

Las herramientas para la gestión de requisitos de software se limitaban a editores

de texto, los cuales hacían de esta tarea una labor tediosa y confusa.
Actualmente, se cuenta con múltiples opciones, como las que se mencionan a
continuación:

IRQA 43

Herramienta CASE de Ingeniería de Requisitos, diseñada para soportar las

actividades realizadas en el proceso de especificación de sistemas. Ésta facilita y
formaliza la comunicación entre el cliente, el proveedor y los distintos miembros
del equipo de desarrollo.

Facilita la captura, organización y análisis de las condiciones, así como la

especificación de la solución mediante el apoyo metodológico adaptable a cada
cliente.

RETO

Esta herramienta propone un modelo de requisitos para capturar los aspectos

funcionales del sistema; básicamente, mediante tres técnicas complementarias
entre sí: la definición de la Misión del Sistema, la construcción del Árbol de
Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso.

Además, se introduce un Proceso de Análisis que permite traducir el Modelo de

Requisitos en el Modelo Conceptual, manteniendo la trazabilidad entre ambos y
propiciando una representación de la información en el segundo prototipo.

CONTROLA

11
Herramienta de apoyo al proceso de ingeniería de software en pequeñas
empresas. Se creó gracias a la expansión que tuvo el mercado y a la generación
de grandes y pequeñas empresas, las cuales requieren un instrumento para el
desarrollo de sus proyectos.

Ofrece recursos importantes tales como: Administración de requisitos,

administración de casos de uso, administración de casos de prueba y error,
planeamiento de liberaciones, administración de implementaciones, control de
dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de
los requisitos.

OSRMT (Open Source Requirements Management Tool)

Herramienta libre para la gestión de requisitos, cuyas principales características

son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versión 1.3
trae un módulo para manejar la trazabilidad y lo introduce para el control de
cambios; así mismo, genera la documentación de los requisitos tratados.

JEREMIA

Se trata exclusivamente de una aplicación cliente exclusivamente, lo cual no

permite la posibilidad de trabajar en equipo. Ésta, ayuda durante el desarrollo del
sistema, especialmente en el seguimiento de cambios de los requisitos a lo largo
del ciclo de vida.

Con JEREMIA es posible captar las necesidades, analizarlas y clasificarlas.

Implementa un módulo orientado a la generación de la documentación posible de
exportar en formato DocBook XML, la cual, junto con los requisitos, se almacena
en una base de datos en MySQL.

12
El límite de la Ingeniería de Requerimientos

Existe un límite fundamental, y sobre todo inherente a la construcción de software,

que afecta a la Ingeniería de Requerimientos. Este límite puede expresarse de la
siguiente forma: virtualmente imposible iniciar la construcción de un sistema de
software teniendo la lista completa y consistente de todos los requerimientos, en
un tiempo razonable. Entre las razones que justifican esta hipótesis tenemos las
siguientes:

 Usualmente se requiere que los grandes sistemas de software constituyan

una superación del estado del arte en cierto dominio de aplicación.
 Los grandes sistemas normalmente son utilizados por una comunidad de
usuarios muy diversos. Esto implica que cada grupo de usuarios planteara
expectativas y requerimientos diferentes sobre el sistema.
 En general la gente que paga por el sistema y quienes lo usan no son los
mismos, lo que genera conflicto entre lo que se puede pagar y lo que se
necesita.
 La introducción de un sistema de software importante en una organización
es tan disruptiva que suele producir cambios igualmente importantes en la
organización lo que, a su vez, genera nuevos requerimientos sobre el
sistema. El entorno en el cual se instala y opera el sistema cambia por lo
que el sistema debe cambiar también.
 El negocio de la empresa productora del software suele cambiar por lo que
sus ejecutivos solicitan nuevas funciones o cualidades al sistema.

13
Conclusión

La Ingeniería de Requisitos e requerimientos es una compleja disciplina que trata

de formalizar las actividades relacionadas con obtener la especificación de
requisitos formales del producto y sistema a desarrollar a base de interactuar y
negociar con el cliente. Especialmente en las metodologías 'pesadas' o
tradicionales del desarrollo de software es crucial contar con un conjunto de
requisitos muy estables sobre los que construir el resto del proyecto

Es importante tomarse el tiempo necesario para conocer a nuestros clientes y

usuarios, así como su ambiente de trabajo. Esto, también ayuda a establecer una
buena relación de trabajo y comunicación entre el equipo de desarrollo y los
clientes. Entregar software de calidad, a tiempo y dentro del presupuesto, hará
que nuestros clientes confíen y asegurará el crecimiento y madurez de la relación
de negocio.

14
 Referencias
https://www.researchgate.net/publication/319728760_Introduccion_a_la_Ingenieria_de_Requeri
mientos

http://phigux.blogspot.com/2012/03/dificultades-para-definir-los.html

http://tecnologicofch.blogspot.com/2013/

https://image.slidesharecdn.com/ingenieriaderequisitos-150519000745-lva1-app6891-
170123222831/95/ingeniera-de-requisitos-e-ingeniera-de-requerimientos-16-638.jpg?
cb=1485210557

https://www.ecured.cu/Requisitos_de_Software

https://slideplayer.es/slide/1687281/

15