INGENIERÍA DE

Unidad V

Analiza técnicas para aplicar las técnicas de

recopilación de información para obtener

REQUERIMIENTOS
los requisitos de un proyecto de software
para elaborar un documento de
especificación de requerimientos del
software para su desarrollo.
REQUERIMIENTO
La definición que aparece en [IEEE, 1990] es la
siguiente:

 una condición o capacidad que un usuario necesita para

resolver un problema o lograr un objetivo.

 una condición o capacidad que debe tener un sistema o un

componente de un sistema para satisfacer un contrato, una
norma, una especificación u otro documento formal.

 una representación en forma de documento de una condición

o capacidad expresadas anteriormente.
REQUERIMIENTO (OTRAS DEFINICIONES)

característica del sistema que es una condición

para su aceptación.

propiedad que un sistema debería tener para

tener éxito en el entorno en el que se usará.
REQUERIMIENTO (OTRAS DEFINICIONES)

Condición o capacidad que debe ser cumplida, o

poseída, por un sistema o componente de sistema,
para satisfacer un contrato, estándar, especificación
u otros documentos impuestos formalmente.

Sin embargo, a pesar de esta aparente simplicidad

del concepto, es frecuente encontrar el término
requerimiento calificado con adjetivos que
pueden resultar confusos en un primer momento:
de sistema, hardware, software, de usuario, de
cliente, funcional, no funcional, etc.
CARACTERÍSTICAS DE LOS REQUISITOS

Según el estándar IEEE-830 los requisitos deben ser:

Correctos
Consistentes
Completos
Realistas
Necesarios
Verificables
Rastreables
INGENIERÍA DE REQUERIMIENTOS
Proceso sistemático utilizado para derivar una definición del sistema de software
a ser desarrollado.

La ingeniería de requerimientos es un proceso que comprende todas las actividades de

desarrollo de software y relacionadas con la gestión y definición de requisitos para
sistemas nuevos o actuales.

 Comprende 4 actividades:

Estudio de factibilidad

Obtención, especificación y análisis de requerimientos

Validación de requerimientos

Administración de requerimientos
Estudio de factibilidad (I)
Un EF es a corto plazo y orientado a resolver el sistema si:

 Contribuye a los objetivos de la organización.

 Se puede implementar con tecnología actual dentro de costo y

tiempo.

 Puede integrarse a otros existentes en la organización.

Obtención, especificación y análisis de requerimientos (II)

Es un proceso difícil:

El cliente a menudo sólo conoce lo que se

desea en términos muy generales.

El cliente expresa los requerimientos con

sus propios términos y con un conocimiento
implícito de su propio trabajo.
Obtención, especificación y análisis de requerimientos (II)

Diferentes interesados tienen requerimientos

distintos y los expresan de diferentes
formas

Influencia de otros factores.

El entorno es dinámico, la importancia de los

requerimientos puede cambiar, nuevos
requerimientos pueden surgir.
Validación de requerimientos (III)

•Es similar al análisis de requerimiento pero comprende un

bosquejo completo del documento.

•Es importante validar los requerimientos ya que los

errores pueden conducir a costos excesivos si se
descubren durante el desarrollo o después de la
implantación.

•Es difícil demostrar que un conjunto de requerimientos

cumple con las necesidades del usuario.
Administración de requerimientos (IV)
Los requerimientos de sistemas grandes son siempre
cambiantes.

Surgirán nuevos requerimientos debido a:

 Comunidad de usuarios nueva.
 Quien paga raramente es quien usa el sistema.
 Entorno de negocios y técnico cambiante.

La AR es el proceso de comprender y controlar los cambios

en los requerimientos.
ESTUDIO DE FACTIBILIDAD
OBTENCIÓN, ESPECIFICACIÓN Y
ANÁLISIS DE LOS REQUERIMIENTOS
 Solicitud Definición

Especificación
Análisis
FUENTES DE POSIBLES
REQUERIMIENTOS
Por ejemplo se puede:

 Revisar la situación actual

 Trabajar en el ámbito del usuario para comprender el contexto, los problemas,

y las relaciones

 Entrevistar a los usuarios actuales y potenciales

 Realizar un video para mostrar cómo podría funcionar el nuevo sistema

 Investigar los documentos existentes

 Conducir lluvias de ideas con los usuarios actuales y potenciales

 Observar las estructuras y los patrones

TÉCNICAS DE RECOPILACIÓN DE
INFORMACIÓN

Muestreo
Observación
Entrevista
Cuestionario
Entre otras
 OBTENCIÓN, ESPEFICACIÓN Y
ANÁLISIS DE REQUERIMIENTOS

Cuando un cliente requiere que un nuevo sistema sea

construido, por lo general el cliente tiene alguna noción
de lo que el sistema hará.

Con frecuencia, el nuevo sistema reemplaza un sistema

existente o la forma de hacer las cosas.

A veces el nuevo sistema es una mejora o extensión de

un sistema actual, ya sea manual o automatizado.
OBTENCIÓN, ESPEFICACIÓN Y ANÁLISIS
DE REQUERIMIENTOS

Con mucha frecuencia, el sistema propuesto está planeado

para hacer cosas que nunca habían sido hechas antes.

Sin importar si su funcionalidad es vieja o nueva, cada

sistema software tiene un propósito, usualmente expresado
en lo que el sistema puede hacer.

Un requerimiento es una característica del sistema o una

descripción de algo que el sistema
es capaz de hacer con el objetivo de
satisfacer el propósito del sistema.
OBTENCIÓN, ESPEFICACIÓN Y ANÁLISIS
DE REQUERIMIENTOS

Cada uno de los requerimientos de un sistema trata con objetos o

entidades, los estados en los cuales pueden estar, y las funciones que
son ejecutadas para cambiar los estados o características de los
objetos.

Los requerimientos no deben especificar cómo el sistema será

implementado. Las descripciones específicas de implementación no
son consideradas parte de los requerimientos. Es decir, los
requerimientos direccionan el propósito del sistema sin considerar
como el sistema será implementado.

Los requerimientos identifican el ¿QUÉ?

del sistema a construir,
el diseño identifica el ¿CÓMO?
 OBTENCIÓN, ESPECIFICACIÓN Y
ANÁLISIS DE REQUERIMIENTOS

Obtención y análisis de Definición y especificación

los requerimientos de los requerimientos

Descripción Documentación
Análisis del
Del Y
problema
Problema validación

¿Hemos ¿Estamos usando

¿Hemos capturado
capturado las técnicas o
Lo que el usuario
todas las puntos
esperaba?
necesidades de vistea
del usuario? correctos?
OBTENCIÓN, ESPECIFICACIÓN Y
ANÁLISIS DE REQUERIMIENTOS
Por su origen:
 Funcionales
 Describen las funciones que lleva a cabo el software.
 Comportamiento de los distintos módulos.

 Ejemplo: El usuario debe ser capaz de buscar entre todo el conjunto de datos
en la BD.

 No funcionales
 Restricciones del sistema o de las funciones o servicios ofrecidos por el sistema.
 Ejemplo: tiempo de respuesta, almacenamiento, casos de uso, logística.
 El sistema no debe revelar al personal que lo utilice ninguna información
personal sobre los usuarios aparte de su nombre y DNI.

Por su aparición de cronología:

 De análisis (descubrimiento) y diseño

 De mantenimiento
Obtención, especificación y análisis de requerimientos
Funcionales
 Describen interacciones entre el sistema y su medio ambiente y cómo el sistema
debe comportarse ante ciertos estímulos dados.

SISTEMA PARA UN PUNTO DE VENTA DE UNA TIENDA COMERCIAL

Los requerimientos funcionales deben responder a preguntas acerca de

cuándo los tickets.

 ¿Qué entrada es necesaria para que un ticket se imprima?

 ¿Bajo qué condiciones puede cambiarse el monto del pago?
 ¿Qué provoca la eliminación de un articulo de la venta?

 Las respuestas a las preguntas destinadas a determinar los requerimientos

funcionales tienen respuestas que son independientes de la implementación de una
solución para el problema del cliente.
Obtención, especificación y análisis de requerimientos
No Funcionales
Describen restricciones sobre el sistema, las cuales limitan sus posibilidades
para construir una solución para el problema.

Estas restricciones por lo general estrechan la selección de lenguaje,

plataforma o técnicas y herramientas de implementación. Sin embargo, la
selección se realiza en la etapa del diseño después de haber especificado los
requerimientos.

SISTEMA PARA UN PUNTO DE VENTA DE UNA TIENDA COMPERCIAL

------ El sistema debe ser desarrollado sobre una computadora

Procesador CORE i9 – Memoria RAM 6GB – DD 250 GB

--- Los tickets deben entregarse al cliente al realizar la compra.
Tipos de requisitos
LOS REQUISITOS NO FUNCIONALES TAMBIÉN
SE PUEDEN CATEGORIZAR* EN:
Requisitos No
funcionales

Requisitos del Requisitos del Requisitos

producto proceso externos

Usabilidad Portabilidad Fiabilidad Eficiencia Entrega Interacción Ética Legislación

Ejecución Implementación Privacidad

Espacio Estándares Seguridad

*Ian Sommerville
Tipos de requisitos

Otras clasificación categoriza a los requisitos en:

Requisitos de usuario
El software debe proveer un medio de representar y acceder a los
archivos externos creados por otras herramientas.

Requisitos de sistema
Cada tipo de archivo externo debe poder tener asociada una
herramienta externa para editarlo y mostrarlo.

Requisitos de software
Los iconos de tipos de archivos se guardan con extensión tipo: *.jpg.
 PROCESO DE INGENIERÍA DE
REQUERIMIENTOS
Estudio de
Factibilidad

Análisis de
Requerimientos
Reporte de
Factibilidad Definición de
Requerimientos

Modelos del Especificación de

Sistema Requerimientos
Definición de
Requerimientos

Documento de
Especificación de
Requerimientos de
Especificación de
Software
Requerimientos
 DEFINICIÓN ESPECIFICACIÓN
Lo que el usuario espera Descripción Técnica de las
que el sistema haga características del Sistema
 TIPOS DE REQUERIMIENTOS
Ambiente Interfaz
Físico Factores
Humanos

Aseguramiento
de Calidad
Requerimientos
Funcionabilidad

Seguridad
Documentación

Recursos Datos
Tipos de Requerimientos
Los documentos de definición y especificación de requerimientos describen
cómo el sistema interactúa con su ambiente, incluyendo los siguientes aspectos:

Ambiente físico:

 ¿Dónde está el equipamiento que necesita el sistema para

funcionar?

 ¿Existe una localización o varias?

 ¿Existen restricciones ambientales, tales como temperatura,

humedad o interferencia magnética?
Tipos de Requerimientos

Interfaces:
 ¿La entrada proviene de uno o más sistemas?

 ¿La salida va a uno o más sistemas?

 ¿Existen una manera prescrita en que deban están los datos?

 ¿Existe un medio prescrito que los datos deban utilizar?

Tipos de Requerimientos
Usuarios y factores humanos:

 ¿Quién usará el sistema?

 ¿Habrá varios tipos de usuario?

 ¿Cuál es el nivel de habilidad de cada tipo de usuario?

 ¿Qué clase de entrenamiento requerirá cada tipo de usuario?

 ¿Qué tan fácil le será a un usuario comprender y utilizar el sistema?

 ¿Qué tan difícil le resultará a un usuario hacer uso indebido del sistema?
Tipos de Requerimientos

Funcionalidad:
 ¿Qué hará el sistema?

 ¿Cuándo lo hará?

 ¿Existen varios modos de operación?

 ¿Cómo y cuándo puede cambiarse o mejorarse un sistema?

 ¿Existen restricciones de la velocidad de ejecución, tiempo de respuesta o

rendimiento?
Tipos de Requerimientos
Documentación:

 ¿Cuánta documentación se requiere?

 ¿Debe estar en línea, en papel o en ambos?

 ¿A qué audiencia está orientado cada tipo de información?

Tipos de Requerimientos
Datos:

 ¿Cuál será el formato de los datos tanto para la entrada como para la salida?

 ¿Qué a menudo serán recibido o enviados?

 ¿Qué exactos deben ser?

 ¿Con qué grado de precisión deben hacerse los cálculos?

 ¿Cuántos datos fluyen a través del sistema?

 ¿Debe retenerse algún dato por algún periodo de tiempo?

Tipos de Requerimientos
Recursos:

 ¿Qué recursos materiales, personales o de otro tipo se requieren para

construir, utilizar y mantener el sistema?

 ¿Qué habilidades deben tener los desarrolladores?

 ¿Cuánto espacio físico será ocupado por el sistema?

 ¿Cuáles son los requerimientos de energía, calefacción o acondicionamiento

de aire?

 ¿Existe un cronograma prescrito para el desarrollo?

 ¿Existe un límite sobre la cantidad de dinero a gastar en el desarrollo o en

hardware y software?
Tipos de Requerimientos
Seguridad:

 ¿Debe controlarse el acceso al sistema o a la información?

 ¿Cómo se podrán aislar los datos de un usuario de los otros?

 ¿Cómo podrán aislarse los programas de usuario de los otros programas y

del sistema operativo?

 ¿Con qué frecuencia deben hacerse las copias de respaldo (backup)?

 ¿Las copias de respaldo deben almacenarse en un lugar diferente?

 ¿Deben tomarse precauciones contra el fuego, el daño provocado por agua o

el robo?
Tipos de Requerimientos
Aseguramiento de la calidad:

 ¿Cuáles son los requerimientos para la confiabilidad, disponibilidad,

facilidad de mantenimiento, exactitud, eficacia, integridad, facilidad de uso,
facilidad de prueba, flexibilidad, portabilidad, reusabilidad, facilidad de
interoperación?

 ¿Cómo deben demostrarse las características del sistema a terceros?

 ¿Debe el sistema detectar y aislar defectos?

 ¿Cuál es el promedio de tiempo prescrito entre fallas?

Tipos de Requerimientos
Aseguramiento de la calidad:

 ¿Existe un tiempo máximo permitido para la recuperación del sistema después de una
falla?

 ¿Cómo puede el sistema incorporar los cambios al diseño?

 ¿El mantenimiento corregirá meramente los errores, o incluirá también el mejoramiento

del sistema?

 ¿Qué medidas de eficiencia se aplicarán al uso de recursos y al tiempo de respuesta?

 ¿Qué tan fácil debe ser mover el sistema de una ubicación a otra o de un tipo de
computadora a otro?
VALIDACIÓN DE LOS
REQUERIMIENTOS
VALIDACIÓN DE LOS
REQUERIMIENTOS

 ¿Está el requisito claramente definido? ¿Puede interpretarse mal?

 ¿Está identificado el origen el requisito? (P.e. persona, norma, documento) ¿El

planteamiento final del requisito ha sido contrastado con la fuente original?

 ¿El requisito está delimitado en términos cuantitativos?

 ¿Qué otros requisitos hacen referencia al requerimiento estudiado?

 Validación de los requerimientos
 ¿El requisito incumple alguna restricción definida?

 ¿El requisito es verificable? ¿Podemos efectuar pruebas para

verificar el requisito?

 ¿Se puede localizar el requisito en el conjunto de objetivos

del sistema/producto?

 ¿Está el requisito asociado con los rendimientos del sistema o

con su comportamiento y han sido establecidas claramente
sus características operacionales?
 Validación de los requerimientos

Correctos
 Tanto el cliente como el desarrollador deben revisarlos para asegurar que no tienen
errores.

Consistentes
 Esto es que no sean conflictivos ni ambiguos. En otras palabras, dos requerimientos
son inconsistentes cuando no se pueden satisfacer simultáneamente.
 Validación de los requerimientos

Completos
 El conjunto de requerimientos es completo si todos los estados posibles, cambios de estado,
entradas, productos y restricciones están descritos en alguno de los requerimientos.

Realistas
 Esto es que el sistema pueda hacer lo que el cliente está pidiendo que haga.
 Validación de los requerimientos

Necesario
 A veces un requerimiento restringe innecesariamente a los
desarrolladores o incluye funciones que no están
directamente relacionadas con el problema que se está
tratando.

Verificables
 Se debe poder preparar pruebas que demuestren que se
han cumplimentado los requerimientos.
 Validación de los requerimientos

Rastreables
 Cada función del sistema se debe poder rastrear hasta el
conjunto de requerimientos que la establece. Debe ser fácil
encontrar el conjunto de requerimientos que concierne a un
aspecto específico del sistema.

Ejemplo:
 El sistema proporcionará respuesta en tiempo real a las consultas.
 El sistema deberá responder a las consultas en no más de dos segundos.
ADMINISTRACIÓN DE LOS
REQUERIMIENTOS
DOCUMENTO DE ER
EL DOCUMENTO DE REQUISITOS LA NORMA IEEE 830 -1993
DOCUMENTO DE ER
DOCUMENTO DE ER
DOCUMENTO DE ER