Este documento describe los requerimientos funcionales y no funcionales para un sistema de análisis foliar del cacao. Incluye 10 requerimientos funcionales como determinar el tiempo de muestreo, generar recomendaciones, introducir datos y graficar resultados. También incluye 11 requerimientos no funcionales como usabilidad, fiabilidad, multipataforma y privacidad de datos. Además, identifica 10 casos de uso como iniciar sesión, cerrar sesión, gestionar cliente y muestreo. El objetivo general es desarroll
2. Casos de uso y diagramas de casos de usoSaul Mamani
Tutorial detallado de los casos de uso y los diagramas de casos de suso en UML 2.
Si tienes problemas para ver la presentación, lo puedes descargar de aquí...
https://drive.google.com/folderview?id=1-1ypq1SSRLCjL2USp0iAIaBMcSNoEzub
www.modelado.pnfi.org
Los Casos de Uso (Ivar Jacobson) describen, bajo la forma de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del usuario.
Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno.
Los Casos de Uso son descripciones de la funcionalidad del negocio/sistema independientes de la implementación.
Detalla los conceptos de elicitación de requisito y detalla las principales técnicas de elicitación como la entrevista, encuestas, brainstorm, jad, focus group, análisis de documentos, análisis de sistemas existentes, observación, prototipo
Trabajo de Taller de Ing de Software. Con el Profesor Antaurco donde tratamos de desarrollar el sistema de Gestion de Notas ... El cual no creo que concluimso bien. Pero en verdad Anita, Mili, Fredy fueron muy buenos amigos disculpen mi comportamiento chicos... Pasu que estres fue hacer eso no :) valio la PENA !!!
Diccionario de datos en los sistemas de informaciónYaskelly Yedra
Un diccionario de datos es un catálogo, un depósito, de los elementos de un sistema. Es un listado organizado de todos los datos pertinentes al sistema con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento en común de todas las entradas, salidas, componentes y cálculos.
2. Casos de uso y diagramas de casos de usoSaul Mamani
Tutorial detallado de los casos de uso y los diagramas de casos de suso en UML 2.
Si tienes problemas para ver la presentación, lo puedes descargar de aquí...
https://drive.google.com/folderview?id=1-1ypq1SSRLCjL2USp0iAIaBMcSNoEzub
www.modelado.pnfi.org
Los Casos de Uso (Ivar Jacobson) describen, bajo la forma de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del usuario.
Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno.
Los Casos de Uso son descripciones de la funcionalidad del negocio/sistema independientes de la implementación.
Detalla los conceptos de elicitación de requisito y detalla las principales técnicas de elicitación como la entrevista, encuestas, brainstorm, jad, focus group, análisis de documentos, análisis de sistemas existentes, observación, prototipo
Trabajo de Taller de Ing de Software. Con el Profesor Antaurco donde tratamos de desarrollar el sistema de Gestion de Notas ... El cual no creo que concluimso bien. Pero en verdad Anita, Mili, Fredy fueron muy buenos amigos disculpen mi comportamiento chicos... Pasu que estres fue hacer eso no :) valio la PENA !!!
Diccionario de datos en los sistemas de informaciónYaskelly Yedra
Un diccionario de datos es un catálogo, un depósito, de los elementos de un sistema. Es un listado organizado de todos los datos pertinentes al sistema con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento en común de todas las entradas, salidas, componentes y cálculos.
Mi Trabajo Desarrollado Para el Curso de Analisis y Desing (no tengo la enie) del ciclo del 2006-II Con mi Amiga Ana Maria Cerdan :D, Mi compa Cuncho y Agapito... (Espero que te vaya bien en SUNAT compa)...
Esa Anita cuanto me soporto ... Pobrechita... Ojala te vaya bien compa...
Especificaciones Suplementarias del Sistema de Control de Producción para la empresa "ADA COMPANY" (caso ficticio), como parte de la materia Ingeniería de Software de la Universidad Politécnica de Victoria
3Redu: Responsabilidad, Resiliencia y Respetocdraco
¡Hola! Somos 3Redu, conformados por Juan Camilo y Cristian. Entendemos las dificultades que enfrentan muchos estudiantes al tratar de comprender conceptos matemáticos. Nuestro objetivo es brindar una solución inclusiva y accesible para todos.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0...Telefónica
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0xWord escrito por Ibón Reinoso ( https://mypublicinbox.com/IBhone ) con Prólogo de Chema Alonso ( https://mypublicinbox.com/ChemaAlonso ). Puedes comprarlo aquí: https://0xword.com/es/libros/233-big-data-tecnologias-para-arquitecturas-data-centric.html
1. Se requiere que como ingeniero de requerimientos se identifique:
a) Los requerimientos funcionales y no funcionales del proyecto asignado
MODULO 2 “Análisis Foliar del cacao”
Requerimientos Funcionales
Número Requerimiento Descripción Prioridad
RF1 Determinar tiempo de Determinar época mas representativa para 3
muestreo el análisis foliar del cultivo.
RF2 Generar
recomendaciones
Generar recomendaciones de acuerdo a las
muestras sobre los nutrientes que son
antagónicos y determinar la carencia de
algunos nutrientes en la planta de cacao.
Permitir registrar los valores de cada nutriente
detectado en la plata de cacao.
5
5RF3
RF4
RF5
Introducción de datos
Seguimiento de cultivo
Graficar resultados.
Hacer un seguimiento de las diferentes etapas 3
de crecimiento de los cultivos de cacao.
Mostrar
macronutrientes
gráficas estadísticas
en porcentajes
de lo
y
5
micronutrientes en microgramos de las
muestras procesadas al análisis.
RF6
RF7
Seguimiento de la planta Hacer un seguimiento del crecimiento de las
plantas de cacao.
Pre-Análisis foliar del Permitir incluir un pre-análisis ya ejecutado en
3
3
cacao cultivos de cacao con cosechas exitosas y
comparar con el cultivo analizado.
RF8
RF9
Determinar estado de las Determinar el estado correcto que debe tener 3
3
hojas una hoja para ser parte de la muestra.
Determinar Determinar el tipo de disposición de pendiendo
procedimiento para toma del tamaño del cultivo o parcela.
de las muestras.
RF10 Validar el muestreó Analizar la muestra y determinar la 5
importancia que tiene para generar los reportes
de cambio para establecer cuáles son los
mejores resultados para el cultivo.
TALLER GRUPAL de la semana
Alejandra Barragán 1150792
Jhorman Botello 1151454
Javier Calderón 1151229
2. Requerimientos no Funcionales
Numero Requerimiento Descripción Prioridad
RNF1 USABILIDAD El sistema debe ser fácil de usar para el usuario.
El sistema deberá recuperar los datos ya
insertados frente a fallos de conexión.
El sistemas al terminarlo deberá quedar funcional
5
RNF2 FIABILIDAD 4
RNF3
RNF4
RNF5
RNF6
FUNCIONALIDAD
MULTIPLATAFORMA
COMPRENSIVO
PROTEGIDO
con todos los requerimientos que se le
asignaron. 4
El sistema deberá adaptarse a cualquier sistema
operativo y servidor.
El sistema debe ser usable en cualquier parte de
la región.
El sistema debe tener usuario y contraseña para
evitar robo de datos.
3
3
5
La plataforma desarrollada tengo un ciclo de vida
moderado, para mayor uso y favorabilidad de los 1
usuarios.
El sistema deberá tener un tiempo prudente para
la búsqueda de datos, haciendo más eficaz el 5
software.
RNF7 DURABILIDAD
EFICIENCIARNF8
RNF9
PRIVACIDAD
DATOS
DE El sistema no revelara datos de los usuarios
registrados.
5
RNF10 APARIENCIA
RNF11 ROBUZTO
La apariencia visual del programa
debe ser 2amigable, responsiva y llamativa para el usuario
El sistema deberá fijar comportamientos frente a
situaciones no previstas en la fase de análisis, 3
pero evidentes en la fase de desarrollo
Matriz de especificación de requisitos
MATRIZ DE RELACION DE DOCUMENTOS
REQUISITOS
Cas Casos Peticio
Negocio Usuario Sistema os de Dependen nes de
de prue
uso bas
cias Cambi
o
No
funcion
ales
No
funcion
ales
No
funcion
ales
Funcion
ales
Funcion
ales
Funcion
ales
RF1 RNF1
RF2
RF5
RNF2
RNF3
RNF4
RF3
RF4
RNF5
RF6 RNF6
RF7
RF8
RNF7
RNF8
RNF9RF9
RF10 RNF10
3. b) Identificar los casos de uso y su especificación
Código
CDU-1
CDU-2
Caso de Uso
INICIAR SESIÓN
CERRAR SESIÓN
Actores participantes
Administrador
Administrador
CDU-3 GESTIONAR CLIENTE Coordinador, Director de Programa
CDU-4 MUESTREO Administrador, Cacaocultor
Administrador, ClienteCDU-5 GENERAR REPORTES
4. 1. Especificaciones de Casos de Uso
Caso de Uso-CDU-1
INICIAR SESIÓNNombre:
Descripción: El usuario solicita ingresar al sistema mediante su
cuenta de acceso.
Requerimiento:
Precondición:
RF2
Datos de la cuenta de acceso (código y
contraseña).
Flujo Normal:
5. En el flujo de casos de uso se describe lo que hace el actor y lo que hace el sistema en respuesta.
Se expresa en forma de un diálogo entre actor y sistema. El flujo básico del caso de uso describe
lo que sucede dentro del sistema. Este flujo puede ser representado en forma gráfica. Hay que
tomar en cuenta que el flujo de un caso de uso, debería tener entre cinco y siete pasos
aproximadamente.
Actor Sistema
1. El usuario accede al sistema mediante la
URL principal
3.El sistema valida los datos respectivos y le da la
bienvenida al usuario.
2. El usuario ingresa al sistema
proporcionando los datos de su cuenta de
acceso.
Flujo Alterno:
El flujo alterno se refleja el comportamiento alternativo debido a las irregularidades que ocurren en
el flujo de eventos normal. Pueden ser tan largos como sea necesario para describir los eventos
asociados al comportamiento alternativo.
Actor Sistema
3.1 El usuario no recuerda su contraseña y
solicita que se le envié a su correo
electrónico.
4.1 El sistema solicita mediante un formulario el
correo electrónico del usuario y envía la
respectiva contraseña.
Flujo Alterno 2:
El flujo alterno se refleja el comportamiento alternativo debido a las irregularidades que ocurren en
el flujo de eventos normal. Pueden ser tan largos como sea necesario para describir los eventos
asociados al comportamiento alternativo.
Actor Sistema
3.2 El usuario no posee cuenta de acceso por 4.2 El sistema solicita mediante un formulario los
lo que solicita crear una cuenta.
3.2.1 El usuario ingresa los datos.
datos necesarios para crear una cuenta de
acceso.
4.2.1 El sistema crea la cuenta de acceso.
Pos condición: El usuario accede al sistema y puede utilizar los
diferentes servicios que presta el mismo.
Requerimientos Especiales:
Puntos de Extensión:
RF1
--
Caso de Uso-CDU-2
Nombre: CERRAR SESIÓN
Descripción: El usuario solicita terminar su sesión, finalizando así el
uso de los servicios del sistema.
Requerimiento:
Precondición:
Flujo Normal:
RF3
El usuario debe haberse logueado en el sistema.
6. En el flujo de casos de uso se describe lo que hace el actor y lo que hace el sistema en respuesta.
Se expresa en forma de un diálogo entre actor y sistema. El flujo básico del caso de uso describe
lo que sucede dentro del sistema. Este flujo puede ser representado en forma gráfica. Hay que
tomar en cuenta que el flujo de un caso de uso, debería tener entre cinco y siete pasos
aproximadamente.
Actor Sistema
2. El usuario pulsa el enlace
proporcionado por el sistema.
1.El sistema ofrece un enlace para la desconexión o
cierre de sesión.
3. El sistema limpia la información de la sesión del
usuario.
4. El sistema ubica al usuario en la plataforma de
inicio del sistema.
Flujo Alterno:
El flujo alterno se refleja el comportamiento alternativo debido a las irregularidades que ocurren en
el flujo de eventos normal. Pueden ser tan largos como sea necesario para describir los eventos
asociados al comportamiento alternativo.
Actor Sistema
-- --
Pos condición: El sistema vuelve a la plataforma de inicio.
Requerimientos Especiales:
Puntos de Extensión:
RF1
--
Caso de Uso-CDU-3
Nombre: GESTIONAR CLIENTE
Descripción: El administrador puede crear, actualizar o eliminar un
cliente.
Requerimiento:
Precondición:
RF15, RF16, RF17, RF18
-Para crear un cliente se deben tener todos los datos de
este
-Para actualizar un cliente se debe tener el ID de este y
los datos a modificar
-Para eliminar un cliente se debe tener el ID de este
-Para consultar los datos de un cliente se debe tener el
ID de este
Flujo Normal:
En el flujo de casos de uso se describe lo que hace el actor y lo que hace el sistema en respuesta.
Se expresa en forma de un diálogo entre actor y sistema. El flujo básico del caso de uso describe
lo que sucede dentro del sistema. Este flujo puede ser representado en forma gráfica. Hay que
tomar en cuenta que el flujo de un caso de uso, debería tener entre cinco y siete pasos
aproximadamente.
Actor Sistema
7. 1. Registrar al cliente que quiere
efectuar un muestreo
2. Actualizar los datos del cliente
3. Eliminar los datos del cliente
4. Consultar los datos del cliente
1. Proporciona una vista de registro en el cual se
ingresarán los datos pertinentes de este
2. En la misma vista se tendrá un botón para
eliminar o actualizar un cliente
3. Se tendrá un buscador para consultar de
manera eficiente los datos de un cliente
Flujo Alterno:
El flujo alterno se refleja el comportamiento alternativo debido a las irregularidades que ocurren en
el flujo de eventos normal. Pueden ser tan largos como sea necesario para describir los eventos
asociados al comportamiento alternativo.
Actor Sistema
1. El cliente ya se encuentra
registrado
1. El sistema encuentra coincidencia con un registro
existente en la base de datos
2. El sistema informa al usuario sobre un error en
el proceso de registro
Pos condición: El sistema muestra el formulario para un nuevo registro
Requerimientos Especiales:
Puntos de Extensión:
Caso de Uso-CDU-4
Nombre: MUESTREO
Descripción: El Administrador definirá el tamaño de cultivo y la cantidad de
árboles a muestrear, a su vez determinará el tiempo de
muestreo.
El cacaocultor llenará un formato de registro de muestras y se
las enviará al Administrador para que este las valide y las
monte al sistema
El cacocultor deberá hacerle seguimiento al los cultivos a
muestrear.
Requerimiento:
Precondición:
RF5, RF6, RF7, RF8, RF13, RF14
Para la selección del tamaño se dará a escoger entre
los diferentes tamaños que se tienen en el terreno
Para la cantidad de árboles a mostrar se escogen de
acuerdo al tamaño de cultivo
Para determinar el tiempo de muestreo se requiere que
el cliente lo proporcione
Para el seguimiento el cacaocultor tendrá un formulario
de actualización del cultivo a muestrear
Flujo Normal:
8. En el flujo de casos de uso se describe lo que hace el actor y lo que hace el sistema en respuesta.
Se expresa en forma de un diálogo entre actor y sistema. El flujo básico del caso de uso describe
lo que sucede dentro del sistema. Este flujo puede ser representado en forma gráfica. Hay que
tomar en cuenta que el flujo de un caso de uso, debería tener entre cinco y siete pasos
aproximadamente.
Actor Sistema
1. Seleccionar el tamaño
del cultivo
2. Selecciona la cantidad de
árboles a muestrear
3. Proporciona tiempo de
muestreo
1. El sistema muestra un formulario donde se podrá
escoger el tamaño del cultivo dependiendo del
nombre del cultivo
2. Dependiendo del tamaño del cultivo el sistema
mostrar la cantidad recomendada de árboles a
seleccionar
4. Hace seguimiento al
cultivo
3. Se mostrará un formulario pidiendo el tiempo de
muestreo
5. Envía la muestra
registrada
6. Valida la muestra
7. Registra la muestra
validada.
4. Se mostrar un formulario donde el cacaocultor llevará
el seguimiento del cultivo a muestrear
5. Se mostrará un formulario donde se diligenciara la
muestra tomada
6. Habrá un boton donde el Administrador podrá validar
la muestra y subirla a sistema
Flujo Alterno:
El flujo alterno se refleja el comportamiento alternativo debido a las irregularidades que ocurren en
el flujo de eventos normal. Pueden ser tan largos como sea necesario para describir los eventos
asociados al comportamiento alternativo.
Actor
Pos condición:
Sistema
El sistema muestra el formulario para un nuevo registro.
Requerimientos Especiales:
Puntos de Extensión:
Caso de Uso-CDU-5
Nombre: GENERAR REPORTES
Descripción: El administrador genera reportes generales de todos los
muestreos, específicamente de un muestreo
recomendaciones a hacerle al cultivo.
o de
Requerimiento:
Precondición:
RF9, RF10, RF11
El usuario debe iniciar sesión previamente.
Si va se va a realizar una gráfica de muestreo
específico o de recomendación se necesita el ID del
muestreo
Flujo Normal:
En el flujo de casos de uso se describe lo que hace el actor y lo que hace el sistema en respuesta.
Se expresa en forma de un diálogo entre actor y sistema. El flujo básico del caso de uso describe
9. lo que sucede dentro del sistema. Este flujo puede ser representado en forma gráfica. Hay que
tomar en cuenta que el flujo de un caso de uso, debería tener entre cinco y siete pasos
aproximadamente.
Actor Sistema
1. Generar reporte general
2. Generar grafica muestreo
específico
3. Generar recomendaciones
a un muestreo
1. Proporciona una vista donde permitira escoger que
reporte se quiere generar
2. Se ingresa el ID del muestreo y se realiza ya sea la
grafica o las recomendaciones al muestreo.
Flujo Alterno:
El flujo alterno se refleja el comportamiento alternativo debido a las irregularidades que ocurren en
el flujo de eventos normal. Pueden ser tan largos como sea necesario para describir los eventos
asociados al comportamiento alternativo.
Actor Sistema
1. No exista muestro 1. Informa al usuario que no es posible realizar el
reporte.
Pos condición:
Requerimientos Especiales:
Puntos de Extensión:
c) Identificar las primeras interfaces graficas
Inicio