Requerimientos

Requerimientos

Jetzt loslegen. Gratis!
oder registrieren mit Ihrer E-Mail-Adresse
Requerimientos von Mind Map: Requerimientos

1. Clasificación General

1.1. LOS FUNCIONALES:

1.2. Son aquellos que van a definir todas las transformaciones que el sistema realizara sobre las entradas de datos.

1.3. LOS NO FUNCIONALES:

1.4. Son todas aquellas limitantes que puede tener el sistema como por ejemplo, las disponibilidades de equipo, mantenimiento, la seguridad, etc.

2. Caracteristicas

2.1. Describen una interacción entre el sistema y su ambiente.

2.2. Cómo debe comportarse el sistema ante determinado estímulo.

2.3. Describen lo que el sistema debe hacer, o incluso cómo NO debe comportarse.

2.4. Describen con detalle la funcionalidad del mismo.

2.5. Son independientes de la implementación de la solución.

2.6. Se pueden expresar de distintas formas

3. Otras Clasificaciones

3.1. Requerimientos del dominio

3.1.1. Reflejan las características y restricciones del dominio de la aplicación del sistema.

3.1.2. Pueden ser funcionales o no funcionales y pueden restringir a los anteriores.

3.1.3. Como se especializan en el dominio son complicados de interpretar.

3.2. Requerimientos por Prioridad

3.2.1. Que deben ser absolutamente satisfechos

3.2.2. Que son deseables pero no indispensables

3.2.3. Que son posibles, pero que podrían eliminarse

3.3. Requerimientos del Usuario

3.3.1. Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe operar.

3.3.2. Pueden surgir problemas por falta de claridad, confusión de requerimientos, conjunción de requerimientos.

3.4. Requerimientos del Sistema

3.4.1. Establecen con detalle los servicios y restricciones del sistema.

3.4.2. Es difícil excluir toda la información de diseño (arquitectura inicial, interoperabilidad con sistemas existentes, etc.)

4. Caracteristicas

4.1. Describen una restricción sobre el sistema que limita nuestras elecciones en la construcción de una solución al problema.

4.2. Requerimientos del producto: Especifican el comportamiento del producto (usabilidad, eficiencia, rendimiento, espacio, fiabilidad, portabilidad).

4.3. Requerimientos organizacionales: Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador (entrega, implementación, estándares).

4.4. Requerimientos externos: Interoperabilidad, legales, privacidad, seguridad, éticos.

5. 1. Correcta

5.1. Una SRS es correcta, sí y solo sí, cada requisito especificado es un requisito que el software debe cumplir.

6. 2. No ambigua

6.1. Una SRS no es ambigua sí y solo sí cada requisito especificado tiene sólo una interpretación.

7. 3. Completa

7.1. Una SRS es completa, sí y solo sí, incluye los siguientes elementos

7.1.1. a) Todos los requisitos significativos, ya sea que se relacionen a funcionalidad, desempeño, restricciones de diseño, atributos o interfaces externas. En particular cualquier requisito externo impuesto por una especificación del sistema debe ser reconocido y tratado.

7.1.2. b) Definición de las respuestas del software a todos los tipos posibles de clases de datos de entrada en todos los tipos posibles de clases de situaciones. Notar que es importante especificar las respuestas tanto para valores de entrada válidos como inválidos.

7.1.3. c) Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la SRS así como la definición de todos los términos y unidades de medida.

8. 4. Consistente

8.1. Una SRS es consistente, sí y solo sí, no se contradice a sí misma, es decir, si ningún subconjunto de requisitos ahí descritos se contradicen o entran en conflicto

9. 5. Calificada de acuerdo a la importancia y/o estabilidad

9.1. Una SRS está calificada de acuerdo a la importancia y/o estabilidad si cada requisito tienen un identificador que indique la importancia o estabilidad del requisito.

10. 6. Verificable

10.1. Una SRS es verificable, sí y solo sí, cada requisito especificado es verificable. Un requisito es verificable sí y solo sí existe un proceso finito de costo-efectivo con el cual una persona o una máquina puede verificar que el producto de software cumple el requisito. En general cualquier requisito ambiguo no es verificable.

11. 7. Modificable

11.1. La modificabilidad generalmente requiere que una SRS

11.1.1. a) Tenga una organización coherente y fácil de usar con una tabla de contenido, un índice y referencias cruzadas explícitas.

11.1.2. b) No sea redundante (esto es, el mismo requisito no debe aparecer en más de una parte en la SRS).

11.1.3. c) Expresa cada requisito de manera separada, en vez de hacerlo mezclado con otros requisitos.

12. 8. Rastreable

12.1. Una SRS es rastreable si el origen de cada uno de sus requisitos es clara y si facilita la referencia de cada requisito en el desarrollo futuro o mejora de la documentación.

12.1.1. Existen dos tipos de rastreabilidad

12.1.1.1. Rastreabilidad hacia atrás (esto es, a estados previos del desarrollo). El requisito tiene referencias explícitas a sus fuentes en documentos anteriores.

12.1.1.2. Rastreabilidad hacia enfrente (esto es, a todos los documentos derivados del SRS). Depende de que cada requisito en la SRS tenga un nombre único o número de referencia.