My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
NormasSRS  
Updated Dec 21, 2011 by replymusic@gmail.com

1.- No usar literatura. Debe ser específica. Ejemplo:

"El propósito de este documento de requisitos es plasmar detalladamente y sin ambigüedades las funciones y restricciones que presentará el producto. De tal forma que quede argumentado de forma escrita y para todo el ámbito al que se dirige; tanto el cliente y los usuarios, como los desarrolladores de la aplicación. Incluyendo las características de una buena ERS (indicadas en el IEEE). Estas características son: • Corrección • No ambigua • Completa • Verificable • Consistente • Clasificada • Modificable • Explorable • Utilizable durante las tareas de mantenimiento y uso

El documento está organizado de una manera tal, que en cada parte de éste el lenguaje presentado muestre de manera concisa el objetivo del mismo y cuya comprensión sea el elemento primordial para el público. "

puede quedar simplemente como:

"El propósito de este documento de requisitos es plasmar detalladamente y sin ambigüedades las funciones y restricciones que presentará el producto, de tal forma que quede argumentado de forma escrita y para todo el ámbito al que se dirige, tanto el cliente y los usuarios, como los desarrolladores de la aplicación."

2.- Usar sólo una abreviatura. Ejemplo:

ERS - SRS, usamos sólo una de ellas.

3.- Cuidar la redacción y puntación

4.- Referencias: Cuando se incluye una referencia hay que ser más concreto. Ejemplo:

IEEE Std 830 1998(R2009). debe ser:

Estándar de blablabla, autor, título, referencia. Si se incluye un link debe tener la fecha en la que se ha incluido (para evitar links muertos)

5.- Restricciones(2.4): no hay que profundizar mucho a nuestro nivel. Restricciones típicas son que estamos sujetos a la Ley de Protección de datos y el idioma (español)

6.- Sencillez en los requisitos: nuestra red social es sencilla. Debe tener las funcionalidades básicas. Nada de juegos, aplicaciones, etc etc

7.- Características del usuario(2.3): no podemos asumir que todos los usuarios son usuarios avanzados de las redes sociales.

8.- Requisitos futuros (2.6): principalmente es que en un futuro la red abrirá el acceso a usuarios que no son de la UCM.

9.- Interfaces externas (3.1): el personal de administración y docente están en bases de datos distintas. Se trata de nombrar esas interfaces sin entrar en mucho detalle y que nuestro sistema se conectará vía web a ellos.

10.- Requisitos de rendimiento (3.3). Usuarios concurrentes. No disponemos de datos así que simplemente lo obvio, que puede haber muchos usuarios conectados.

11.- Requisitos lógicos de la base de datos (3.4): Hay que fijarse en el caso de J.A. Roberts de cómo las bases de datos se interconectan.

12.- Disponibilidad (3.6.2): Un buen ejemplo sería: "El sistema debe estar disponible las 24 horas del día.". Si el sistema debe someterse a revisión especificar en qué momento se haría (por la noche, en vacaciones, etc)

13.- Portabilidad (3.6.5): se refiere a si fuese necesario la migración del sistema. Qué grado de portabilidad tiene.

Powered by Google Project Hosting