Ing. Sonia Godoy H

Ing. Sonia Godoy H

1. Lo que el director desea.

2. Como lo define el director de proyecto

3. Como se diseña el Sistema.

4. Como lo desarrolla el programador

5. Como se ha realizado la instalación

6. Lo que el usuario quería.

QUÉ ES LA INGENIERIA DE REQUERIMIENTOS ????

CLIENTEUSUARIO

DOCUMENTACIÓN

CONDUCTAS

RESTRICIONES

NECESIDADES

Análisis de necesidades y estudio de viabilidad:

Decisión de emprender el proyecto

Recoger información sobre el proyecto(Directivos nivel alto/medio)

Estudio de la viabilidad del proyecto (Análisis de factibilidad)

Ing. Sonia Godoy H

Informe de necesidades

Técnicas recogida información

Elicitación

• Tiene como objetivos buscar, investigar y ayudar a los clientes y usuarios a documentar sus necesidades

• Entrevistas,reuniones en grupo, estudio in situ

Análisis

• Distinción y separación de las partes de un todo hasta llegar a conocer sus principios o elementos

Verificación de requisitos

• Detectar defectos en los requisitos previamente analizados, normalmente mediante técnicas como revisiones formales, listas de comprobación (checklists)…

Ing. Sonia Godoy H

„Validación

•Asegurar que los requisitos verificados reflejan realmente las necesidades de clientes y usuarios

•„ Las técnicas empleadas suelen ser reuniones en las que se revisan los requisitos mediante el apoyo de prototipos de interfaz de usuario

Negociación

•Buscar soluciones a los conflictos detectados que satisfagan a los distintos actores del proceso

Gestión

•Se encarga de todo el proceso, en especial las peticiones de cambios en los requisitos, el impacto de dichas peticiones, las distintas versiones de los requisitos…

Ing. Sonia Godoy H

Ing. Sonia Godoy H

QUÉ DESCRIBE UN REQUISITO??

Una utilidad para el usuario

Una propiedad general del sistema

Una restricción general del sistema

Una restricción sobre el desarrollo del sistema

Condición o capacidad que necesita el usuario

para resolver un problema o conseguir

un objetivo determinado [Piattini et al., 1996]

Una característica del sistema que es una condición para su

aceptación [DoD, 1994]

Una propiedad que debe exhibirse para

solucionar algún problema del mundo

real [Sawyer y Kontoya, 2001]

Una representación en forma de documento de

una condición o capacidad [IEEE,

1999a]

REQUISITO??

Ing. Sonia Godoy H

Ing. Sonia Godoy H

Ámbito

HARDWARAE

SOFTWARE

SISTEMA

CARACTERISTICAS

NO FUNCIONALESFUNCIONALES

AUDIENCIA

USUARIO

SOFTWARE

SISTEMA

CLIENTE

DISEÑO REPRESENTACIÓN

NO FORMALFORMAL

SEMIFORMAL

Describen la funcionalidad o los servicios que se espera que el sistema proveerá, sus entradas y salidas, excepciones, etc.

Ejemplos:

1.-“El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella.”

2.-“El sistema deberá ofrecer un explorador (browser) para que el usuario lea documentos en el almacén de documentos.”

Se refieren a las propiedades emergentes del

sistema como la fiabilidad, el tiempo de

respuesta, la capacidad de

almacenamiento, la capacidad de los

dispositivos de entrada/salida, y la

representación de datos que se utiliza en

las interfaces del sistema.

Ejemplos:

1.-“Será necesario que la comunicación

requerida entre el APSE y el usuario se

pueda expresar utilizando el conjunto de

caracteres estándar de ADA.”

2.-“El proceso de desarrollo del sistema y los

documentos a entregar estarán sujetos al

proceso y a los productos a entregar

definidos en XYZCo-SP-STAN-95.”

3.-“El sistema no deberá revelar a sus

operadores información personal alguna de

los clientes excepto su nombre y número

de referencia.

Ing. Sonia Godoy H

Deberían definir las acciones fundamentales que tienen que tener lugar en el software, aceptando y procesando las entradas y su procesamiento y generación de salidas

Pruebas de validez en las entradas

Secuencia exacta de operaciones

Respuestas a situaciones anormales, incluyendo: desbordamientos, facilidades de comunicación, manejo de errores y recuperación

Efecto de los parámetros

Relaciones de salidas a entradas, incluyendo secuencias de entrada/salida y fórmulas para la conversión entre entrada y salida

Puede ser apropiado partir los requisitos funcionales dentro de subfunciones o subprocesos. Esto no implica que el diseño de software tenga que ser partido de esa forma.

Son generalmente listados como sentencias del tipo “deberá”, comenzando con “El sistema deberá...”.

Ing. Sonia Godoy H

Requisitos no relacionados directamente con la funcionalidad del sistema

„Pueden estar relacionados con propiedades emergentes del sistema

Pueden describir restricciones al producto a desarrollar

„Pueden describir restricciones externas del sistema

„Definen las cualidades globales que el sistema ha de exhibir

„Suelen hacer referencia al sistema considerado de forma global

„Suelen ser requisitos más críticos que los requisitos funcionales

„Suelen ser difíciles de verificar

Ing. Sonia Godoy H

Requisitos de producto

„ Tiempo de respuesta, memoria

requerida, fiabilidad, portabilidad, usabilidad…

„ Requisitos de organización

Estándares de proceso, lenguajes de

programación, métodos de diseño, estándares de

documentación...

Requisitos externos

Interoperabilidad, éticos, legislativos,

privacidad, seguridad...

Ing. Sonia Godoy H

ANALIZA LOS SIGUIENTES REQUERIMIENTOS Y CLASIFICALOS

¿Son funcionales o no funcionales?

“Los participantes tendrán que ser mayores de edad”

“Los participantes tendrán que residir en la península”

“El valor de las pujas será mostrado en euros”

“El IVA aplicado a las pujas ganadoras será del 7%”

“La lista de resultados estará preparada para ser impresa en un folio tamaño A4”

“El sistema lanzará una excepción en caso de que un usuario quiera cargar un importe mayor que el saldo de la cuenta”

“Los accesos a la BD deberán usar el estándar SQL-92”

“Los registros de la BD no deben ocupar más de 4 Kb”

“El sistema deberá ser capaz de interactuar con 100 usuarios concurrentes”

Ing. Sonia Godoy H