ESPECIFICACION DE REQUERIMIENTOS DE SOFTWARE (ERS) (SRS)

ESPECIFICACION DE REQUERIMIENTOS DE SOFTWARE (ERS) (SRS)

Es un documento donde se especifican los términos acordados por usuario y desarrollador al momento de construir un programa. en este se especifican los requerimientos funcionales de la misma, así como como también los no funcionales

REQUERIMIENTOS FUNCIONALES

son todos los requisitos que se enfocan en especificar las funciones esenciales del programa, tales como botones de acceso, almacenamiento, opciones de recuperación, rutas de salida.

REQUERIMIENTOS NO FUNCIONALES.

son todos aquellos que no interfieren directamente con la funcionalidad del programa más bien se enfoca en los estándares bajo los cuales se construyó el programa.

CARACTERÍSTICAS DE UN BUEN (SRS)

segun el estandar IEEE 830-1998, un buen srs debe contar con las siguientes características para garantizar su entendimiento para ambas partes involucradas en el desarrollo de programa, (cliente y desarrollador)

1)CORRECTO. un SRS se considera correcto solo si cada requisito acordado en el documento es verificable en el programa.

2)INEQUÍVOCO. cada requisito declarado en el documento debe tener una sola interpretación para ambas partes, para ello se deben utilizar términos únicos al describir el programa.

para evitar que un término tenga interpretaciones distintas se debe incluir un glosario y esta misma debe ser en el idioma natural de ambas partes.

3)COMPLETO. para considerarse completo un SRS debe incluir los elementos siguientes

  a) todos los requisitos deben estar relacionados a la funcionalidad, el diseño, las características y las interfaces externas, y todas las restricciones también deben ser incluidas.

   b)debe describir las reacciones del programa a las distintas entradas y las contestaciones o las respuestas de la misma a las entradas validas e invalidas.

   c)debe definir las etiquetas, figuras, tablas y diagramas contenidos en el programa. asi como también definir todas las unidades de medida y condiciones.

nota: si un SRS utiliza el término "to be determined" (TBD) no se considera completo.

si un requerimiento aun no es definido, se debe especificar las condiciones que pueden provocar el requerimiento cambie o los pasos a seguir para eliminarla. para que esta pueda considerarse resuelta .

4) CONSISTENTE, un SRS se considera consistente solo si es compatible con cualquier otro documento de nivel superior. en el caso de existir conflictivas con algún requerimiento de sistema, el SRS ya no se considera compatible.

un ejemplo de inconsistencia es que un controlador de batería indique que cuando la batería está llena la luz es verde pero en otros sistemas puede ser azul.

5) DELINEAR QUE TIENE IMPORTANCIA Y/O ESTABILIDAD. Un SRS debe contar con un identificador para indicar cuando un requisito es importante o estable siendo bien específicos en grado de estabilidad y necesidad. como y cuando un elemento es esencial, condicional y optativo.

6) COMPROBABLE, para que un SRS se considere comprobable, deben utilizarse términos finitos e indicar con exactitud la ejecución de un proceso, para que una máquina o un humano pueda medir exactamente en cuanto tiempo o cuantas veces se realizara un proceso.

términos como "trabaja bien, interface humana buena, o normalmente pasara", se consideran procesos no verificables por lo tanto se debe evitar su uso en un SRS.

7) MODIFICABLE. un SRS debe tener una estructura que garantice un cambio a los requisitos sin alterar el diseño original.

para facilitar la modificación de requisitos se debe evitar que el mismo aparezca en más de una vez en el documento.

cada requisito debe tratarse por separado y no mezclarlo con otros requisitos.

8) IDENTIFICABLE. Cada requisito en un SRS debe ser claro y se le debe incluir una referencia para facilitar su documentación en procesos futuros. Existen dos tipos de identificabilidad.

 a) identificable hacia atrás, esto quiere decir que un requisito debe ser fácil de encontrar en las fases anteriores de desarrollo.

 b) identificable delantero, cada requisito debe contar con un numero de indentificacion para poder determinar si puede resultar afectado durante un proceso de mantenimiento o modificación y asi tener un dato exacto de que requisitos se alteraron y cuales permanecen intactas.

                  

PARTES DE UN SRS.

1 INTRODUCCIÓN.

  - esta es una apreciación global de contenido del documento, en esta parte se pueden incluir;

  - El propósito del programa

  - El alcance.

  - Definiciones, siglas y abreviaciones

  - Referencias.

2. DESCRIPCIÓN GLOBAL. En esta parte se mencionan todos los detalles de las funciones del programa tales como:

   - Perspectiva del programa

   - Funciones

   - Características del usuario

   - Restricciones

   - Atención y dependencias.

3. REQUISITOS ESPECIFICOS. esta el la parte más importante del SRS ya que esta debe ser lo suficientemente clara y explicita para garantizar que tanto desarrollador, usuario, auditor y todas las partes involucradas puedan entenderlo de la misma forma.

a) se deben especificar todos los requisitos de acuerdo con todas la características descritas.

b) cada requisito específico debe tener una referencia para garantizar su compatibilidad con cualquier otro documento de mayor validez o mas actualizado.

c) ningún requisito puede ser identificado igual a otro, cada un debe ser identificado individualmente.

d) todos lo requisitos deben estar organizados de manera que  no sean complicado encontrarlos.