|
NormasSRS
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. |