Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

INTRODUCCION AL ANALISIS DE REQUISITOS

No description
by

PATRICIO VACA ESCOBAR

on 12 August 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of INTRODUCCION AL ANALISIS DE REQUISITOS

En la determinación de los requisitos no sólo deben actuar los analistas, es muy importante la participación de los propios usuarios.

El documento de especificación de requisitos debe ser legible por el cliente, con lo que se evita el malentendido de determinadas situaciones.

Basándose en estos requisitos, el ingeniero de software procederá al modelado de la futura aplicación. Para ello, se pueden utilizar diferentes tipos de metodologías entre las que destacan la metodología estructurada y la metodología orientada a objetos (por ejemplo DFDs y UML respectivamente).

La metodología estructurada está basada en la representación de las funciones que debe realizar el sistema y los datos que fluyen entre ellas.

En la metodología orientada a objetos se utiliza el UML
Características de una buena ERS
Las características deseables para una buena especificación de requisitos software que se indican en el IEEE son las siguientes:
OBJETIVOS DE LA ERS
Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado software

Ayudar a los desarrolladores a entender qué quiere exactamente el cliente

Servir de base para desarrollos de estándares de ERS particulares para cada organización

Una ERS forma parte de la documentación asociada al software que se está desarrollando, por tanto debe definir correctamente todos los requerimientos, pero no más de los necesarios.
ANALISIS DE REQUISITOS
INTRODUCCION AL ANALISIS DE REQUISITOS
El análisis de requisitos es una de las tareas más importantes en el ciclo de vida del desarrollo de software, puesto que en ella se determinan los “planos” de la nueva aplicación.

Definicion:
se puede definir como el proceso del estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema, hardware o software,
CORRECCION:
La ERS es correcta si y sólo si todo requisito que figura en ella refleja alguna necesidad real. La corrección de la ERS implica que el sistema implementado será el sistema deseado.

AMBIGUEDAD
Un documento es no ambiguo si y solo si cada requisito descrito tiene una única interpretación. Cada característica del producto final debe ser descrita utilizando un término único y, en caso de que se utilicen términos similares en distintos contextos, se deben indicar claramente las diferencias entre ellos.
Correcta
• No ambigua
• Completa
• Verificable
• Consistente
• Clasificada
• Modificable
• Explorable
• Utilizable durante las tareas de mantenimiento y uso
COMPLETITUD

Una ERS es completa si:

• Incluye todos los requisitos significativos del software (relacionados con la funcionalidad, ejecución, diseño, atributos de calidad o interfaces externas).

• Existe una definición de respuestas a todas las posibles entradas, tanto válidas como inválidas, en todas las posibles situaciones.

• Cumple con el estándar utilizado. Si hay alguna parte del estándar que no se utiliza, se debe razonar suficientemente el porqué no se ha utilizado dicho apartado.

• Aparecen etiquetadas todas las figuras, tablas, diagramas, etc, así como definidos todos los términos y unidades de medida empleados.
VERIFICABILIDAD
Un requisito se dice que es verificable si existe algún proceso no excesivamente costoso por el cual una persona o una máquina pueda chequear que el software satisface dicho requerimiento.
Consistencia
Una ERS es consistente si y sólo si ningún conjunto de requisitos descritos en ella son contradictorios o entran en conflicto. Se pueden dar tres casos:
• Requisitos que describen el mismo objeto real utilizando distintos términos.
• Las características especificadas de objetos reales. Un requisito establece que todas las luces son verdes y otro que son azules.
• Conflicto lógico o temporal entre dos acciones determinadas. Se llega a un punto en el
Clasificación
No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por diversos criterios:
• Importancia: Pueden ser esenciales, condicionales u opcionales.
• Estabilidad: Cambios que pueden afectar al requisito.

Modificabilidad
Una ERS es modificable si cualquier cambio puede realizarse de manera fácil, completa y consistente.

También es deseable evitar la redundancia, es decir que no aparezca un mismo requisito en más de un lugar de la ERS. No es un error, pero si se tiene que modificar alguna cosa será mucho más cómodo si no tenemos que buscar el mismo requisito en varios lugares
Explorabilidad

Una ERS es explorable si el origen de cada requerimiento es claro tanto hacia atrás (origen que puede ser un documento, una persona etc.) como hacia delante (componentes del sistema que realizan dicho requisito).

Utilizable durante las tareas de mantenimiento y uso
En la ERS también se deben tener en cuenta las necesidades de mantenimiento. personal que no ha intervenido directamente en el desarrollo debe ser capaz encargarse de su mantenimiento. Así, dicha ERS actúa a modo de plano de aplicación,
Full transcript