1

Resumen unidad 1

Argeniz Antonio Romero García.

Febrero 2018.
 2

Especificación de requisitos de software

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 requisitos funcionales. Además de los casos de
uso, la ERS también contiene requisitos no funcionales (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

1. Requisitos de Usuarios: Necesidades que los usuarios expresan verbalmente

2. Requisitos del Sistema: Son los componentes que el sistema debe tener para
realizar determinadas tareas
3. Requisitos Funcionales: Servicios que el sistema debe proporcionar al finalizar el
sistema
 3

Norma IEEE 830

El estándar 830-1998 fue generado por un equipo de trabajo del IEEE, su finalidad es la
integración de los requerimientos del sistema desde la perspectiva del usuario, cliente y
desarrollador.

Esta ha sido nuestra propuesta durante la existencia como blog, la 830 se encarga de
poner las pautas para identificar y esquematizar los requerimientos de software. como
parte integral del desarrollo de software, sino también como base fundamental de este,
todo esto con el fin de no caer en cambios, errores o situaciones que pongan en peligro la
creación de una solución, producto o software; incurriendo en gastos o cambios producto
de un mal análisis de requerimientos

Trazabilidad de requisitos

La trazabilidad de requisitos es una herramienta fundamental para la gestión de

requisitos. Es elemental para el control y como apoyo para la toma de decisiones en el
proyecto. Como no es un entregable o componente del producto, se debe cuidar que su
creación y uso sea lo más eficiente posible.

Se define trazabilidad, o en algunos textos rastreabilidad, como la asociación del requisito

con otros requisitos y las diferentes instancias con que se relaciona durante la evolución
de las diferentes fases del ciclo de desarrollo del producto o servicio. Esa asociación se
controla en ambos sentidos, de los requisitos a los resultados y viceversa. La intención
principal es poder determinar si todos los requisitos base han sido considerados y si las
instancias que han sido generadas pueden asociarse con un requisito válido.

Diagramas UML

En UML el diagrama de clases es uno de los tipos de diagramas o símbolo estático y

tiene como fin describir la estructura de un sistema mostrando sus clases, atributos y
relaciones entre ellos.

Estos diagramas son utilizados durante el proceso de análisis y diseño de los sistemas
informáticos, en donde se intentan conformar el diagrama conceptual de la información
que se manejará en el sistema.

Como ya sabemos UML es un modelado de sistema Orientados a Objetos, por ende, los
conceptos de este paradigma se incorporan a este lenguaje de modelado.

Los diagramas de clases tienen las siguientes características:

• Las clases define el ámbito de definición de un conjunto de objetos.
 4

• Cada objeto pertenece a una clase.

• Los objetos se crean por instanciación de las clases.

Estudio de factibilidad

Es importante que tanto el cliente como el desarrollador tengan la misma visión del
proyecto, por lo que la comunicación inicial es importante.

No solo se trata de que el cliente diga lo que requiere, porque muchas veces esta lista de
requisitos escapa de los limites del problema, así que lo primero será partir de la
necesidad o problema que da origen a la solicitud de desarrollo, dado que dicha solicitud
no es siempre hecha por quien esta mas ligado con el problema, entendiendo que, quien
solicita el software, usualmente no es quien lo va a tener que utilizar, por lo que los
requisitos e incluso el problema varían según el nivel de la organización donde nos
encontremos
 5

Lista de referencias

Es.wikipedia.org. (2018). Especificación de requisitos de software. [online] Available at:

https://es.wikipedia.org/wiki/Especificación_de_requisitos_de_software [Accessed 2 Feb.
2018].

Estudio de factibilidad. [online] Sistemasumma. Available at:

https://sistemasumma.com/2015/11/06/estudio-de-factibilidad/ [Accessed 2 Feb. 2018].

(2018). Estudio de factibilidad. [online] Sistemasumma. Available at:

https://sistemasumma.com/2015/11/06/estudio-de-factibilidad/ [Accessed 2 Feb. 2018].

Es.wikipedia.org. (2018). Especificación de requisitos de software. [online] Available at:

https://es.wikipedia.org/wiki/Especificación_de_requisitos_de_software [Accessed 2 Feb.
2018].
6