"La tarea más difícil de construir un sistema del software es

precisamente decidir qué construir. Ninguna otra parte del

trabajo conceptual es tan difícil como establecer los
requisitos, incluyendo todas las interfaces a las personas, a
las máquinas, y otros sistemas del software. Ninguna parte
del trabajo lesiona tanto al sistema resultante si hace mal.
Ninguna otra parte es más difícil rectificar después

 RE es la rama de la ingeniería de sistemas que trata la

identificación del propósito de un sistema de software y el
contexto en el cual será usado. RE actúa como un puente
entre las necesidades del mundo real de los clientes,
usuarios y otros actores afectados por el sistema de
software, así como también de las capacidades y
oportunidades ofrecidas por la tecnología de software.
No tiene sentido ser preciso si no se sabe de que se está
hablando
1. Cuanto más tarde en el ciclo de vida se detecta un error, más cuesta
repararlo.
2. Muchos errores permanecen latentes y no son detectados hasta bastante
después de la etapa en que se cometieron. Muchos podrían detectarse
tempranamente.
2. Se cometen muchos errores de requisitos

Impacto de los errores en la etapa de requisitos

• El software resultante puede no satisfacer a los usuarios
• Las interpretaciones múltiples de los requisitos pueden causar desacuerdos
entre clientes y desarrolladores
• Es imposible que a través del testeo el software satisfaga sus requisitos
• Puede gastarse tiempo y dinero construyendo el sistema erróneo
 Es una condición o capacidad que debe
cumplir o poseer un sistema o componente
de un sistema para satisfacer un contrato,
Standard, o especificación o algún otro
documento impuesto.

 El conjunto de requisitos forma la base para

el desarrollo de un sistema o una
componente de sistema.
 Requisitos funcionales: describen lo que el
sistema debería hacer
Ej.: el sistema debe proveer autenticación de la identidad de un usuario
Ej.: el sistema debe emitir una factura

 Requisitos no funcionales: establecen

restricciones de cómo estos requisitos funcionales
son implementados.
EJ.: el proceso de autenticación debería completarse en menos de 4
segundos
EJ.: la emisión de factura debe poder hacerse desde cualquier terminal
de trabajo
 Identificar la fuente de los requerimientos

 Entrevistar a los StakeHolders para validar y

refinar los RF y los RNF.

 Documentar la especificación de requerimientos

de software (ERS) utilizando todas las fuentes de
requerimientos.
Los requerimientos de un sistema pueden aparecer desde
muchas fuentes. He aquí las más importantes:
 Entrevistas con StakeHolders

 Observar a los usuarios realizar su trabajo

 Analizando y documentando políticas y procedimientos

 Analizando el sistema existente

 Analizando y documentando entradas y salidas

La lista inicial de stakeholders provienen del dueño de la
empresa.
De todas maneras esa lista puede ser expandida una vez
comenzada la primer ronda de entrevistas con los
stakeholders.
Stakeholder incluye:
 Los usuarios primarios del sistema.
 Usuarios operacionales del sistema, administradores del sistema y
administradores de redes.
 Gerentes de los usuarios primarios y operacionales.
 Expertos de dominio
 Gerente de marketing del producto.
Especificación de los
Requerimientos del
Sistema (ERS)
La ERS es el contrato entre el
cliente y el proveedor, registra
lo que el sistema debe realizar
y con qué calidad.
 ESPECIFICACIÓN: Es un documento que define de
forma completa, precisa y verificable los requisitos, el
diseño, el comportamiento de un sistema.

 SOFTWARE: Conjunto de programas, procedimientos

y documentación asociada a la operación de un sistema
informático
La ERS se puede definir como:
 Documentación de los requisitos esenciales del
software y de sus interfaces externas.

Las dos características fundamentales de una ERS

son:
› 1. Debe incluir información veraz, coherente con las
necesidades reales del usuario
› 2. Debe comunicar dicha información de forma eficaz,
es decir de forma que se pueda comprender.
La ERS describe lo que HAY que desarrollar, NO el
COMO ni el CUANDO, esto implica:
 1. Describir correctamente todo los requisitos del
software, sin incluir requisitos innecesarios

 2. No describir ningún detalle del diseño de software, de

su verificación o de la dirección del proyecto.

En definitiva se trata de especificar lo que desea el

usuario sin considerar como se va a solucionar.
 1. Ayudar a los clientes a describir claramente lo que se desea
obtener de un determinado software: El cliente debe participar
activamente, ya que éste tiene una visión mucho más detallada de
los procesos que se llevan a cabo y también se siente partícipe del
propio desarrollo.

 2. Ayudar a los desarrolladores a entender qué quiere exactamente

el cliente: En muchas ocasiones el cliente no sabe exactamente
qué es lo que quiere. La ERS permite a los desarrolladores tener
una base fija en la que trabajar.

 3. Servir de base para desarrollos de estándares de ERS

particulares para cada organización: Cada entidad puede
desarrollar sus propios estándares para definir sus necesidades.
 El contrato entre cliente y desarrolladores
 La reducción del esfuerzo en el desarrollo,
 Una buena base para la estimación de costos y
planificación,
 Un punto de referencia para procesos de verificación y
validación,
 Una base para la identificación de posibles mejoras en
los procesos analizados.
 No Ambigua:
 Un requisito ambiguo se presta a distintas interpretaciones, por lo tanto
cada requisito debe tener una sola interpretación.
 En caso de que un termino es usado en distintos contextos debe incluirse
en un glosario, donde se determina la forma exacta de su significado.
 Los requisitos se deben escribir en lenguaje natural lo que implica un
riesgo.

 Completa:
 1. Incluye todos los requisitos significativos del Software
 2. Esta conforme con cualquier estándar de especificación que se deba
cumplir
 3. Están etiquetadas y referenciadas todas las figuras, tablas, diagramas,
términos y unidades de medida.
 Fácil de Verificar:
 Es si y solo si cualquier requisito al que se haga referencia se puede
verificar fácilmente.

 Consistente:
 Es si y solo si ningún conjunto de requisitos descriptos son contradictorios
o entran en conflicto.

 Fácil de Modificar:
 Si su estructura y estilo permiten que cualquier cambio en los requisitos se
pueda hacer fácil, completa y consistente.
 Debe tener una organización coherente y manejable, con tabla de
contenidos, índice y referencias.
 No debe ser redundante; o sea que el mismo requisito no aparezca en mas
de un lugar de la ERS.
 Facilidad para identificar el Origen y las
consecuencias de cada requisito (trazabilidad):
 Si se establece un origen claro para cada uno de los requisitos y si
posibilita las referencias de estos requisitos en desarrollos futuros.
 Cada requisito debe tener un nombre y/o número debe referencia único,
que sirva para identificarlo en futuros documentos.
 Cuando un requisito representa una derivación de otro requisito, se debe
facilitar la referencia hacia atrás como hacia delante.
Cualquier ERS que este bien escrita debería
incluir toda la información necesaria para el
equipo de desarrolladores

Se presenta una sugerencia de estructura.

Los riesgos es una de las principales razones por las que
un proyecto fracasa. La identificación temprana y el plan
de mitigación ayudan a que un proyecto sea exitoso.

Las 5 áreas principales de riesgos son:

 Políticos
 Tecnológicos
 Recursos
 Habilidades
 Requerimientos
Los riesgos políticos existen cuando:
 Existe un proyecto que compite o bien otro proveedor.

 Hay problemas interpersonales o internas o bien dentro del equipo de

desarrollo o en la gerencia.

 El proyecto tiene conflictos con las leyes gubernamentales

Un riesgo tecnológico existe cuando un proyecto debe usar una

tecnología desconocida para el equipo, de vanguardia o de uso
dificultoso.
Un riesgo de recurso existe cuando el proyecto no tiene todo el recurso
(humano, equipamiento o financiero) requerido para realizarse
exitosamente.
Algunos indicios son:
 El propietario de la empresa comenta que el proyecto tiene un
presupuesto apretado.

 El staff de IT está actualmente sobrecargado.

 El proyecto es apretado en cuestión de tiempos.

Los riesgos sobre habilidades existen cuando el equipo de
desarrollo no posee el conocimiento o la experiencia
necesaria para realizar el trabajo en las condiciones
dadas.
Algunos indicios son:
 Cuando el proyecto tiene restricciones para usar una
tecnología específica pero el equipo no tiene
entrenamiento en esa área.

 Cuando el proyecto debe ser desarrollado en un lenguaje

desconocido para el equipo de desarrollo.
Un riesgo de requerimiento existe cuando algún caso de uso
no es completamente conocido.
Algunos indicios:
 Cuando el dueño del negocio dice algo parecido a “Te lo
voy a decir bien cuando revise en detalle”

 Cuando el dueño no puede proveer un escenario para el

caso de uso

 Cuando el propietario del negocio no sabe que un caso

de uso existe.