Ir al contenido principal

Importancia de las Características de los Requisitos de una ERS

Los requisitos en una ERS (Especificación de Requisitos de Software) tienen que tener una serie de características, las cuales permiten una correcta comprensión de los mismos, para que pueda ser utilizado sin mayores problemas.

Algunas características recomendadas en los requisitos son las siguientes:

·         Completa: No puede faltar ningún requisito, todas las referencias entre requisitos, tablas, figuras deben estar presentes y no puede quedar alguna situación posible sin respuesta.

·         Consistente: No pueden estar presentes contradicciones entre requisitos, otros documentos de especificación o en un mismo requisito.

·         Inequívoca: Todos los requisitos deben estar libres de ambigüedad, de modo que tengan una solo interpretación.

·         Correcta: Los requisitos tienen que cumplir con las necesidades del cliente.

·         Trazable: Es la característica de poder ubicar un requisito o determinar su origen.

·         Prioridad: Cada requisito debe poder asignársele una categoría, para poder determinar su relevancia dentro del desarrollo.

·         Modificable: Debe ser fácilmente modificable, su redacción tiene que ser de forma ordenada y sin redundancia para permitir esto.

·         Verificable: Debe existir un proceso finito que permita, ya sea a una persona o máquina, verificar cada requisito sin un costo elevado.

Las características anteriores son importantes que estén presentes en todos los requisitos de una ERS, ya que no solo serán utilizados por el cliente o los desarrolladores principales del software, sino que existen más personas involucradas en la utilización de este documento, entre los cuales se encuentran los siguientes:

·         Clientes: Son los encargados de indicar sus requisitos o necesidades, por ello, leen el documento para comprobar que cumple con lo indicado y si no quedan satisfechos sugieren cambios en los requisitos.

·         Gestores: Se encargan de analizar los requisitos y generar un plan de desarrollo, para poder hacer una oferta por el sistema.

·         Desarrolladores: Utilizan la ERS para entender el problema y que es lo que tienen que desarrollar para cubrir las necesidades del cliente.

·         Encargados de pruebas: Utilizan los requisitos, para generar pruebas para el sistema, de esta forma comprobar que el sistema realiza lo indicado en ellos.

·         Encargados de mantenimiento: Se apoyan en los requisitos para entender el funcionamiento del sistema que se le brindara mantenimiento.
Fuente: Propia

Como vemos los requisitos tienen que tener las características mencionadas anteriormente, ya que son diversas las personas que utilizan la ERS con diferentes fines en el proceso de desarrollo de software. De esta forma todos los involucrados pueden comprender el sistema y realizar su trabajo de acuerdo con lo indicado en los requisitos.

Referencias:
https://www.ctr.unican.es/asignaturas/is1/IEEE830_esp.pdf

Comentarios

Entradas populares de este blog

Diagrama de Secuencia del Sistema (DSS)

Existen diferentes formas de explicar un sistema de software que se esté desarrollando, por ejemplo, los casos de uso, estos nos muestran una función específica que realiza el sistema, pero estos pueden ser explicados de una forma diferente por medio de los diagramas de secuencia del sistema. Los DSS es un modelo que muestra al sistema como una caja negra para un caso de uso específico, donde se muestran los actores externos que participan en él, también el orden de los eventos que suceden durante la ejecución del caso de uso. Se dice que debería haber un DSS para cada caso de uso de un proyecto de software, esto debido a que cada DSS se deriva directamente de un caso de uso. Se puede decir que los DSS explican los casos de uso de una forma diferente mostrando las secuencias de eventos que suceden en los casos de uso, estas secuencias comúnmente inician con un verbo, ya que describen una acción que sucede. En los diagramas como tal, el tiempo avanza hacia abajo respetando el

Requerimientos Volátiles y Estables

Los requerimientos de un proyecto de software se pueden clasificar de formas distintas por ejemplo cuando identificamos los requisitos funcionales, no funcionales y los de información, pero también es posible clasificarlos de una forma distinta, más específicamente en volátiles y estables. Requerimientos Volátiles: Estos requisitos volátiles (Cambiantes) tienen una alta probabilidad de sufrir cambios durante el proceso de desarrollo del software, pero también pueden cambiar fuera de dicho proceso cuando el software está terminado o incluso cuando ya está en uso por parte del usuario. Estos requisitos tienen subclasificaciones ya que son muy diversos, los cuales son los siguientes. ·          Mutables: Reciben este nombre los requisitos que se ven afectados por cambios que puedan presentarse en el ambiente con el que opera la organización. ·          Emergentes: Estos aparecen cuando el proceso de diseño de los requerimientos, facilitan el entendimiento del sistema y le perm

StakeHolders

La palabra stakeholders se utiliza para definir a las personas, grupo de personas o empresas que están interesados en un proyecto especifico, en nuestro caso un proyecto de software. El termino stakeholders se puede traducir como “interesados”, estos interesados son empresas o personas que tienen relación de alguna forma con el proyecto y no necesariamente trabajan en el. Algunos ejemplos son los siguientes: Empresas y Organizaciones: En algunos casos los proyectos necesitan de la aprobación de otras empresas u organizaciones para poder desarrollarlo, como financiamientos, seguros, aprobación de licencias etc. Usuarios: Son las personas a las cual va dirigido el proyecto, son los usuarios del programa informático en un proyecto de software, estas personas pueden estar de acuerdo o en desacuerdo con el proyecto. Afectados: Son personas u organizaciones que están indirectamente involucrados en el proyecto, y tampoco son el objetivo de los resultados del proyecto, p