REQUERIMIENTOS

¿Porque falla un Proyecto de Software?

Principales factores que hacen canelar un proyecto de Software.

Principales factores que hacen un proyecto exitoso.

Requerimientos.

Requerimiento.

Condición o capacidad que:

• Necesita un usuario para resolver un problema o alcanzar un objetivo.
• Debe cumplirse o poseer un sistema o componente del sistema para satisfacer un contrato, estándar, especificación u otro documento formal mente impuesto.

¿Quienes intervienen en su especificación?

Tipos de Requerimientos.

Existen dos tipos de requerimientos:

• Requerimientos Funcionales.
• Requerimientos No Funcionales.

Requerimientos Funcionales.

• Describe lo que el Software debe hacer.
• Se conocen como requerimientos conductuales u operacionales, ya que describen las entradas al sistema y las respuestas al sistema, así como las relaciones entre ellos.

Requerimientos no Funcionales.

Describen consideraciones sobre confiabilidad y seguridad en el Software.

• Del producto.
• Organizacionales.
• Externos.

¿Para que sirven los requerimientos?

1. Describen precisamente lo que los clientes quieren saber.
2. Proveen las bases para el posterior desarrollo del software.
3. Facilitan la aplicación:

• Gestión de los registros.
• Control de cambios.
• Planeacion del proyecto.

Especificación de los requerimientos de software (Software Requeriments Specification) – SRS

Es la documentación de los requerimientos esenciales del software y sus interfaces externas.

Especificación de requerimientos del software.

Aspectos a considerar.

•  Funcionalidad: ¿Que va hacer el software?
• Interfaces externas: ¿Como interactua recíprocamente con las personas y otros software?
• Rendimiento: ¿Cual es la disponibilidad, tiempo de la recuperación de varias funciones del software, etc.?
• Atributos: ¿Que potabilidad tiene, exactitud, mantenimiento, la seguridad, etc.?
• Restricciones del diseño: ¿Hay algún requerimiento empresarial, Standard, lenguaje de aplicación, políticas para la integridad de los datos, los limitas de los recursos, de ambiente, etc.?

Atributos de los Requerimientos.

Considerados en conjunto:

• Correcto, No Ambiguo, Completo, Consistente, Jerarquizado.

Considerados individualmente:

• Verificable, Modificable y Rastreable.

Atributo: Correcto.

• Un SRS es correcto, si y solo si, cada requisito declarado se encuentra en el software.
• Alternativamente el cliente y el usuario pueden determinar si los requerimientos reflejan las necesidades reales.
• Identificar los requerimientos hace este proceso mas fácil y hay menos probabilidad de error.

Atributo: No Ambiguo.

1. Cada requisito declarado debe tener una sola interpretación.
2. En casos donde un término en un contexto particular tenga significados múltiples, el término debe de ser incluido en un glosario donde su significado es mas específico.
3. Evitar la ambigüedad:

• Confusiones del idioma natural.

• Idiomas de especificación de requisitos.

• Representación hecha con herramienta.

Atributo: Completo.

• Los requisitos están relacionados a los aspectos básicos a considerar.
• En particular debe reconocerse cualquier requisito externo impuesto por una especificación del sistema.
• Las definiciones de las respuestas del software a todos los posibles datos de la entrada del sistema y a toda clase de situaciones.
• Identificar los requerimientos y referencias a todas las figuras y tablas.
• Si existen requerimientos pendientes de determinar (To Be Determined – TBD). Debe especificarse:

1. Una descripción de las condiciones que causan la condición TBD para que la situación pueda resolverse.
2. Una descripción de lo que debe de hacerse para eliminar la TBD.

Atributo: Consistente.

• Las características especificadas en el mundo real de los objetos pueden chocar.

• Puede haber conflictos lógicos o temporal entre dos acciones especificadas.

• Dos o más requerimientos pueden describir el mismo objeto, pero deben de usar condiciones diferentes para el mismo.

Atributo: Jerarquía.

1. Grado de estabilidad. Puede expresarse la estabilidad por lo que se refiere al número de cambios esperados o cualquier requerimiento basado en la experiencia.
2. Grado de necesidad: alinear los requerimientos por su grado de necesidad del proyecto.

• Esenciales.

• Condicionales.

• Optativos.

Atributo: Verificable.

Cuando existe algún proceso costo – efectivo finito con que una persona o sistema puede verificar que el producto de software cumple con el requerimiento.

Atributo: Modificable.

• Puede hacerse cualquier cambio fácilmente y consistentemente.
• Es fácil de usar, contiene un índice y referencias cruzadas y explícitas.
• No es redundante.
• Expresar cada requisito separadamente, en lugar de intercalarlos con otros requisitos.
• La redundancia no es un error, pero puede llevar fácilmente a los errores.

Atributo: Rastreable.

• Es claro y facilita las referencias de cada requerimiento en el desarrollo futuro o la documentación.
• Rastreable hacia atrás (Fases anteriores): Referencia la fuente de donde proviene.
• Rastreable hacia adelante (Fases posteriores): Cada documento debe tener un único nombre o número de referencia.

Obtención de requerimientos.

Preparación para recolectar datos.

• Identificar la información a recolectar.
• Preparar cuestionarios e informes.
• Preparar y Realizar entrevistas.

Nota: Cada cuestionario, entrevista, resumen y reunión de trabajo; debe encaminarse a recolectar datos específicos.

Recolectar Requerimientos.

1. Enviar cuestionarios.
2. Efectuar entrevistas.
3. Revisar documentación existente.
4. Tomar notas.
5. Organizar la información recolectada:
   • En carpetas.
   • Un sistema con índice.
6. Documentar requerimientos necesita de un análisis para:
• Eliminar redundancia.
• Identificar los impacto de diferentes puntos de vista.
• Organizarlos en algo coherente.
• Identificar ambigüedades.

Entrevistas.

• Puntos fuertes:
  • Permite conocer a los posibles usuarios en un ambiente controlado.
• Puntos vulnerables: las personas no siempre están dispuestas a ser entrevistadas, ya que:
  • Temen hacer un mal papel.
  • Temen perder poder si revelan lo que saben.
  • No se sienten en confianza con el analista.

Prototipos.

1. El prototipo se realiza y se muestra a los usuarios cuando ya se están comprendiendo los requerimientos.
2. Los prototipos deben ser evolutivos:
   • Al entender los requerimientos los prototipos se siguen desarrollando.
   • Se le agregan nuevas funcionalidades iterativa mente.
   • Es la base para la versión final que se entrega al cliente.

 Cuestionarios.

1. Hay varios tipos:
   1. Nominal.
   2. Ordinal.
   3. Radio – escalas.
   4. y de Intervalos.
2. Puntos fuertes:
   1. Obtiene información cuando la gente se encuentra dispersa y/o hay mucha gente involucrada en el sistema.
   2. Para conocer y sensibilizar a los interesados antes de ser entrevistados.
3. Puntos vulnerables:
   1. El lenguaje utilizado debe de ser muy preciso.
   2. Se necesita bastante práctica.

Cuestionario: nominal.

• El departamento en que trabaja es:
  1. Inversiones.
  2. Operaciones.
  3. Ventas.
• Mi nivel de estudios es:
  1. Preparatoria.
  2. Licenciatura.
  3. Maestría.
  4. Doctorado.

Cuestionario: Ordinal y de Intervalo.

• El soporte dado por el personal del centro de cómputo es:

Inútil                                                    Extremadamente útil
1                      2                       3                      4                       5

• El volumen de movimientos mensuales es:

• a)1 a 10.
• b)10 a 100.
• c)100 a 1000.
• d)1000 a 10000.
• e)10000 en adelante.

Como se debe de redactar un requerimiento.

1. Los requerimientos se redactan iniciando con un verbo en infinitivo siempre y cuando el requerimiento sea funcional.
2. Un requerimiento debe de especificar una sola tarea nada mas.
3. En la redacción de los requerimientos funcionales, normalmente se debe de hacer mención a los actores que participan en los mismos.