Clase 01 Tecnicas de Busqueda de Requerimientos 13 12 23

CARRERA: DESARROLLO DE SISTEMAS DE INFORMACION
Curso
Técnicas de búsqueda de requerimientos
Clase 1: Conceptos. Clasificación. Actividades del Análisis de

requerimientos. Procesos de Búsqueda de Requerimientos
Lima, 13 de diciembre de 2023

Prof. Juan Daniel Daza Hermoza
Diapositiva 2 Fecha: 13/12/2023
ingenieria.sistemas.2030@gmail.com
1. Tener los micrófonos apagados.
2. Sólo active su micrófono si va a participar,

después lo desactiva.

Para participar levante la
mano, indique su nombre y
el lugar de donde se conecta

Participación de todos ustedes
¡¡¡¡¡Poner en
el Zoom sus
nombres
completos!!!!!

Empecemos
la Clase!!!!

¿Qué es Requerimiento? Participación
de los alumnos

"Requerimientos" es un término que se utiliza
para referirse a las condiciones o necesidades
específicas que deben ser cumplidas o
satisfechas en un determinado contexto.
En el ámbito empresarial, los "requerimientos"

suelen hacer referencia a las especificaciones,
características o funcionalidades que un
producto, servicio o sistema debe cumplir para
satisfacer las necesidades del cliente o del
usuario.

Los Requerimientos de Software
son las necesidades de los Necesario
Stakeholders que requiere que el Claro Completo

Sistema deba de cumplir de
manera Satisfactoria.
Verificable Consistente
Son los que definen las funciones Características
de un buen
que el sistema será capaz de requerimiento
realizar, describen las

transformaciones que el sistema
Priorizado Correcto
realiza sobre las entradas para
producir salidas.
Modificable Factible

¿Qué son Stakeholders?
Los stakeholders, también conocidos como partes
interesadas, son todas las personas o entidades que
tienen interés, influencia o impacto en una empresa
u organización. Esto puede incluir empleados,
clientes, proveedores, accionistas, comunidades
locales y otros grupos que se ven afectados por las
actividades de la empresa.
Los stakeholders tienen un papel importante en la

toma de decisiones y en la dirección estratégica de la
organización, ya que sus intereses y preocupaciones
deben ser tenidos en cuenta.
Para PRESSMAN, Roger S. La búsqueda de requisitos proporciona
el mecanismo apropiado para entender:
❖ Lo que el cliente quiere, analizar las necesidades.

❖ Evaluar la factibilidad.
❖ Negociar una solución razonable.
❖ Especificar la solución sin ambigüedades.
❖ Validar la especificación.
❖ Administrar los requisitos conforme éstos se transforman en un sistema operacional.
El proceso de la búsqueda de requisitos
se lleva a cabo a través de siete distintas funciones:
Inicio, Obtención, Elaboración, Negociación, Especificación, Validación y Gestión

Según F. P. Brooks dice: Lo más difícil en la construcción de
un sistema de software es decidir precisamente qué construir.
No existe tarea con mayor capacidad de lesionar al sistema, cuando se hace mal. Ninguna
otra tarea es tan difícil de rectificar a posteriori. La evidencia empírica demuestra que:
❖ Los requisitos contienen demasiados errores

❖ Muchos de estos errores no se detectan al principio
❖ Muchos de estos errores podrían ser detectados al principio
❖ No detectar estos errores incrementará los costes(tiempo, dinero) de forma
exponencial
❖ Además, los programadores obedecen los requisitos (cuando existen).

BUSQUEDA DE REQUERIMIENTOS
El proceso de recopilar, analizar y verificar las necesidades del

cliente para un sistema de software es llamado búsqueda de
Requerimientos.
La meta de la búsqueda de requerimientos es entregar una
especificación de requerimientos de software correcta y
completa.
La búsqueda de requerimientos apunta a mejorar la forma en que
comprendemos y definimos sistemas de software complejos.
Existen varias definiciones de requerimientos, de entre las cuales
podemos citar las siguientes:

1. Condición o capacidad requerida por el usuario para resolver un
problema o alcanzar un objetivo
2. Condición o capacidad que debe satisfacer o poseer un sistema o una componente
de un sistema para satisfacer un contrato, un standard, una especificación u otro
documento formalmente impuesto
3. Representación documentada de una condición o capacidad como en 1 o 2.
La técnica de búsqueda de requerimiento o requisitos es un proceso

sistemático y disciplinado para la especificación y administración de
éstos con las siguientes metas:
❖Entender el problema por el que surge la necesidad del software.

❖Documentar las necesidades de los stakeholders
La fase de definición de requerimientos es sumamente importante,
ya que se necesita mucha disposición por parte del cliente o usuario,
de paciencia y creatividad por parte de los analistas para lograr buenos resultados. Las
actividades principales del proceso de definición de requerimientos pueden dividirse en 4:
Extracción.
Consiste en una comunicación intensa con el
cliente/usuario para establecer claramente el
problema que requiere una solución.
Diferentes técnicas deben ser usadas en combinación
para obtener la mayor cantidad de información.
Algunas técnicas: entrevistas, cuestionarios, prototipos
(en papel) y sesiones de lluvia de ideas, entre otros.

Análisis.
Inicia una vez que se cuenta con la información obtenida. Usa técnicas de modelado y
lenguajes como UML y BPMN para plasmar conceptos que son parte del problema y que
formarán parte de la solución. Lo ideal es que haya una iteración de las primeras dos
actividades antes de pasar a la especificación, aunque pueden repetirse en cualquier
momento.

Especificación
El objetivo es documentar los requerimientos en formatos establecidos. Los modelos
generados en la etapa de análisis también forman parte de la especificación. Documentos
con el listado de requerimientos funcionales, no funcionales, reglas de negocio, casos de
uso y diagramas de estados y clases, por ejemplo, conforman el paquete que especifica el
software a ser construido.
Validación y verificación
La información que ha sido documentada en la
especificación debe ser validada por el cliente, de forma
que esté de acuerdo con lo establecido.

Falconi Nieto Luís
Cornejo Huayanay Juan Héctor
Fernández Calderón Percy Williams
Ortiz Alanoca Vaner

Los requerimientos se pueden definir de distintas maneras, la
primera clasificación que encontramos se encuentra relacionada
con el nivel de descripción con la que cuentan los requerimientos.
Dentro de este tipo de clasificación encontramos los siguientes:
1. REQUERIMIENTOS DE USUARIO:
Son declaraciones, en lenguaje natural y en diagramas, de los servicios
que se espera que el sistema proporcione y de las restricciones bajo
las cuales debe funcionar.
Los requerimientos de usuario pueden incluir aspectos funcionales,

de rendimiento, de usabilidad, de seguridad, entre otros, y es
importante identificarlos de manera precisa para garantizar la
satisfacción del usuario final.
2. LOS REQUERIMIENTOS DEL SISTEMA:
Establecen con detalle los servicios y restricciones del sistema. El documento de
requerimientos del sistema, algunas veces denominado Especificación funcional, debe ser
preciso. Éste sirve como un contrato entre el comprador del sistema y el desarrollador de
software.
2.1. Requerimientos funcionales:
Son declaraciones de los servicios que debe proporcionar el sistema, de la manera
en que éste debe reaccionar a entradas particulares. O también pueden declarar
explícitamente lo que el sistema no debe hacer.

2.2. Requerimientos no funcionales:
Son restricciones de los servicios o
funciones ofrecidos por el sistema.
Incluyen restricciones de tiempo,
sobre el proceso de desarrollo y
estándares.
Dentro de estos requerimientos
encontramos todo lo referente a
fiabilidad, el tiempo de respuesta y
la capacidad de almacenamiento.

Ejemplos de requisitos no funcionales
Estos son algunos ejemplos de requisitos no funcionales:
Seguridad: El sistema debe estar protegido contra el acceso no autorizado.
Actuación: El sistema debe poder manejar el número requerido de usuarios sin

ninguna degradación en el rendimiento.
Escalabilidad: El sistema debe ser capaz de escalar hacia arriba o hacia abajo según sea
necesario.
Disponibilidad: El sistema debe estar disponible cuando sea necesario.

Mantenimiento: El sistema debe ser fácil de mantener y actualizar.
Portabilidad: El sistema debe poder ejecutarse en diferentes plataformas con cambios

mínimos.
Fiabilidad: El sistema debe ser confiable y cumplir con los requisitos del usuario.
Usabilidad: El sistema debe ser fácil de usar y comprender.
Compatibilidad: El sistema debe ser compatible con otros sistemas.
Compliance: El sistema debe cumplir con todas las leyes y reglamentos aplicables.

Los requisitos no funcionales son esenciales para cualquier sistema.
Ayudan a garantizar que el sistema satisfaga las necesidades del
usuario y pueda funcionar según lo previsto. Es importante considerar cuidadosamente
todos los requisitos no funcionales antes de diseñar y desarrollar un sistema.
En un primer nivel, los requerimientos no funcionales pueden clasificarse en requerimientos
de producto, organizacionales y externos
En un segundo nivel, los requerimientos de producto pueden clasificarse en requerimientos
de usabilidad, eficiencia, dependibilidad y seguridad. A su vez, los requerimientos
organizacionales pueden clasificarse en requerimientos de entorno, organizacionales y de
desarrollo. Asimismo, los requerimientos externos pueden clasificarse en requerimientos
regulatorios, éticos y legislativos.

EJEMPLOS DE REQUERIMIENTOS NO FUNCIONALES DE PRODUCTO
Eficiencia
❖ El sistema debe ser capaz de procesar N transacciones por segundo. Esto se medirá por
medio de la herramienta SoapUI aplicada al Software Testing de servicios web.
❖ Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en
menos de 5 segundos.
❖ El sistema debe ser capaz de operar adecuadamente con hasta 100.000 usuarios con
sesiones concurrentes.
❖ Los datos modificados en la base de datos deben ser actualizados para todos los
usuarios que acceden en menos de 2 segundos.

Seguridad lógica y de datos
❖ Los permisos de acceso al sistema podrán ser cambiados solamente por el

administrador de acceso a datos.
❖ El nuevo sistema debe desarrollarse aplicando patrones y recomendaciones de
programación que incrementen la seguridad de datos.
❖ Todos los sistemas deben respaldarse cada 24 horas. Los respaldos deben ser
almacenados en una localidad segura ubicada en un edificio distinto al que reside el
sistema.
❖ Todas las comunicaciones externas entre servidores de datos, aplicación y cliente del
sistema deben estar encriptadas utilizando el algoritmo RSA.
❖ Si se identifican ataques de seguridad o brecha del sistema, el mismo no continuará
operando hasta ser desbloqueado por un administrador de seguridad.
Usabilidad
❖ El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 4 horas.
❖ La tasa de errores cometidos por el usuario deberá ser menor del 1% de las
transacciones totales ejecutadas en el sistema.
❖ El sistema debe contar con manuales de usuario estructurados adecuadamente.
❖ El sistema debe proporcionar mensajes de error que sean informativos y orientados
a usuario final.
❖ El sistema debe contar con un módulo de ayuda en línea.
❖ La aplicación web debe poseer un diseño “Responsive” a fin de garantizar la
adecuada visualización en múltiples computadores personales, dispositivos tableta y
teléfonos inteligentes.
❖ El sistema debe poseer interfaces gráficas bien formadas.
Ejemplos de requerimientos no funcionales organizacionales
❖ El procedimiento de desarrollo de software a usar debe estar definido explícitamente

(en manuales de procedimientos) y debe cumplir con los estándares ISO 9000.
❖ La metodología de desarrollo de software será Behaviour Driven Development (BDD)
apoyada en Cucumber.
❖ El sistema debe ser desarrollado utilizando las herramientas CASE XYZ.
❖ El proceso de desarrollo se gestionará por medio de una determinada herramienta web
para gestionar el proceso de desarrollo de software.
❖ Debe especificarse un plan de recuperación ante desastres para el sistema a ser
desarrollado.
❖ Cada dos semanas deberán producirse reportes gerenciales en los cuales se muestre el
esfuerzo invertido en cada uno de los componentes del nuevo sistema.
❖ Las pruebas de software se gestionaran con una herramienta de gestión de software
testing. Diapositiva 31 Fecha: 13/12/2023
¿ISO 9000 para qué sirve? La norma ISO 9000 es un conjunto de normas
industriales mundiales para la gestión de la
calidad.
Establece un punto de referencia amplio pero
riguroso para mejorar la calidad de los
productos y servicios en todos los sectores del
mundo.
La serie de normas ISO 9000 describe los
fundamentos de un Sistema de Gestión de
Calidad (SGC) eficaz a través de sus principios,
directrices y mejores prácticas.

Actividades del análisis de requerimientos
El proceso del establecimiento de requerimientos de un sistema de
software, como ya mencionamos, es el primer paso esencial en
entregar lo que el cliente desea. A pesar de esto, la insuficiencia de
tiempo y esfuerzo son a menudo encontrado en esta actividad y
existen pocos métodos sistemáticos para soportarlo. Entre los
métodos conocidos se puede citar a los siguientes:
Para Pressman, en el proceso de análisis de requerimientos del

software se puede identificar cinco tareas o etapas fundamentales:

Reconocimiento del problema.
Se deben de estudiar inicialmente las especificaciones del sistema y el plan del proyecto
del software. Realmente se necesita llegar a comprender el software dentro del contexto
del sistema. 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.
En esta etapa el analista debe centrarse 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.
Durante la evaluación y síntesis de la solución, se crean modelos
del sistema que servirán al analista 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 intentan 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.
Una vez que se han descrito la información básica, se
especifican los criterios de validación que han de
servir para 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 CORE
El método Controlled Requirements Expression (CORE)
[Norris] es un conjunto de notaciones textuales y
gráficas, con guías especificadas para la captura y
Modelación
validación de requerimientos del sistema, en las Definición del
Problema
combinada de
Análisis de
restricciones
Puntos de Vista
etapas iniciales del diseño del sistema.
CORE ha sido, por tradición, pensado como Estructuración
del Punto de
Modelación
individual de
puramente una técnica de captura y análisis de vista Puntos de Vista
requerimientos (RCA), aunque soporta algunos

Colección Estructuración
aspectos de diseño tales como estructuras de datos. Tabular de datos
CORE está basada en el principio de primero definir el

problema a ser analizado (definición del problema), y
luego dividirlo en unidades o puntos de vista a
considerar.
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.
Flujo de datos Esta etapa es cuando la información
Puntos de Procesami sobre los flujos de datos entre los
Vista ento 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 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.

Procesos de Búsqueda de Requerimientos
Como sabemos, un área de conocimiento de
gran importancia en el desarrollo de
software, es la ingeniería de requerimientos.
Esta comprende las actividades de obtención
(captura, descubrimiento y adquisición),
análisis (y negociación), especificación, y
validación de requisitos.
Además, establece una actividad de gestión
de requerimientos para manejar los cambios,
mantenimiento y rastreabilidad de los
requerimientos.

Técnicas Para la Obtención de
Requerimientos
Existe un gran número de técnicas para

obtener requerimientos.
A continuación describo las más
utilizadas.
Hay que aclarar que ninguna de estas
técnicas es suficiente por sí sola y que es
recomendable combinarlas para
obtener requerimientos completos.

Entrevistas
La entrevista es de gran utilidad para obtener información
cualitativa como opiniones, o descripciones subjetivas de
actividades.
Es una técnica muy utilizada, y requiere una mayor preparación y
experiencia por parte del analista. La entrevista se puede definir
como un “intento sistemático de recoger información de otra
persona” a través de una comunicación interpersonal que se
lleva a cabo por medio de una conversación estructurada.
Debe quedar claro que no basta con hacer preguntas para
obtener toda la información necesaria.
Es muy importante la forma en que se plantea la conversación y
la relación que se establece en la entrevista.
Estos son algunos de los aspectos más importantes a tener en cuenta
al realizar entrevistas:
❖ Preparación. Es necesario documentarse e investigar la situación de la organización
analizando los documentos disponibles, de tal forma que la entrevista se enfoque en
aquellos aspectos que están solamente en la mente del entrevistado y que no son
accesibles por otros medios como la observación o el análisis de documentos.
❖ Entrevistar al personal adecuado. La mayoría de los analistas adoptan un enfoque top-
down, comenzando a entrevistar a directivos para que brinden un panorama general
de hacia donde deberían ir las cosas, y terminando por hablar con los empleados que
aportan detalles importantes de la operación.
❖ Duración. Una entrevista debería durar a lo sumo un par de horas.
❖ Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados puedan
elaborar y dar detalles, más allá de simplemente responder “si” o “no”.
Desarrollo Conjunto de Aplicaciones ( JAD )
Es una técnica que se utiliza para promover la
cooperación y el trabajo en equipo entre
usuarios y analistas. Consiste en realizar
sesiones en las que participan usuarios
expertos del dominio junto a analistas de
software. La idea es aprovechar la dinámica de
grupos aplicando un proceso de trabajo
sistemático y organizado, apoyado por
elementos visuales de comunicación y
comprensión de soluciones.

Las razones que sirven de base a JAD son las siguientes:
❖ Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino

también en redactar un conjunto de requisitos coherente a partir de opiniones
diferentes de los distintos entrevistados.
❖ Es más difícil apreciar posibles errores en la especificación de requisitos, ya que sólo
el analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y
detectar defectos.
❖ El JAD propugna una participación más profunda de los usuarios en el proyecto,
hasta tal punto que los usuarios que participan adquieren un cierto sentido de
propiedad en el sistema que se construye.

Desarrollo de Prototipos
Los prototipos suelen consistir en versiones reducidas,
demos o conjuntos de pantallas (que no son totalmente
operativos) de la aplicación pedida. Esta técnica es
particularmente útil cuando:
❖ El área de la aplicación no está bien definida

(posiblemente por ser algo muy novedoso).
❖ El costo del rechazo de la aplicación por los usuarios es
muy alto.
❖ Es necesario evaluar previamente el impacto del
sistema en los usuarios y en la organización.

Los prototipos de sistema permiten a los usuarios
experimentar para ver cómo éste ayuda a su trabajo.
Fomentan el desarrollo de ideas que desembocan en
requerimientos. Además de permitir a los usuarios mejorar
las especificaciones de requerimientos, el desarrollo de un
prototipo tiene otras ventajas:
1. Al demostrar las funciones del sistema se identifican las

discrepancias entre los desarrolladores y los usuarios.
2. Durante el desarrollo del prototipo, el personal del
desarrollo de software puede darse cuenta de que los
requerimientos son inconsistentes y/o están
incompletos.

3. Aunque limitado, se dispone rápidamente de un sistema
que funciona y demuestra la factibilidad y usabilidad de la
aplicación a administrar.
4. El prototipo se utiliza como base para escribir la
especificación para la producción.
En general, el uso de esta técnica es un medio que permite
solventar objeciones del usuario del tipo: “No sé exactamente
lo que quiero, pero lo sabré cuando lo vea”.
Por lo general, la construcción de prototipos incrementa los
costos en las etapas iniciales de un proyecto, pero esto se
recupera en etapas posteriores gracias al mejor
entendimiento de los requerimientos por parte de los
desarrolladores
Observación
Por medio de esta técnica el analista obtiene
información de primera mano sobre la forma en
que se efectúan las actividades.
Este método permite observar la forma en que se
llevan a cabo los procesos y, por otro, verificar que
realmente se sigan todos los pasos especificados.
Como sabemos, en muchos casos los procesos son
una cosa en papel y otra muy diferente en la
práctica. Los observadores experimentados saben
qué buscar y cómo evaluar la relevancia de lo que
observan.

Estudio de documentación
Varios tipos de documentación, como
manuales y reportes, pueden proporcionar
al analista información valiosa con respecto
a las organizaciones y a sus operaciones.
La documentación difícilmente refleja la
forma en que realmente se desarrollan las
actividades, o donde se encuentra el poder
de la toma de decisiones.
Sin embargo, puede ser de gran
importancia para introducir al analista al
dominio de operación y el vocabulario que
utiliza.
Cuestionarios
El uso de cuestionarios permite a los analistas
reunir información proveniente de un grupo
grande de personas.
El empleo de formatos estandarizados para las
preguntas puede proporcionar datos más
confiables que otras técnicas; por otra parte, su
amplia distribución asegura el anonimato de los
encuestados, situación que puede conducir a
respuestas más honestas.

Tormenta de ideas ( Brainstorming )
Consiste en reuniones con cuatro a diez personas
donde como primer paso sugieren toda clase de
ideas sin juzgar su validez –por muy disparatadas
que parezcan–, y después de recopilar todas las
ideas se realiza un análisis detallado de cada
propuesta.
Esta técnica se puede utilizar para identificar un
primer conjunto de requisitos en aquellos casos
donde no están muy claras las necesidades que hay
que cubrir, o cuando se esta creando un sistema
que habilitará un servicio nuevo para la
organización.

ETHICS ( Implementación Efectiva de Sistemas Informáticos desde
los puntos de vista Humano y Técnico )
Constituye un método bastante evolucionado para
fomentar la participación de los usuarios en los proyectos.
Creado por E. Mumford en 1979, coordina la perspectiva
social de los sistemas con su implementación técnica.
Un sistema no tiene éxito si no se ajusta a los factores
sociales y organizacionales que rigen a la empresa.
Se busca la satisfacción de los empleados en el trabajo a
través de estudios integrales.
Los requisitos técnicos del sistema serán los necesarios
para mejorar la situación de los empleados (y, por lo
tanto, su productividad) en función de dichos análisis.
Puntos de Vista
Cualquier sistema de software no trivial debe
satisfacer las necesidades de un grupo diverso
de interesados (stakeholders). Cada uno de
estos puede tener intereses diferentes en el
sistema de software, y por lo tanto sus
necesidades pueden generar requerimientos
que tengan conflicto entre sí, o incluso se
contradigan.

Las etapas principales de este método son:
1. Identificación de puntos de vista, que implica descubrir los que reciben los servicios
del sistema e identificar los servicios específicos que se suministran a cada punto
de vista.
2. Estructuración de puntos de vista, que comprende agrupar los relacionados en una
jerarquía. Los servicios comunes se ubican en los niveles altos de la jerarquía y se
heredan los puntos de vista de bajo nivel.
3. Documentación de puntos de vista, que comprende refinar la descripción de éstos
y los servicios identificados.
4. Trazado del punto de vista del sistema, que comprende identificar los objetos en un
diseño orientado a objetos utilizando la información del servicio encapsulado en los
puntos de vista.
Escenarios
Estos se utilizan para documentar el comportamiento
del sistema cuando se le presentan eventos específicos.
Cada evento de interacción distinto, o la selección de un
servicio del sistema, se documentan como un escenario
de eventos distinto.
Los escenarios de eventos incluyen una descripción del
flujo de datos y las acciones del sistema, y documenta
las excepciones que puedan surgir.
Las convenciones para los diagramas utilizados en los
escenarios de eventos son:

1. Los datos proporcionados desde un punto de vista o proporcionados a éste se
representan como elipses.
2. Las entradas y salidas de la información de control se ubican en la parte superior de
cada recuadro.
3. Las salidas de datos se ubican a la derecha de cada recuadro. Si no están encerradas,
significa que pertenecen al sistema.
4. Las excepciones se muestran en la parte inferior del recuadro. Si existen varias
excepciones posibles, éstas se encierran en un recuadro.
5. El nombre del siguiente evento esperado después de completar el escenario se
muestra en un recuadro sombreado.

Etnografía
La etnografía es una técnica de observación que se puede utilizar para entender los
requerimientos sociales y organizacionales. Un analista se sumerge por sí solo en el
entorno laboral donde el sistema se utilizará. El trabajo diario se observa y se hacen notas
de las tareas reales en las que los participantes están involucrados.
La etnografía es especialmente efectiva para descubrir dos tipos de requerimientos:
1. Los requerimientos que se derivan de la forma en la que la gente
trabaja realmente más que de la forma en la que las definiciones de
los procesos establecen que debería trabajar.
2. Los requerimientos que se derivan de la cooperación y conocimiento
de las actividades de la gente.

Estrategia para la obtención de requerimientos
1. Aprender todo lo que se pueda de los documentos, formularios, informes y archivos
existentes. Es sorprendente lo que se puede aprender de un sistema sin necesidad de
quitarle tiempo a la gente.
2. De ser posible, se observará el sistema en acción. No se plantearán preguntas. Tan sólo
se observará y se tomarán notas o dibujos. Conviene asegurarse de que las personas
observadas saben que no se les está evaluando. En caso contrario, harán su trabajo de
manera más eficaz que lo normal.
3. Diseñar y distribuir cuestionarios para aclarar cuestiones que no se comprenden bien.
Será también buen momento para solicitar opiniones sobre los problemas y las
limitaciones. Los cuestionarios requieren que los usuarios inviertan una parte de su
tiempo. Pero son ellos los que pueden elegir cuándo les viene mejor hacerlo.
4. Realizar entrevistas (o sesiones de trabajo en grupo, como JAD). Como ya se ha
recogido una base de requerimientos iniciales en los pasos anteriores, se pueden
utilizar las entrevistas para verificar y aclarar las cuestiones y los problemas de
mayor dificultad. En este punto se pueden llegar a aplicar algunas de las otras
técnicas cómo Escenarios, Tormenta de ideas, Puntos de Vista, ETHICS y Desarrollo
de Prototipos.
5. Se verifican los requerimientos a través del uso de técnicas como Entrevistas,
Observación y orientados a Puntos de Vista.

¿Preguntas?

Cualquier duda o consulta escribir al
correo
visita mi página web
repasovirtual.jimdofree.com

Eres dueño de tu propio destino!!!!!
Gracias Totales!!!

Clase 01 Tecnicas de Busqueda de Requerimientos 13 12 23

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Clase 01 Tecnicas de Busqueda de Requerimientos 13 12 23

Cargado por

Copyright:

Formatos disponibles

CARRERA: DESARROLLO DE SISTEMAS DE INFORMACION

Clase 1: Conceptos. Clasificación. Actividades del Análisis de

Lima, 13 de diciembre de 2023

2. Sólo active su micrófono si va a participar,

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

En el ámbito empresarial, los "requerimientos"

Prof. Juan Daniel Daza Hermoza

Stakeholders que requiere que el Claro Completo

realizar, describen las

Prof. Juan Daniel Daza Hermoza

Los stakeholders tienen un papel importante en la

❖ Lo que el cliente quiere, analizar las necesidades.

Prof. Juan Daniel Daza Hermoza

❖ Los requisitos contienen demasiados errores

Prof. Juan Daniel Daza Hermoza

El proceso de recopilar, analizar y verificar las necesidades del

Prof. Juan Daniel Daza Hermoza

La técnica de búsqueda de requerimiento o requisitos es un proceso

❖Entender el problema por el que surge la necesidad del software.

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Fernández Calderón Percy Williams

Ortiz Alanoca Vaner

Prof. Juan Daniel Daza Hermoza

Los requerimientos de usuario pueden incluir aspectos funcionales,

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Estos son algunos ejemplos de requisitos no funcionales:

Seguridad: El sistema debe estar protegido contra el acceso no autorizado.

Actuación: El sistema debe poder manejar el número requerido de usuarios sin

Disponibilidad: El sistema debe estar disponible cuando sea necesario.

Portabilidad: El sistema debe poder ejecutarse en diferentes plataformas con cambios

Usabilidad: El sistema debe ser fácil de usar y comprender.

Compatibilidad: El sistema debe ser compatible con otros sistemas.

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

❖ Los permisos de acceso al sistema podrán ser cambiados solamente por el

❖ El procedimiento de desarrollo de software a usar debe estar definido explícitamente

Prof. Juan Daniel Daza Hermoza

Para Pressman, en el proceso de análisis de requerimientos del

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

requerimientos (RCA), aunque soporta algunos

CORE está basada en el principio de primero definir el

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Existe un gran número de técnicas para

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

❖ Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino

Prof. Juan Daniel Daza Hermoza