Especificación y validación de requerimientos. IEEE-830 y plantillas SRS.



Es importante considerar la parte que el SRS representa en el diseño del proyecto total que se define en IEEE Std 610.12-1990. El software puede contener toda la funcionalidad del proyecto esencialmente o puede ser parte de un sistema más grande.
En el último caso habrá un SRS que declarará las interfaces entre el sistema y su software modular, y pondrá que función externa y requisitos de funcionalidad tiene con el software modular. Otras normas, relacionan a otras partes del ciclo de vida de software para que pueda complementar los requisitos del software. Desde que el SRS tiene un papel específico en el proceso de desarrollo de software, el que define el SRS debe tener el cuidado para no ir más allá de los límites de ese papel. 


Resultado de imagen para Especificación y validación de requerimientos. IEEE-830 y plantillas SRS.



Esto significa que: 

a) debe definir todos los requisitos del software correctamente.Un requisito del software puede existir debido a la naturaleza de la tarea a ser resuelta o debido a una característica especial del proyecto.

b) no debe describir cualquier plan o detalles de aplicación. Éstos deben describirse en la fase del diseño del proyecto. 
c) no debe imponer las restricciones adicionales en el software. 

Éstos se especifican propiamente en otros documentos. 2.3 Características de un buen SRS. Un SRS debe ser: 

a) Correcto; 
b) Inequívoco; 
c) Completo; 
d) Consistente; 
e) Delinear que tiene importancia y/o estabilidad; 
f) Comprobable; 
g) Modificable; 
h) Identificable. 


Un SRS es correcto si, y sólo si, cada requisito declarado se encuentra en el software. No hay ninguna herramienta o procedimiento que aseguran la exactitud. Alternativamente el cliente o el usuario pueden determinar si el SRS refleja las necesidades reales correctamente. Identificando los requerimientos hace este procedimiento más fácil y hay menos probabilidad al error. 

Inequívoco
Un SRS es inequívoco si, y sólo si, cada requisito declarado tiene sólo una interpretación. Como un mínimo, se requiere que cada característica de la última versión del producto se describa usando un único término. En casos dónde un término en un contexto particular tenga significados múltiples, el término debe ser incluido en un glosario dónde su significado es hecho más específico. Un SRS es una parte importante del proceso de requisitos del ciclo de vida de software y se usa en el diseño, aplicación, supervisión, comprobación, aprobación y pruebas como está descrito en IEEE Std 1074-1997.
El SRS debe ser inequívoco para aquéllos que lo crean y para aquéllos que lo usan. Sin embargo, estos grupos no tienen a menudo el mismo fondo y por consiguiente no tienden a describir los requisitos del software de la misma manera. 
Las Subclauses recomiendan cómo evitar la ambigüedad Trampas del idioma natural. Los requisitos son a menudo escritos en el idioma natural (por ejemplo, inglés) el idioma natural es inherentemente ambiguo. Un idioma natural que SRS podría ser revisado por una parte independiente para identificar el uso ambiguo del idioma para que pueda corregirse. 

Aprende a llenar una plantilla SRS:


Comentarios

Publicar un comentario

Entradas populares de este blog

Técnicas de recolección de requerimientos: Entrevistas, encuestas, observación y listas de verificación.

Imagen
La recolección de datos se refiere al uso de una gran diversidad de técnicas y herramientas que pueden ser utilizadas por el analista para desarrollar los sistemas de información, los cuales pueden ser la entrevistas, la encuesta, el cuestionario, la observación, el diagrama de flujo y el diccionario de datos. Todos estos instrumentos se aplicarán en un momento en particular, con la finalidad de buscar información que será útil a una investigación en común. En la presente investigación trata con detalle los pasos que se debe seguir en el proceso de recolección de datos, con las técnicas ya antes nombradas. Las 5 principales técnicas de recolección de datos son: 1. Entrevistas 2. La encuesta 3. La observación 4. Diccionario de datos  5. Diagrama de flujo ENTREVISTA   La entrevista es una conversación dirigida, con un propósito especifico y que usa un formato de preguntas y respuestas. Se establece así un diálogo, pero un diálogo peculiar, asimétrico, donde
Leer más

Metodologías de Desarrollo Tradicional

Imagen
Teniendo en cuenta la filosofía de desarrollo de las metodologías, aquellas con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales. Esta metodología  impone una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar. Las metodologías tradi
Leer más

Tipos de arquitecturas: SOA, Micro servicios, cliente - servidor, monolítica, distribuido, capas.

Imagen
Arquitectura SOA La Arquitectura Orientada a Servicios (SOA en inglés), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a ciertos requisitos del negocio. Esta arquitectura permite crear sistemas altamente escalables, que pueden ayudar a las organizaciones a impulsar el rendimiento y, al mismo tiempo, reducir costos de TI y mejorar la flexibilidad en los procesos del negocio. SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y da soporte a las actividades de integración y consolidación de los datos de cualquier organización. Iniciativas: Servicios de datos escalables y flexibles. Servicios de infraestructura para la autentificación, el control de acceso y el registro. Servicios CRUD para crear, leer y actualizar datos de todas las formas de sistemas back-end, incluidos datos estructurados, no estructurados, semi-estructurados, de mainframe y en la nube.
Leer más