Sistemas 5

INGENIERIA DE SOFTWARE
Análisis de Requerimientos
Material preparado por:

Ing. Armando Acuña Martínez
Análisis de Requisitos/Requerimientos
Considerando que el Diseño es una buena manera de

materializar con precisión y acercar a la realidad los
requisitos/requerimientos del cliente, es necesario
entender las características de los
requisitos/requerimientos.
La Especificación de Requisitos de Software (SRS),

define de forma precisa el producto de software que
se va a construir.
Proceso de Ingeniería de requisitos/requerimientos

Proceso de Ingeniería de Software:
Análisis de requisitos  Ingeniería de

Requisitos/Requerimientos
Modelo de desarrollo en V
http://cmunoz334.blogspot.es/tags/Modelo
El estándar IEEE-STD-830-1998 normaliza la

creación de las especificaciones de los requisitos
del software SRS, estableciendo sus
características para una buena definición:
Correcto, Inequívoco, Completo, Consistente,
Delinear que tiene importancia y/o estabilidad,
Comprobable, Modificable, Identificable.
Algunas otras características importantes:

Conciso, Alcanzable y Necesario.
Que describen esas características:

- Correcto: Un SRS es correcto si, y sólo si, cada
requisito declarado se encuentra en el software.
-Inequívoco o no ambiguo: Un SRS es inequívoco

o no ambiguo, si y sólo si, cada requisito
declarado tiene sólo una interpretación. El
lenguaje usado en su definición, no debe causar
confusiones al lector (prestar atención a las
traducciones de los requisitos).

-Completo: Un SRS está completo si, y sólo si, incluye los
elementos siguientes:
a) Los requisitos están relacionados a la funcionalidad, el
desarrollo, las restricciones del diseño, los atributos y
las interfaces externas.
b) b) La definición de las respuestas del software a todos
los posibles datos de la entrada del sistema y a toda
clase de situaciones.
c) Tener todas las etiquetas llenas y referencias a todas
las figuras, tablas, diagramas en el SRS y definición
de todas las condiciones y unidades de medida.

- Consistente: La consistencia se refiere a la
consistencia interior. Si un SRS no está de
acuerdo con algún documento del superior-nivel,
como una especificación de requisitos de
sistema, entonces no es correcto.
- Importancia y/o estabilidad: Un SRS debe

delinear la importancia y/o estabilidad si cada
requisito en él tiene un identificador para indicar
la importancia o estabilidad de ese requisito en
particular.

- Comprobable o verificable: Un requisito es
comprobable si, y sólo si, allí existe algún
proceso rentable finito con que una persona o la
máquina puede verificar que el producto del
software reúne el requisito.
Un requisito es verificable cuando puede ser
cuantificado de manera que permita hacer uso de
los siguientes métodos de verificación:
inspección, análisis, demostración o pruebas.

- Modificable: Un SRS es modificable si, y sólo si,
su estructura y estilo son tales que puede
hacerse cualquier cambio a los requisitos
fácilmente, completamente y de forma
consistente mientras conserva la estructura y
estilo.
- Identificable: Un SRS es identificable si el origen

de cada uno de sus requisitos está claro y si
facilita las referencias de cada requisito en el
desarrollo futuro o documentación del mismo.

- Conciso: Un requisito es conciso si es fácil de
leer y entender. Su redacción debe ser simple y
clara para aquellos que vayan a consultarlo en un
futuro.
- Alcanzable: Un requisito debe ser un objetivo

realista, posible de ser alcanzado con el dinero, el
tiempo y los recursos disponibles.

- Necesario: Un requisito es necesario si su
omisión provoca una deficiencia en el sistema a
construir, y además su capacidad, características
físicas o factor de calidad no pueden ser
reemplazados por otras capacidades del producto
o del proceso.
Discusión sobre dificultades para definir los

requisitos.
Fuentes de información:
-Sommerville Ian, Ingeniería de Software, Editorial Pearson
-Schach Stephen, Ingeniería de software clasica y orientada a objetos,

sexta edición Ed. McGraw Hill
-http://www.di.uniovi.es/~cueva/investigacion/lineas/patrones/PatronesIntro
duccion.pdf
-http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o

Sistemas 5

Cargado por

Copyright:

Formatos disponibles

Sistemas 5

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistemas 5

Cargado por

Copyright:

Formatos disponibles

INGENIERIA DE SOFTWARE

Material preparado por:

Considerando que el Diseño es una buena manera de

La Especificación de Requisitos de Software (SRS),

Proceso de Ingeniería de requisitos/requerimientos

Proceso de Ingeniería de Software:

Análisis de requisitos  Ingeniería de

El estándar IEEE-STD-830-1998 normaliza la

Algunas otras características importantes:

Que describen esas características:

-Inequívoco o no ambiguo: Un SRS es inequívoco

Que describen esas características:

Que describen esas características:

- Importancia y/o estabilidad: Un SRS debe

Que describen esas características:

Que describen esas características:

- Identificable: Un SRS es identificable si el origen

Que describen esas características:

- Alcanzable: Un requisito debe ser un objetivo

Que describen esas características:

Discusión sobre dificultades para definir los

-Schach Stephen, Ingeniería de software clasica y orientada a objetos,

También podría gustarte