ADSI REQUISITOS

Competencia
Definir los requerimientos necesarios para construir
el sistema de información de acuerdo con las
necesidades del cliente.
 • EXPECTATIVAS?
PRESENTACIÓN

Diana Lorena Velandia Vanegas

Ingeniera de Sistemas Universidad del
Valle
Especialización Tecnológica en
Desarrollo de Aplicaciones para
Dispositivos Móviles
Especialización en Procesos para el
Desarrollo de Software.

dlvelandia@misena.edu.co

EVIDENCIA DE DESEMPEÑO FINAL?

Aplicación del Proceso de Requisitos a
un Caso Simulado y posteriormente al
Proyecto Formativo.
K. Pohl Requirements Engineering
ADSI
¿PARA QUÉ LOS REQUISITOS
O REQUERIMIENTOS?
 • Muchos de los problemas
encontrados en el desarrollo de
INTRODUCCIÓN
software se deben a la falta de
claridad en la recolección
documentación, y validación de
los requerimientos del mismo.
• Los requerimientos son un
punto clave que puede marcar
la diferencia entre el éxito y
fracaso de los proyectos de
desarrollo de software.
 • “Una condición o necesidad de un
usuario para resolver un problema o
¿Qué es un Requisito? alcanzar un objetivo”.
(Std 610.12-1900, IEEE: 62)
En la ingeniería de sistemas, un
• “Una condición o capacidad que
requerimiento es una necesidad debe estar presente en un sistema o
documentada sobre el contenido,
forma o funcionalidad de un producto componentes de sistema para
o servicio. Se usa en un sentido formal
en la ingeniería de sistemas o la
satisfacer un contrato, estándar,
ingeniería de software. especificación u otro documento
En la ingeniería clásica, los
formal”.
requerimientos se utilizan como datos
de entrada en la etapa de diseño del (Std 610.12-1900, IEEE: 62)
producto.
• “…es simplemente una declaración
Establecen QUÉ debe hacer el abstracta de alto nivel de un servicio
sistema, pero NO CÓMO hacerlo.
Ian Sommerville

Introducción
Veamos:
http://www.youtube.com/watch?v=gl
nrQ2fymSg&feature=related
http://www.youtube.com/watch?v=8T
ev7hyUYlE
http://www.youtube.com/watch?v=UZ
fpUdYLsao&feature=related
La fase del desarrollo de
requerimientos puede estar precedida
por una fase de análisis conceptual del
proyecto. Esta fase puede dividirse en
recolección de requerimientos, análisis
de consistencia e integridad, definición
en términos descriptivos para los
desarrolladores y un esbozo de
especificación, previo al diseño
completo.
 Entorno de Desarrollo de Requisitos – El término Requisito

Validación
Una condición o Capacidad
.... Requerida por un usuario Especificación

para resolver un problema. Análisis

.... Que debe alcanzar o poseer Levantamiento

un sistema o componente para
satisfacer un contrato, un
estándar, una especificación o
un documento formalmente
impuesto.
Una forma documentada de 1 o
2

Un requisito documentado en
adelante se llamará artefacto.
 • El desarrollo de requerimientos
puede ser subdividido en:
Desarrollo de Requisitos • Levantamiento, Análisis,
Especificación y Verificación. (Thayer
and Dorfman 1997).
Contexto
• Cada etapa deberá contar con
Educción técnicas claras, estándares, métodos
y herramientas que permitan
Documentación madurar los pasos del proyecto.
Negociación
Validación
Gestión
 • Metas y Objetivos
• Análisis: Identificación de
Requerimientos funcionales, Reglas del
Desarrollo de Requisitos Negocio, Atributos de Calidad,
Sugerencias de Solución e Información
extraña.
• Identificar los módulos o niveles del
sistema y clasificar los requerimientos
en cada uno de ellos.
• Negociación de prioridades de
desarrollo
• Escribir especificaciones de
requerimientos
• . Validación y acuerdos con el usuario
• . Validación del entendimiento del
problema
 Excelentes
Requerimientos

Desarrollo de Requisitos
Validación

Método de especificación de
Requerimientos

Técnicas de identificación de
Requerimientos

Métodos de Documentación

Herramientas y Estándar
 • Funcionales: Define un servicio que
el sistema debe proveer, el
TIPOS DE REQUISITOS comportamiento del sistema y en
algunos casos también lo que el
sistema no debe hacer.

• Un requerimiento funcional puede

ser una descripción de lo que un
sistema debe hacer. Este tipo de
requerimiento especifica algo que el
sistema entregado debe ser capaz de
realizar.

TIPOS DE REQUISITOS
Ejemplo:
El sistema debe estar disponible de
lunes a viernes de 6am a 9pm.
Calidad: Definen las propiedades de
calidad del sistema, componente,
servicio o función
• Influencian la arquitectura
• Normalmente no son detallados o
negociados
• Deben ser documentados aparte
• Diferentes clasificaciones ej:
ISO9126
 No funcionales
TIPOS DE REQUISITOS • Se usa pero realmente no
existen
• Principalmente son
Ejemplo de Requisito NO funcional:
El sistema debe ser seguro requisitos funcionales sin
Se convierte en Requerimientos de especificación
Calidad:
1. Cada usuario debe ingresar al
sistema con una clave de
• Muchos de ellos son
seguridad.
2. El sistema debe, cada cuatro requisitos de calidad
semanas, solicitar al usuario que
cambie la clave de seguridad
3. La clave de seguridad debe tener
al menos 8 caracteres .
4. La clave de seguridad debe tener
al menos un carácter especial.
 • Un requerimiento no funcional: de
rendimiento, de calidad, etc;
TIPOS DE REQUISITOS especifica algo sobre el propio
sistema, y cómo debe realizar sus
funciones. Algunos ejemplos de
aspectos solicitables son la
disponibilidad, el testeo, el
mantenimiento, la facilidad de uso,
etc.

TIPOS DE REQUISITOS
Ejemplo:
El sistema debe estar terminado y
operando en producción el 1 de enero
de 2013 a las 8:00 am
Restricciones: un
requerimiento organizacional
o tecnológico que restringe la
forma como el sistema debe
ser desarrollado (no se
implementan)
 • Otros tipos de limitaciones
TIPOS DE REQUISITOS
Una colección de requerimientos
describe las características o
atributos del sistema deseado. Se
omite el cómo debe lograrse su
implementación, ya que esto debe
ser decidido en la etapa de diseño
por los diseñadores.
externas, que afectan en una
forma indirecta al producto.
Estas pueden ir desde la
compatibilidad con cierto
sistema operativo hasta la
adecuación a leyes o
regulaciones aplicables al
producto. Requerimientos
Técnicos.
 • Pensamiento Analítico (abstracción)
Características de un • Empatía
Ingeniero de Requisitos
• Habilidades de comunicación
(escuchar, preguntar y traducir)
• Habilidades para solución de
conflictos (aplicar técnicas)
• Seguridad (Centro de atención)
• Persuasión (representa los
LA INGENIERÍA DE requisitos)
REQUISITOS ES UN
PROCESO CONTINUO.

K. Pohl 2011
 Como una de las primeras
Proceso continuo
fases en el proyecto
 Como una actividad
Proceso Continuo
transversal al ciclo de vida

Ventajas
Establece una línea base de
requisitos
Los requisitos están
permanentemente
actualizados
Tiempos de desarrollo mas
cortos
Permite reutilizar los
requisitos
Responsabilidades definidas
claramente
 Como una actividad
Proceso Continuo
transversal al ciclo de vida
del proyecto y del producto

K. Pohl 2011
 Depende del rol de cada
QUE vs COMO
stakeholder.
Stakeholder???
Un stakeholder es la persona interesada en el
proyecto como cliente o como usuario.

QUE vs En la medida en que se

avanza en la solución el
Cómo ? COMO se convierte en QUE
Problema
vs solución
QUE vd COMO
QUE vs COMO

Requisitos de Menor Detalle

El sistema debe validar si el Requisitos más Detallados

aprendiz puede matricularse en
El aprendiz puede matricularse en un
el programa.
programa si:
1. Esta registrado en Sofia Plus
2. Realizo prueba virtual
3. Realizo prueba de entrevista y prueba
situacional
4. No esta sancionado por matriculas en
programas anteriores
 Los requerimientos bien formulados deben
satisfacer varias características. Si no lo hacen,
deben ser reformulados hasta hacerlo.
Características

Necesario: Lo que pida un requerimiento debe

ser necesario para el producto.
Cada requerimiento debería documentar algo
que el usuario Realmente necesita. Algo que es
requerido por un estándar, o por variables
externas indispensables.

Es necesario aquel requerimiento que forma

parte de un contrato firmado y establecido.
Una manera de identificar requerimientos
necesarios, es si la fuente del requerimiento
viene de una fuente CON AUTORIDAD para
especificar requerimientos
 No ambiguo: El texto debe ser claro, preciso y
tener una única interpretación posible.
Características Un requerimiento es no ambiguo si todos los
lectores del requerimiento pueden llegar a
una simple y consistente interpretación.
Escribir los requerimientos en lenguaje
natural, y no en términos computacionales,
ayuda que un requerimiento pueda ser
interpretado y entendido sin ambigüedades.

Una forma efectiva para revelar ambigüedad

es hacer revisiones de los documentos,
diagramas, casos de uso, desarrollar
prototipos, pintar borradores de interfaces y
revisar escenarios de cada uno de ellos.
Características
 Correctos
Cada requerimiento especifica una funcionalidad
Características o condición que debe contener el software
No podemos contar con interpretaciones
incorrectas de funcionalidades a implantar.

El punto de referencia para validar si un

requerimiento es correcto o no, es la fuente del
mismo. El usuario directamente, o la
documentación de alto nivel que originó el
requerimiento.
Un usuario representativo, puede determinar si
el requerimiento es correcto o no.
Por ello es esencial incluir los usuarios durante el
Procesos de revisión de proceso de revisión de los requerimientos.
requerimientos que no
incluyen los usuarios,
podrían generar cosas
como . Es probable que
esto signifique....
 Conciso: Debe redactarse en un lenguaje
comprensible por los inversores en lugar
Características
de uno de tipo técnico y especializado,
aunque aún así debe referenciar los
aspectos importantes.

Consistente: Ningún requerimiento debe

entrar en conflicto con otro
requerimiento diferente, ni con parte de
otro. Asimismo, el lenguaje empleado
entre los distintos requerimientos debe
ser consistente también.
 Completo: Los requerimientos deben contener
en sí mismos toda la información necesaria, y no
remitir a otras fuentes externas que los
Características
expliquen con más detalle.

Requerimientos mal especificados, podrían

esconder información que no es fácil de detectar.
Puede ayudar a no tener requerimientos
incompletos, enfocarse en conocer las tareas del
usuario y no sesgarse en las funciones de un
sistema.

Si usted sabe que tiene información que falta

algo por conocer, utilice estrategia de marcas o
banderas, lo cual generen tareas «PENDIENTES
POR DETERMINAR».
 Alcanzable / Viables: Un requerimiento debe ser
un objetivo realista, posible de ser alcanzado con
el dinero, el tiempo y los recursos disponibles. Es
Características
mas fácil implementar requerimientos cuando se
conocen limitaciones técnicas, la capacidad, y las
condiciones del ambiente que rodea el proyecto.

Verificable: Se debe poder verificar con absoluta

certeza, si el requerimiento fue satisfecho o no.
Esta verificación puede lograrse mediante
inspección, análisis, demostración o testeo.
Trate de aplicar métodos formales, para realizar
pruebas que confirmen que el requerimiento
está correctamente especificado.
 • Contexto:
INICIEMOS!
 Es la parte del entorno del sistema que es relevante
para la definición y entendimiento de los requisitos.
Contexto

Una identificación incorrecta o incompleta del contexto

del sistema durante IR, genera requisitos incompletos y
erróneos.
Estos errores o faltas de completitud pocas veces son
identificados durante los procesos de validación. En la
mayoría de los casos se detectan cuando el sistema ya
está en operación.

Un requisito es definido en un contexto determinado y

solo puede ser interpretado correctamente en ese
contexto.
 Fronteras de Sistema y del Contexto

Contexto

Sistema e Interfaces
 Elementos del Contexto

Contexto
 Personas: Clientes, usuarios,
equipo de desarrollo (todos los
Contexto Fuentes de roles y los expertos del dominio.
Requisitos Documentación: Leyes,
procedimientos, sistemas legacy,
estándares.

Clasificación de los Aspectos del CONTEXTO

Contexto

Objetos del Objetos o personas materiales e

inmateriales que existen en el
Contexto contexto del sistema
 Cuando se define los elementos del Contexto
debemos tener en cuenta aspectos como:
Contexto Objetos y eventos que deben ser representados en el
sistema. De los que el sistema va a procesar y
almacenar información.
Todos los aspectos que se refieren al uso del sistema
por las personas u otros sistemas.
Todos los aspectos referentes a plataformas (HW,
SW), redes de comunicaciones, periféricos,
componentes ya existentes, otros sistemas.
Estrategias (PETI) y Políticas de TI.
Todos los aspectos que se refieren a proceso de
desarrollo, herramientas, métodos de aseguramiento
de calidad.
Pasos para recolección de Información

• El problema que se pretende solucionar

Identificar la
Necesidad

• OBSERVACION (Participante no participante)

• ENTREVISTA (Formal (estructurada, semi estructurada, libre) – Informal)
Técnicas e • ENCUESTA (Personal o por otros medios)
Instrumentos • SESION DE GRUPO (Coloquio, lluvia de ideas, simulación o taller)
de
Recolección • MÉTODO DELPHI

• Tabulación, gráficos
• Conclusiones
Análisis e • INFORME
Informe
 ¿PREGUNTAS?
Iniciemos Entonces a
aplicar lo aprendido…