Estudio de Viabilidad del Sistema - UC3Mocw.uc3m.es/cursos-archivados/ingneieria-del-software... ·...
Transcript of Estudio de Viabilidad del Sistema - UC3Mocw.uc3m.es/cursos-archivados/ingneieria-del-software... ·...
-
Estudio de Viabilidad del Sistema
1
-
1. Descripción y objetivos
Objetivo:el análisis de un conjunto concreto de necesidadesel análisis de un conjunto concreto de necesidadespara proponer una solución a corto plazo, quetenga en cuenta restricciones económicas,g ,técnicas, legales y operativas.
Se identifican los requisitos que se ha deq qsatisfacerSe estudia la situación actualSe estudia la situación actual.Se identifican alternativas de soluciónS l li d llSe valoran y se elige una de ellas
2
-
1. Descripción y objetivosActividades en el EVS
3
-
2. EVS 1.ACTIVIDAD EVS 1: ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA
4
-
3. EVS 3.ACTIVIDAD EVS 3: DEFINICIÓN DE REQUISITOS DELSISTEMA
5
-
3. EVS 3.Requisitos:
Identificación: cada requisito software incluirá una identificaciónpara facilitar su traza por las fases subsiguientes.p p gNecesidad: los requisitos esenciales de software se marcarán comotales. Los requisitos esenciales no son negociables. El resto puedenestar sujetos a negociación.P i id d d i it d ft i l i á did d lPrioridad: cada requisito de software incluirá una medida de laprioridad para que el desarrollador pueda decidir la planificación dela producción.Estabilidad: algunos requisitos se pueden saber fijos sobre la vidag q p jesperada del software, mientras que otros pueden depender de lasdecisiones de diseño o implementación que se tomen durante eldesarrollo.Fuente: Origen del requisitoFuente: Origen del requisito.Descripción: descripción del requisito. Puede ser textual oacompañarse de diagramas y prototipos. La descripción debe ser⌂ Clara: un requisito es claro si tiene una y sólo una interpretación. Si un
é i ili d i i úl i l i itérmino utilizado en cierto contexto tiene múltiples interpretaciones, sedebe aclarar su significado o debe ser reemplazado con un término másespecífico.
⌂ Verificable: debe ser posible que se pueda verificar que el requisito haid i d l di ñ d d t l ft
6
sido incorporado en el diseño y que se pueda demostrar que el softwareaplicar el requisito.
-
3. EVS 3.
Identificador
Prioridad: Alta Media Baja Fuente: Cliente Desarrollador.Prioridad: Alta Media Baja Fuente: Cliente Desarrollador.
Necesidad: Esencial Deseable Opcional
Claridad: Alta Media Baja Verificabilidad: Alta Media BajaClaridad: Alta Media Baja Verificabilidad: Alta Media Baja
Estabilidad:
Descripción:
7
-
3. EVS 3.
UR 1.2 REQUISITO DE CAPACIDAD (Funcional)
El primer paso para la creación de un blog será rellenar un
Descripción
formulario con los siguientes campos:-Nombre de Usuario-Nick del bloggerC t ñp -Contraseña
-Cuenta de correo electrónicoLa aplicación comprobará que todos los campos han sido rellenados correctamentecorrectamente
Estabilidad Estable Necesidad Esencial Prioridad Alta
Verificabilidad Alta Claridad Alta Fuente Cliente
8
-
3. EVS 3.Tipos:
Requisitos de Usuario (EVS)⌂ Requisitos de capacidad: especifican la funcionalidad que el cliente desea que tenga
i P i ió l d li i lsu sistema. Para concretar con mayor precisión el producto a realizar, se incluyenlos requisitos inversos, que especifican la funcionalidad que no debe tener elsistema.
⌂ Requisitos de restricción: especifican la forma en que el sistema debe alcanzar losobjetivos o realizar las funcionalidades.j
Requisitos del Sistema (ASI)⌂ Requisitos funcionales⌂ Requisitos de rendimiento⌂ Requisitos de Interfaz⌂ Requisitos de Interfaz⌂ Requisitos de Operación⌂ Requisitos de recursos⌂ Requisitos de verificación⌂ Requisitos de pruebas de aceptación⌂ Requisitos de pruebas de aceptación⌂ Requisitos de documentación⌂ Requisitos de seguridad⌂ Requisitos de calidad⌂ Requisitos de daño⌂ Requisitos de daño⌂ Requisitos de mantenibilidad⌂ Requisitos de recuperación entre fallos.
9
-
10