anotado lo de hoy

seminario/5.org

@@ -0,0 +1,73 @@
+#+title:     Requerimientos
+#+author:    Fede
+#+email:     federico.nicolas.polidoro@gmail.com
+
+* Teoria
+Requerimientos
+- Definicion.
+- Diagrama.
+- Tipos.
+- Proceso.
+- Tecnicas.
+- Documentos.
+- Para que existe?
+- Relacion con negocios.
+
+*Criterio de aceptacion*: Definido como el grupo de reglas utilizadas para evaluar la validez de una entrega.
+
+* Definición
+#+begin_quote
+Una accion necesaria en el sistema ~ alumno random
+#+end_quote
+
+Son las funcionalidades y un sistema esta comprendido por los problemas que resuelve. Se busca que el sistema este bien hecho para que sea mantenible en el tiempo, y que sea util, osea, que cumpla la funcionalidad de forma correcta.
+
+Componentes del software:
+- Funcionalidad.
+- Problema/Objetivo.
+- Conocimiento.
+- Dominio.
+
+Es importante tener en cuenta que corregir un requerimiento en una etapa temprana antes del desarrollo es considerablemente menos costoso. Se estima que un gasto de 1 usd en etapa de ingenieria de requerimientos equivale a 1000 usd en desarrollo, adicionalmente el 70% de los proyectos con problemas en los requerimientos terminan en fracasos.
+
+* Diagramas
+[[./5.1.png]]
+
+* Tipos
+** Funcionales
+funcionalidades necesarias para que el negocio opere.
+** No-Funcionales
+- Entorno / Contextuales
+- Dominio
+- Negocio
+- Usuario
+- Documentacion
+- Sistema
+
+* Documento
+*Dos documentos*: El profesor recomienda que en un trabajo hagamos dos documentos uno que entienda el cliente y otro que sea más facilmente entendido por el equipo de desarrollo.
+* Proceso
+Cualquier cosa seria en cualquier diciplina necesita tener una secuencia de operaciones ordenadas.
+#+begin_quote
+Literalmente la definicion de proceso ~ profe
+#+end_quote
+
+* Tecnicas
+para tomar requerimientos es necesario tener en cuenta las distintas cosas:
+- Entevistas (Preguntas abiertas / cerradas).
+- Dialogo.
+- Encuentas.
+- Mirar a como el usuario realiza su trabajo para encontrar puntos de mejora??? (1984).
+- Hacer una lista de stackeholders.
+- Brainstorming.
+- Prototipado (ponele).
+- Historia de usuario (_Como <Usuario> quiero <Objetivo> para <Resultado>_).
+- Casos de uso.
+  - Camino Principal.
+  - Camino Alterno.
+  - Post-Condicion.
+  - Pre-Condicion.
+  - Criterio de Aceptacion.
+
+* Conclusion
+Es necesario ademas de los casos de uso tener los requerimientos formateados con una plantilla que no se que es