3. OBTENER INFORMACIÓN DEL
CLIENTE
Técnicas generales para la identificación de requerimientos
Entrevista: Estas técnicas son muy utilizadas para la recolección de
opiniones, criterios o descripciones sobre diferentes actividades.
Lluvia de ideas: Esta técnica es abierta y se utiliza para explorar
necesidades iniciales con la ayuda de la identificación de ideas de
todas las personas que hacen parte del equipo de apoyo para la
identificación de los requerimientos.
Cuestionario: Esta técnica puede ir dirigida a un público específico o
general, lo que permite obtener una información mayor, ya que se
tiene la posibilidad de involucrar más personas para el desarrollo de
los cuestionarios y que estos tengan diferentes puntos de vista.
4. OBTENER INFORMACIÓN DEL
CLIENTE
Observación
Esta permite obtener información directa sobre la forma en que se
realizan las actividades. Es una técnica que sirve para revisar que no
existen omisiones o interpretaciones erróneas sobre el proceso que
se realiza. Hay que tener en cuenta que se debe utilizar si el cliente
lo permite y si el proyecto así lo amerita.
5. DEFINICIÓN DEL ALCANCE
La definición del alcance tiene como propósito describir y delimitar
claramente las necesidades del cliente, las cuales pretenden ser
cumplidas con el proyecto.
6. RECOMENDACIONES PARA DEFINIR
EL ALCANCE
Conocer los objetivos de la empresa o dependencia
Desarrollar un escrito o documento formal.
Detallar claramente qué actividades y procesos son parte del
proyecto
Definir los criterios que se utilizarán para determinar si el proyecto
o fase ha finalizado exitosamente, es decir, los criterios de
aceptación.
Al definir el alcance, tener en mente que lo que no esté en el alcance
está fuera del proyecto.
7. REQUERIMIENTOS FUNCIONALES Y
NO FUNCIONALES
Requerimientos
Un requerimiento es una característica que el sistema DEBE tener o es
una restricción que el sistema DEBE satisfacer para ser aceptada por
el cliente.
Requerimientos funcionales
Describen la interacción entre el sistema y su ambiente
independientemente de su implementación.
El ambiente incluye al usuario y cualquier otro sistema externo que
interactúa con el sistema.
8. REQUERIMIENTOS FUNCIONALES Y
NO FUNCIONALES
Requerimientos no funcionales
Son aquellos requerimientos que no se refieren directamente a las
funciones específicas que entrega el sistema,
Algunos ejemplos de requisitos no funcionales típicos son los
siguientes:
rendimiento
disponibilidad
seguridad
accesibilidad
usabilidad
estabilidad
portabilidad
costo
operatividad
interoperabilidad
9. ASPECTOS A TENER EN CUENTA EN LA
IDENTIFICACIÓN DE REQUERIMIENTOS
FUNCIONALES Y NO FUNCIONALES
Requerimientos básicos:
¿Cuál es el proceso básico de la empresa?
¿Qué datos utiliza o produce este proceso?
¿Cuáles son los límites impuestos por el tiempo y la carga detrabajo?
¿Qué controles de desempeño utiliza?
Se debe identificar muy claramente los siguientes elementos:
Procesos
Flujos de datos entre procesos
Datos de cada flujo de datos
Bases de datos
Datos de las bases de datos
10. REQUERIMIENTOS FUNCIONALES Y
NO FUNCIONALES
Preguntas generales ejemplo:
¿Cuántos empleados laboran para la organización en el área(s) que se
pretende desarrollar el sistema; o sea, cuántos tienen relación directa con el
proyecto
¿Cuáles son las personas claves en el sistema? ¿Por qué son importantes?
¿Existen obstáculos o influencias de tipo político que afectan la eficiencia
del sistema?
¿Existen manuales de procedimientos, políticas o lineamientos de
desempeño documentados oficial o no oficialmente?. Si los hay, ¿Se cumplen
en forma cabal en el 100% de las ocasiones?, es decir, ¿se respetan dichos
procedimientos?
¿Existen métodos para evadir el sistema?, ¿Por qué se presentan?
12. ENTREGABLE DE IDENTIFICACIÓN
DE NECESIDADES
Realizar un informe que me permita dar a conocer cuales son los
requerimientos que se van a realizar en el proyecto, este se logra
aplicando toda la información recolectada en los procesos
anteriormente hablados, para así llegar a realizar los diferentes
diagramas UML del sistema de información.
Cuando no Utilizar Diagramas
No dibujar diagramas porque el proceso te lo dice
Porque te sientes culpable de no hacerlo o porque piensas que es
buen diseño hacerlo. Los buenos diseñadores escriben código y
dibujan diagramas solamente cuando es necesario.
Dibujar diagramas para que otra persona codifique
13. ENTREGABLE DE IDENTIFICACIÓN
DE NECESIDADES
Cuando Utilizar los Diagramas
Utilizar los diagramas cuando varias personas necesiten entender la
estructura de una parte particular del diseño, porque todos ellos lo estarán
trabajando simultáneamente. Deténgase cuando todos ellos estén de
acuerdo que lo han entendido
Cuando dos o mas personas estén en desacuerdo con un elemento particular
que debería ser diseñado, y quieres un consenso del equipo. Detente cuando
la decisión haya sido tomada
Cuando quieras jugar con una idea de diseño, y los diagramas pueden
ayudarte a entenderlo. Detente cuando hayas conseguido finalizar el punto
que querías codificar
Cuando necesites exponer una estructura de alguna parte del código a
alguien más o a ti mismo.
14. ENTREGABLE DE IDENTIFICACIÓN
DE NECESIDADES
Los diagramas que se utilizan son los siguientes:
De estados:
Estos diagramas nos muestra los diferentes estados de un objeto durante su
vida util.
De secuencia:
Estos nos muestran el intercambio de mensajes (es decir la forma en que se
invocan) en un momento dado. Los diagramas de secuencia ponen especial
énfasis en el orden y el momento en que se envían los mensajes a los
objetos.
De caso de uso:
Los diagramas de casos de uso describen las relaciones y las dependencias
entre un grupo de casos de uso y los actores participantes en el proceso. Los
diagramas de casos de uso describen qué es lo que debe hacer el sistema,
pero no cómo.
15. ACTIVIDAD PARA LA RECOLECCIÓN
DE INFORMACIÓN E INFORME DE
REQUERIMIENTOS
IDENTIFICAR FUENTES DE INFORMACIÓN.
DISEÑAR Y APLICAR INSTRUMENTOS PARA RECOLECTAR
INFORMACIÓN.
ELABORAR INFORMES CON SU RESPECTIVA TABULACION
ELABORAR EL INFORME DE REQUERIMIENTOS.
