Especificacin de Requisitos de Usuario segn la ESA

Las salidas de esta etapa deben ser formalmente revisadas durante la actividad de revisin de Requisitos de Usuarios (UR/R). Estn involucrados los: usuarios, clientes, administradores del proyecto, y los tsters. analistas,

Es aconsejable realizar revisiones peridicas, antes de la revisin final. Eso mejorar la calidad y la disponibilidad del producto final de la fase (URD).

Documento de Requisitos de Usuario (URD).

1. Introduccin
1.1 Propsito. Narrativa que describe el propsito del documento en
particular.

1.2 Alcance o mbito. Narrativa consistente, que identifica el producto a

ser producido, nombrndolo, explicando lo que el software har, sus beneficios, objetivos y metas precisas, establece el alcance del sistema a desarrollar.

1.3 Glosario o Definiciones. Listado de acrnimos, con su significado.

1.4 Referencias. Se colocan una lista completa de las referencias de los
documentos utilizados para construir el URD, identificadas por el ttulo, autor y fecha, identificando aquellos documentos que son aplicables o solo son referencia. rasgos, el sistema a desarrollar.

1.5 Visin general, o apreciacin global. Narrativa que describe a grandes

3

Documento de requisitos de usuarios (URD).

2. Descripcin General
2.1 Perspectivas del Producto. Narrativa que establece que es lo que se espera obtener con el producto de software en desarrollo. 2.2 Capacidades Generales. Se deben describir las capacidades principales y el porque son necesarios, asimismo se debe indicar los procesos que sern apoyados por el software 2.3 Restricciones Generales. Narrativa que establece cules son las restricciones de funcionamiento del software. 2.4 Caractersticas de los Usuarios. Narrativa que describe las caractersticas de los usuarios que afectan los requerimientos especficos.

Documento de requisitos de usuarios (URD).

2.5 Ambiente Operacional. Narrativa que establece las caractersticas del escenario de trabajo del software, el cual debe estar apoyado por un Diagrama de Contexto.

10

11

Documento de requisitos de usuarios.

3. Especificacin de Requerimientos
3.1 Requisitos de Capacidad. Listado de requisitos que especifican las
capacidades que debe poseer el software (lo que debe poder realizar el software), para satisfacer las necesidades del cliente/usuario. Estos requisitos se deben especificar segn el formato preestablecido.

a. Velocidad. El tema de la velocidad esta dada por el medio o servicio que lo otorga. b. Exactitud. Depender de la plataforma o hardware que soporte este software.

3.1 Requisitos de Calidad. Listado de requisitos de calidad del producto

de software. Estos requisitos se deben especificar segn el formato preestablecido.

12

3.1.3 Requisitos de Restricciones. Listado de requisitos que especifican

restricciones a cerca de cmo debe ser construido (se refiere a conexiones con otros sistemas, o adhesin a los estndares de la empresa) y operado el software. Estos requisitos se deben especificar segn el formato preestablecido.

13

Tabla de Atributos
NECESIDAD 1 2 1 2 3 1 2 ESTABILIDAD 3 1 2 3 1 VERIFICABILIDAD FUENTE 2 1 2 BAJA PRECISA AMBIGUA NO CLARA SI NO REQ. DE .USUARIO EQUIPO PROYECTO Cada requisito es comprobable que se incorpore en el diseo y ejecucin. Se debe comprobar que el software pone en ejecucin el requerimiento. ESCENCIAL NEGOCIABLE ALTA MEDIANA BAJA ALTA MEDIANA Requerimiento vital, importante y esencial del software no son negociables. Menos vital, importantes y conforme a negociacin Cada requisito del software incluir una medida de la prioridad del modo que el desarrollador pueda decidir un plan de fabricacin

PRIORIDAD

Algunos requisitos pueden ser estables durante la vida de software, otros pueden ser ms dependientes a partir de la fase del diseo y otros pueden estar conforme a cambios durante el ciclo de vida del software

CLARIDAD

Respecto a la interpretacin implica carencia de ambigedad. Si un trmino usado en un contexto particular tiene significados mltiples se debe sustituir por uno ms especfico.

Las referencias acompaarn cada requerimiento de software

14

Necesidad

Prioridad

Estabilidad

Claridad

Verificabilidad

Fuente

Descripcin ID

1.- Ambiente Operacional

UR

1.1

Aplicacin desarrollada sobre plataforma Windows XP.

1 1 1 1 1 1

Este requerimiento de usuario exige que el sitio del foro se desarrolle sobre una plataforma de sistema operativo Windows XP UR 2.1 Acceder a travs de un browser compatible Explorer 6.0 1 1 2 1 1 1 El acceso al sistema ya sea por parte del Administrador como de los usuarios debe ser por medio de un browser compartible con el utilitario Explorer 6.0, que se incluye en el sistema operativo Windows XP UR 3.1 Desarrollo en pgina Web. 1 1 1 1 1 1 El desarrollo debe ser bajo un ambiente Web, con el objeto de que esta pgina pueda ser visitada por cualquier usuario que tenga acceso a Internet.

15

Atributos de requisitos de usuarios:

La forma completa de especificar requisitos, es similar a la propuesta de Tom Gilb (vista en transparencias anteriores).
Por razones de background del equipo de trabajo, y de tiempo para desarrollar el proyecto, especificaremos los requisitos de la siguiente manera: Para Requisitos Funcionales y de Restriccin, especificar:
Identificador. Identifica unvocamente al requisito. Descripcin. Describe el requisito. Prioridad. Indica una prioridad. Por ej.(alta-media-baja) Usuarios. Identifica los tipos de usuario que se vern afectados por este requisito. Fuente. Referencia a la fuente de donde surgi el requisito (documento, grupo, entrevista, etc.).

1 6

Atributos de requisitos de software: Para Requisitos de Calidad relevantes, se recomienda utilizar el formato completo de especificacin. Para Requisitos de Calidad poco relevantes, se recomienda utilizar el mismo formato (simplificado) que para los Requisitos Funcionales y de Restriccin.

1 7

Las salidas de esta etapa deben ser formalmente revisadas durante la actividad de revisin de Requisitos de Usuarios (UR/R). Estn involucrados los: usuarios, clientes, analistas, administ. del proyecto, y los tsters. Es aconsejable realizar revisiones peridicas, antes de la revisin final. Eso mejorar la calidad y la disponibilidad del producto final de la fase (URD).

1 8

Documento de requisitos de usuarios.

2. Descripcin General
2.4 Suposiciones y Dependencias. Narrativa que establece (por escrito) todas aquellas suposiciones, que se han hecho (con el consentimiento del cliente/usuario), sobre alguna caracterstica del software a desarrollar. 2.5 Restricciones Generales. Narrativa que establece cules son las restricciones de funcionamiento del software. Por ej. que funcione en Windows y UNIX, que funcione en el actual ambiente operacional, etc. 2.6 Descripcin del Modelo. Diagrama + explicacin del modelo de funcionamiento global actual. Se puede utilizar DFD, diagramas de procesos, de transicin de estados, etc.
1 9

Documento de requisitos de usuarios.

3. Requisitos del Sistema
3.1 Requisitos de Usuario. Listado de requisitos que
representan la necesidad del usuario/cliente.
3.1.1 Requisitos de Capacidad. Listado de requisitos que
especifican las capacidades que debe poseer el software (lo que debe poder realizar el software), para satisfacer las necesidades del cliente/usuario. Estos requisitos se deben especificar segn el formato preestablecido. producto de software. Estos requisitos se deben especificar segn el formato preestablecido. especifican restricciones a cerca de cmo debe ser construido (se refiere a conexiones con otros sistemas, o adhesin a los estndares de la empresa) y operado el software. Estos requisitos se deben especificar segn el formato preestablecido.

3.1.2 Requisitos de Calidad. Listado de requisitos de calidad del 3.1.3 Requisitos de Restricciones. Listado de requisitos que

2 0

2 1

Los documentos URD y SRD deben ser documentos completos. Esto significa que todos los requisitos conocidos deben ser incluidos cuando son producidos. Sin embargo, es altamente probable que aparezcan nuevos requisitos despus de las aprobaciones de los documentos. Por ello, es necesario establecer al inicio del proyecto, procedimientos para manejar nuevos requisitos. Es necesario no comprometer la integridad del diseo cuando se incorporan nuevos requisitos. Dichos requisitos, si es que son aceptados tanto por el usuario como por el diseador, debiesen ser

manejados de la misma forma que los requisitos originales.

2 2

El procedimiento para incorporar un nuevo requisito de usuario es el siguiente:

Generar un nuevo manuscrito del URD. Convenir una revisin de los UR, y si el cambio es aceptado,

Repetir las fases SR, AD, y DD para incorporar el nuevo requisito y sus consecuencias.

El procedimiento para incorporar un nuevo requisito de software es similar.

2 3

Otra forma de manejar nuevos requisitos es el de instituir un Comit de Revisin de Software despus de UR/R en vez de DD/R. Otra forma es el uso de un enfoque de ciclo de vida de desarrollo evolutivo. Sin embargo, esto slo alarga la administracin de los nuevos requisitos para el release posterior al que est en preparacin, lo que puede no ser suficiente.

La calidad del trabajo hecho para las fases UR y SR puede ser medido por el nmero de requisitos que aparecen en fases posteriores.
Especial nfasis debe drsele a la aparicin de nuevos requisitos. Un nmero de apariciones importantes es un signo claro que el software muy probablemente no ser un xito.

2 4

La disponibilidad de herramientas puede ser crtica para un proyecto con cambios de requisitos frecuentes.
En proyectos donde se conviene (entre el cliente y el desarrollador) en congelar los requisitos en la fase SR, el uso de mtodos basados en papel para realizar anlisis de requisitos y especificacin de diseo pueden ser suficientes. En proyectos donde no es posible congelar los requisitos, puede ser esencial el uso de herramientas de ingeniera de software que permitan que nuevos requisitos y cambios al diseo sean asimilados rpidamente para evitar atrasos serios.
2 5

I. Sommerville, P. Sawyer. Requirements Engineering, A Good Practice

Guide.Wiley, 1999.

S. Robertson, J. Robertson. Mastering the Requirements Process. AddisonWesley, 1999.

A. Davis. Software Requirements, Revision. Prentice Hall, 1993. ESA, SOFTWARE ENGINEERING STANDARDS, ISSUE 2. Preparado por: ESA Board for Software Standardisation and Control (BSSC).

R. L. Kliem, Collecting Project Information. R. H. Deane, Linking Project Outcomes to Customer Needs.

Principles of Software Engineering Management, Tom Gilb, Addison-Wesley,

1988.

26