Diferencia entre revisiones de «Especificación de requisitos de software»

← Ir a diferencia anterior Ir a siguiente diferencia →

Contenido eliminado Contenido añadido

En renglón

Revisión del 00:15 8 nov 2017

La especificación de requisitos de software (ERS) de acuerdo a Teacher Fischer es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad.

Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su redacción debe ser informal, de forma que sea fácilmente comprensible para todas las partes involucradas en el desarrollo.

Prácticas recomendadas para una buena ERS

Las características de una buena ERS son definidas por el estándar IEEE 830-1998. Una buena ERS debe ser:

Completa. Todos los requerimientos deben estar reflejados en ella y todas las referencias deben estar definidas.
Consistente. Debe ser coherente con los propios requerimientos y también con otros documentos de especificación.
Inequívoca. La redacción debe ser clara de modo que no se pueda mal interpretar.
Correcta. El software debe cumplir con los requisitos de la especificación.
Trazable. Se refiere a la posibilidad de verificar la historia, ubicación o aplicación de un ítem a través de su identificación almacenada y documentada.
Priorizable. Los requisitos deben poder organizarse jerárquicamente según su relevancia para el negocio y clasificándolos en esenciales, condicionales y opcionales.
Modificable. Aunque todo requerimiento es modificable, se refiere a que debe ser fácilmente modificable.
Verificable. Debe existir un método finito sin costo para poder probarlo.

Tipos de requisitos

Requisitos de Usuarios: Necesidades que los usuarios expresan verbalmente
Requisitos del Sistema: Son los componentes que el sistema debe tener para realizar determinadas tareas
Requisitos Funcionales: Servicios que el sistema debe proporcionar al finalizar el sistema

Véase también

Análisis de requisitos

Referencias

Raymond Turner. "The Foundations of Specification". Journal of Logic and Computation, Vol. 15, No. 5 (October 2005), pp. 623–663.
IEEE STD 830-1998. "Especificaciones de los requisitos del Software", pág. 3.

@@ Línea 1: / Línea 1: @@
 {{fusionar | Ingeniería de requerimientos }}
-La '''especificación de requisitos de software''' ('''ERS''') es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de [[casos de uso]] que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como [[requisito funcional|requisitos funcionales]]. Además de los casos de uso, la ERS también contiene [[Requisito_no_funcional|requisitos no funcionales]] (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad.
+La '''especificación de requisitos de software''' ('''ERS''')  de acuerdo a Teacher Fischer es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de [[casos de uso]] que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como [[requisito funcional|requisitos funcionales]]. Además de los casos de uso, la ERS también contiene [[Requisito_no_funcional|requisitos no funcionales]] (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad.
 Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su redacción debe ser informal, de forma que sea fácilmente comprensible para todas las partes involucradas en el desarrollo.