Академический Документы
Профессиональный Документы
Культура Документы
Cada uno de los modelos del proceso de desarrollo del software propuestos, incluye actividades que apuntan a la captura de requerimientos.
Anlisis de Requerimientos
Por lo tanto, la comprensin del propsito y la funcin del sistema comienza con un atento examen de los requerimientos.
Definicin de Requerimiento
Cuando el Cliente solicita que se desarrolle un sistema tiene algunas nociones de lo que debe hacer. Por est razn cada sistema basado en software tiene un propsito, usualmente expresado con algo que el sistema debe hacer. Un Requerimiento es una caracterstica del sistema o una descripcin de algo que el sistema es capaz de hacer con el objeto de satisfacer el propsito del sistema.
Definicin de Requerimiento
Es decir, los requerimientos son lo que clientes/usuarios esperan que haga el sistema. los
Los analistas, por lo tanto, deben entender el problema de los usuarios en SU cultura y con SU lenguaje y construir el sistema que resuelve sus necesidades. En si el objetivo del anlisis de requerimientos es resolver el problema.
Etapa en la que se encuentra el error Anlisis y Esp. Requerimientos Diseo Codificacin Prueba Unitaria Produccin
Documentos de Requerimientos
Existen dos documentos que emanan del anlisis de requerimientos: Definicin de requerimientos Es un documento que debe escribirse en trminos que el cliente pueda entender. Es decir, este documento es un listado completo de todas las cosas que el cliente espera que haga el sistema propuesto. Este documento es escrito en forma conjunta por el cliente y el desarrollador.
Documentos de Requerimientos
Especificacin de requerimientos Documento que reitera la definicin de los requerimientos en los trminos tcnicos apropiados para el desarrollador del diseo de un sistema. Es la contrapartida tcnica al documento de definicin de requerimientos y es escrito por los analistas de requerimientos. A veces un nico documento puede servir para ambos propsitos, lo que lleva a un entendimiento comn entre clientes, analistas de requerimientos y diseadores. Pero a menudo se necesitan ambos documentos.
Documentos de Requerimientos
Es muy importante, que al usar ambos documentos exista un correspondencia directa entre cada requerimiento del documento de definicin y aquellos documentos en la especificacin. Esto para que la visin del cliente este unida a la de los desarrolladores (esto se logra gracias a la gestin de configuracin).
Clasificacin de Requerimientos
Segn el Tipo los requerimientos se clasifican en: Requerimientos funcionales. Requerimientos no funcionales. Requerimientos del Dominio. Segn a quien van dirigidos se clasifican en: Requerimientos del Usuario. Requerimientos del Sistema.
Clasificacin de Requerimientos
Requerimientos funcionales Describen la funcionalidad o los servicios que se espera que el sistema proveer. Dependen del tipo de software, del sistema que se desarrollo y de los posibles usuarios. Cuando se expresan como Requerimientos usuarios, se definen de forma general. del
Clasificacin de Requerimientos
Requerimientos no funcionales
Son los requerimientos que no se refieren directamente a las funciones especficas que entrega el sistema, sino a las propiedades emergentes de ste, como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. Muchos requerimientos no funcionales se refieren al sistema como un todo ms que a rasgos particulares del mismo. A menudo son mas crticos que los funcionales. Mientras que un incumplimiento de un requerimiento funcional degrada el sistema, el de un requerimiento no funcional del sistema lo inutiliza.
Cuando se expresan como requerimiento del sistema describen con detalle la funcin de ste, sus entradas y salidas, excepciones, etc.
Clasificacin de Requerimientos
Requerimientos no funcionales
Los requerimientos no funcionales se clasifican segn su implicancia: Del producto: especifican comportamiento del producto. Ej.: de desempeo en la rapidez de ejecucin del sistema, cuanta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para el sistema sea aceptable, los de portabilidad y de usabilidad. Organizacionales: se derivan de las polticas y procedimientos existentes en la organizacin del cliente y del desarrollador. Ej.: estndares en los procesos que deben utilizarse, requerimientos de implementacin como los lenguajes de programacin o el mtodo de diseo a utilizar.
Clasificacin de Requerimientos
Requerimientos no funcionales
Externos: cubre todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Ej.: requerimientos de interoperabilidad, requerimientos legales, requerimientos ticos.
Un problema comn con los requerimientos no funcionales es que algunas veces son difciles de verificar.
De forma ideal los requerimientos no funcionales se deben expresar de manera cuantitativa utilizando mtricas que se puedan probar de forma objetiva. En la prctica, es difcil. El costo es muy alto.
Clasificacin de Requerimientos
Requerimientos del dominio Se derivan del dominio del sistema ms que de las necesidades especificas del usuario. Son importantes debido a que a menudo reflejan los fundamentos del dominio de la aplicacin. Si estos no se satisfacen es imposible que el sistema trabaje de forma satisfactoria. Estos se expresan utilizando un lenguaje especifico del dominio de la aplicacin que a menudo es difcil de comprender. Ej.: operacin para calcular desaceleracin del tren, para un sistema de control de trenes.
Los requerimientos indican al equipo de pruebas que demostraciones llevar a cabo para convencer al cliente de que el sistema que se le entrega es de hecho lo que haba ordenado.
Fuentes de Requerimientos
Modelo del Dominio Deseos y necesidad De los interesados
Requerimientos
Organizacin y sistemas actuales Requerimientos Reutilizables
Plantilla de Requerimientos
La Ingeniera de Requerimientos (IR) es un proceso que comprende todas las actividades requeridas para crear y mantener un documento de requerimientos del sistema.
Estudio de factibilidad
Especificacin de Requerimientos
Validacin de Requerimientos
Artefactos
Informe de factibilidad Documento de Requerimientos Modelo del Sistema Especificacin de Requerimientos
Estudio de factibilidad
Especificacin de Requerimientos
Validacin de Requerimientos
Artefactos
Informe de factibilidad Documento de Requerimientos Modelo del Sistema Especificacin de Requerimientos
El resultado del estudio es un informe que recomienda si es conveniente llevar a cabo la ingeniera de requerimientos y el proceso de desarrollo del sistema. Adems permite proponer cambios al alcance, presupuesto, calendarizacin, etc. Este es un estudio corto para resolver si es posible y conveniente construir el sistema con la tecnologa existente, las restricciones de costo y tiempo, etc.
Estudio de factibilidad
Especificacin de Requerimientos
Validacin de Requerimientos
No saben lo que quieren del sistema , slo en trminos generales, no conocen el costo de sus peticiones. Los requerimientos estn en sus trminos y conocimientos implcitos de su propio trabajo. con
Artefactos
Informe de factibilidad Documento de Requerimientos Modelo del Sistema Especificacin de Requerimientos
Distintos usuarios tienen distintos requerimientos, se deben encontrar todas las fuentes. Influyen factores polticos. La importancia de los requerimientos varia en el tiempo. Aparecen nuevos requerimientos.
Recoleccin de Requerimientos
Clasificacin
2.
Verificacin de Requerimientos Priorizacin Resolucin de Conflictos
3.
Descubrir
la
importancia
de
cada
Estudio de factibilidad
Especificacin de Requerimientos
Validacin de Requerimientos
Artefactos
Informe de factibilidad Documento de Requerimientos Modelo del Sistema Especificacin de Requerimientos
6.Verificacin de Requerimientos: Los requerimientos se verifican para descubrir si estn completos, son consistentes y acorde con lo que realmente quieren los stakeholders. No existe un enfoque perfecto ni universal aplicable a la obtencin y anlisis de requerimientos .
Descripciones Dinmicas
Especifican estados y las transiciones entre estados en el tiempo.
Estudio de factibilidad
Especificacin de Requerimientos
Validacin de Requerimientos
Se trabaja con un bosquejo completo del documento a diferencia de la verificacin del Anlisis. Se realizan las siguientes verificaciones en el documento de requerimientos:
Artefactos
Informe de factibilidad Documento de Requerimientos Modelo del Sistema Especificacin de Requerimientos
Validez: compromiso con el usuario, que valide que es lo que quiere. Consistencia: que no haya contradicciones. Realismo: que se puedan implementar (incluye: tecnologa, presupuesto y calendario). Verificabilidad: Disear conjunto de pruebas para demostrar que el sistema cumple esos requerimientos.
Propiedad
Rapidez Tamao Fiabilidad Robustez Portabilidad Facilidad de uso Transacciones por seg. KB.
Medida
Tiempo promedio entre fallas. Probabilidad de datos corruptos despus de la falla. Nmero de sistemas. Tiempo de capacitacin.
Estudio de factibilidad
Especificacin de Requerimientos
Validacin de Requerimientos
Artefactos
Informe de factibilidad Documento de Requerimientos Modelo del Sistema Especificacin de Requerimientos
10
Estados
1 2 F F X 3 V V V X X X 4 V V F 5 V F -
Condiciones Acciones
V = Condicin
F V X
Analizar antecedentes
ENTRADA
0 1 0 1 0 1 0
PROXIMO ESTADO
S2 S1 S2 S1 S1 S3
S1
S2
F(Si,Cj) = Sk
S3
11
Descripcin dinmica. Las tcnicas descritas hasta ahora son sumamente tiles para sistemas cuyos estados y eventos son secuenciales. Est tcnica sincronizacin. permite describir : concurrencia y
Acciones
Ninguna plaza disponible Poner en lista de espera
Solicitada
Confirmada
El cliente cancela Incrementar cuenta de plazas El cliente ocupa ninguna
En Lista de Espera
El cliente desiste Retirar de la lista
Ocupada
Cancelada
La representacin con una red de petri es una alternativa que se ajusta bien para expresar los requerimientos del procesamiento paralelo.
El estado inicial de una red de Petri se le llama marca, esta dado por los Tokens (marcas) iniciales. Significado: Transiciones: Modelan eventos o acciones. Lugares con marca: Cumplimiento de una condicin. Transicin activada: Ocurrencia del evento o ejecucin de la accin.
Arcos slo pueden unir Estados con Transiciones y Transiciones con Estados
Transicin
L2 -Lugar
12
T1
T3 T6 A2 A5
T4
T5
A6
A7
T2 T7 T8 Concurrencia T9
L3
L4
L5
L3
Mquina dispensadora
T1-Inserta moneda E1- Tiene moneda T4-dispensa T2- rechaza moneda T3- acepta moneda
13
Historia Clnica
Registro Contable
El diagrama no es suficiente para precisar el comportamiento: por un flujo que entra a un proceso desde un archivo, fluye un registro o todo el archivo?.
No estipula sincronizacin, un flujo llega a una entidad externa y otro sale Estn relacionados? Uno es respuesta del otro?. Se complementa con un diccionario de datos que describe:
Sntomas
Paciente Paciente
estructura de los flujos y otros detalles. los procesos (lenguaje natural estructurado) con lo que el comportamiento queda determinado. A menudo sistemas legados estn documentados con DFD.
Caso
de
Uso
Reutilizable
Retiro de <<include>> M onedas < < include> > Retiro Cliente Dep sit o < <include> > V alidar con P IN
Caso de Uso:
<< inc l ude>>
Conjunto de escenarios posibles que Generalizacin puede encarar Va li dar Client e un actor (o varios) con el sistema para el logro de cierto objetivo.
14
Estudio de factibilidad
Especificacin de Requerimientos
Validacin de Requerimientos
Artefactos
Informe de factibilidad Documento de Requerimientos Modelo del Sistema Especificacin de Requerimientos
Balancear
Calidad
Alcance
Necesidades Expectativas
Restricciones
Prototipado.
Proceso
15
Ventajas Ventajas
Ahorra tiempo de otros. Prepara para otros enfoques. Puede llevarse a cabo fuera de la organizacin.
Desventajas
Costoso. Depende de las habilidades interpersonales.
Desventajas
Perspectiva limitada. Desactualizado. Demasiado genrico.
Su principal uso es para validar asunciones y obtener datos estadsticos sobre preferencias. Ventajas
Conveniente para contesta. Respuestas annimas. quien
Desventajas
Menos Rico. Problemas por no Respuestas. Esfuerzo de desarrollo.
16
parcial,
permite
los
desarrolladores y
Entender mejor los requerimientos. Cuales son necesarios, deseables. Acotar riesgos.
Prototipo desechable: El propsito es solo establecer que algo se puede hacer, luego se parte de cero en la construccin, quedando el conocimiento aprendido. Prototipo evolutivo: Es implementado sobre la arquitectura del producto final, el sistema final se obtiene de evolucionar el prototipo. Aspectos para los que es frecuente construir prototipos:
Usarlo
Cuando el sistema est orientado a la funcionalidad, con varios tipos de usuarios. Cuando la implementacin se va a hacer OO y con UML.
Apariencia y percepcin de la interfaz de usuario. Arquitectura (riesgos tcnolgicos, tiempos de respuesta). Otros aspectos riesgosos.
Estudio de factibilidad
Especificacin de Requerimientos
Validacin de Requerimientos
Luego se chequea la definicin para ver si cada requerimiento es rastreable hasta la especificacin.
Artefactos
Informe de factibilidad Documento de Requerimientos Modelo del Sistema Especificacin de Requerimientos
Es importante recordar, que la validacin no es tan solo un rastreo de traza. Ya que, adems, pretende garantizar que el sistema har lo que los clientes y usuarios esperan. Validando que las metas e intenciones de los usuarios y clientes estn satisfechas.
17
Medicin de Requerimientos
La medicin de requerimientos est enfoca a tres reas: Producto, Proceso y Recursos. Los productos de los requerimientos (definicin y especificacin) pueden ser evaluados en primer lugar considerando el nmero de requerimientos. De manera similar se puede medir la cantidad de cambios introducidos a los requerimientos. Un gran nmero de cambios indica cierta inestabilidad o incertidumbre en la comprensin de lo que el sistema debe hacer o como comportarse. Tambin es bueno evaluar la incertidumbre por tipo de requerimiento. Esto permite seccionar.
Incluye:
Revisar objetivos del sistema. Evaluar alineamiento de requerimientos con los objetivos (necesidad). Revisar el ambiente de operacin y las interfaces con otros sistemas. Funciones completas, restricciones realistas. Evaluar riesgos. Considerar: o Pruebas del sistema.
o Cambios en los requerimientos en el proyecto, su verificacin y validacin.
Medicin de Requerimientos
Debido a que los requerimientos son utilizados por los diseadores y verificadores, pueden utilizarse medidas que reflejen cuando los requerimientos estn preparados para derivar a ellos. Existe un forma de evaluacin utilizada para verificadores y diseadores, donde califican los requerimientos en una escala de 1 a 5 para saber si estos estn listos. La escala es la siguiente:
1. Lo comprende por completo, ha diseado (verificado) requerimiento similar antes y no debera tener problema. 2. El requerimiento posee algn elemento que le resulta nuevo, pero no es radicalmente distinto de lo que ha diseado (verificado) con xito antes.
Medicin de Requerimientos
3. Hay elementos nuevos que lo hacen muy diferente de los que ha diseado (verificado) antes, pero los comprende y piensa que a partir de ellos puede desarrollar un buen diseo (prueba). 4. Hay partes del requerimiento que no entiende bien y no est seguro de poder desarrollar un buen diseo (prueba). 5. No comprende este requerimiento en absoluto y no puede desarrollar un diseo (prueba) para l.
Si un verificador o diseador entrega un perfil con mayora de 1 y 2 entonces el requerimiento esta en forma y puede pasar al equipo de diseo o verificacin.
Diseadores Verificadores
OK
5
A
1 2 3 4 5 1 2 3 4
B
1 2 3 4 5 1 2 3 4 5
18