MTA - 4 - TP1 - M2 Requerimientos de Software PDF

Taller de proyectos 1 UPC Online
1
Indicaciones
Para el curso de Taller de Proyectos 1, es importante que revises este materiales fin
de recordar temas de cursos anteriores.
Relaciona los conceptos con los artefactos que debes producir en la primera sub
iteración de la segunda iteración de tu proyecto.
2
Logros de la sesión
Al finalizar este MTA, estarás preparado para:
• Especificar los requerimientos de software.

Los cuales deberás presentar en tu 1era. sub iteración de tu 2da. Iteración de tu
proyecto.
3
El temario es:
1. Especificación de requerimientos de software.
1.1 Especificación de requerimientos funcionales
1.2 Especificación de requerimientos no funcionales
4
En RUP (Rational Unified Process), la segunda disciplina es la de Requerimientos

Recuerdas cuales son las actividades de dicha disciplina?
5
Aquí tienes todas las actividades de la segunda disciplina de RUP

En este material veremos la actividad 1.
6
Los requerimientos del sistema se capturan en dos artefactos.

Especificación de Requerimientos de Software.
Modelo de Casos de Uso del Sistema.
En este material veremos sobre la identificación de los requerimientos de software.
7
8
Adicionalmente también se tiene que:

“La construcción del software no es el problema.”
“El verdadero problema radica en saber cuáles son los requerimientos que deben ser
construidos y los que no.”
9
10
11
12
13
A fin de poder identificar la necesidades debes tener en cuenta la trilogía de

información, personas y procesos.
En lo que corresponde a la información debes identificar:

• Las dificultades en el manejo del a información del negocio
• La ausencia de información de las actividades
• Las inconsistencias en la información que se maneja en el negocio
• Es decir todos los problemas de información que el negocio tenga.
En lo que corresponde a las personas, podrás identificar sus necesidades mediante:

• Reuniones con los usuarios y clientes.
• Solicitándoles a los interesados que completen cuestionarios
• Por aplicación de políticas, normas y restricciones de la organización
Y en lo que corresponde a los procesos, puedes identificar necesidades durante:

• Análisis y diseño de los procesos de la organización
• Modelado del negocio, que fue parte de la primera iteración de tu proyecto.
• Y el mejoramiento de los procesos.
14
Tomando como base las necesidades identificadas debes identificar los

requerimientos del sistema y realizar las siguientes actividades:
• Documentar
• Modelar
• Acordar
• Comprender
15
Necesidades vs. Requerimientos
En lo que corresponde a las necesidades que están representadas en color naranja,

se enfocan en las necesidades de información de los procesos de negocio.
Y los requerimientos vienen a ser los acuerdos entre los usuarios/clientes,

interesados y el equipo de proyecto, sobre lo que el sistema debe cumplir, varios de
ellos han sido identificados de las necesidades, lo cual se representa por la
intersección de las necesidades y requerimientos.
En este gráfico puedes apreciar que hay requerimientos y necesidades que no

pertenecen a la intersección de los mismos.
16
Entonces quedarán algunas necesidades (las que quedan de color anaranjado) que:
• Necesidades que seguirán su manera anterior de ejecución.
• La naturaleza de las necesidades no exigen automatizarlas.
• El cliente no está dispuestos a esperar el tiempo que demora la automatización.
• El cliente no tiene capacidades financieras para pagar el costo de automatizar
esas necesidades.
• El equipo de proyecto no tiene capacidad técnica para automatizar esas
necesidades
• No existen TICs para automatizar esas necesidades.
• No serán incluidas en el alcance del sistema.
17
La intersección de las necesidades vs. Los requerimientos vienen a ser:
• Necesidades que se automatizarán.

• Constituyen parte del alcance del sistema.
• Funcionalidades que están dentro de las fronteras del sistema.
• Los usuarios/clientes y el equipo del proyecto han acordado automatizar esas
necesidades.
18
Y los requerimientos que nacen de las necesidades que se muestran en la parte

inferior representan:
• Aspectos de plataforma y del entorno que deben ser considerados en el sistema.

• Aspectos que no tienen relación directa con las necesidades de los
clientes/usuarios.
• Requisitos de soporte al sistema.
• Adiciones no consideradas en las necesidades.
• Peticiones especiales de interesados clave.
• Dichos requerimientos constituyen también parte del alcance del sistema.
• Son funcionalidades que también están dentro de las fronteras del sistema.
19
20
21
Un requerimiento funcional viene a ser una descripción de lo que un sistema debe

hacer.
Este tipo de requerimiento especifica algo que el sistema debe ser capaz de realizar.
22
23
Cuando los requerimientos funcionales están orientados a operaciones y tareas, es

decir de modo estructurado.
Los requerimientos funcionales están identificados teniendo en cuenta cada

operación necesitada.
Esta manera de enunciar los requerimientos funcionales está orientada a las tareas
que realizan los objetos de tipo CLIENTE.
24
En cambio si estamos en orientado a objetos.
Los requerimientos funcionales se identifican teniendo en cuenta el objeto

involucrado.
Con esta manera de enunciar los requerimientos funcionales está orientado a los
objetos de tipo CLIENTE que realizan las operaciones o tareas.
25
26
Recuerdas los atributos de calidad de las arquitecturas de SW.
Mantenibilidad (Maintainability)
Capacidad del SW para ser reparado y mejorado de forma eficiente, de manera
rápida y a bajo costo.
Modificabilidad (Modifiability)
Capacidad del SW para ser sometido a cambios futuros.
Escalabilidad (Scalability)
Es el grado con el que se pueden ampliar la arquitectura de SW, de datos o los
requerimientos funcionales.
Portabilidad (Portability).
Capacidad del SW para ser transferido de un entorno a otro, sea la organización,
plataforma o software.
27
Los requerimientos deben ser identificados orientados a objetos para permitir

arquitecturas de SW y sistemas más escalables, modificables, mantenibles y
portables.
Las arquitecturas orientadas a objetos se adaptan mejor a los cambios en las

necesidades y los requerimientos.
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Interfaces de usuario
Describe las interfaces de usuario que serán desarrolladas en el
sistema.
Interfaces de hardware
Define cualquier interfaz de hardware que será soportada por el
software, incluyendo:
Estructura lógica.
Direcciones físicas.
Comportamiento esperado, etc.
Interfaces de software
Describe las interfaces de y otros componentes del software, tales
como:
Componentes comprados.
Componentes rehusados de otra aplicación.
Componentes que se están desarrollando fuera del alcance
del software pero con los cuales la aplicación deberá
interactuar.
Interfaces de comunicación
Describe cualquier interfaz de comunicación con otros sistemas o
dispositivos tales como redes locales, dispositivos seriales remotos y
otros similares.
42
43
44
Necesario
El requerimiento especificado debe ser necesario para el producto.
Alcanzable
Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el
dinero, el tiempo y los recursos disponibles.
El requerimiento debe ser relevante desde el punto de vista de las capacidades del
proyecto para llevarlo a cabo.
Único
Un requerimiento no debe contener otro.
Evitar dos o más cláusulas independientes.
Los requerimientos pueden cumplirse de forma diferente en el sistema.
Consistente
Un requerimiento no debe entrar en conflicto con otro.
No debe contradecir otro requerimiento.
Verificable
El requerimiento debe ser tangible.
Incluir métricas siempre que sea posible.
Escribir el requerimiento de tal manera que se pueda comprobar si fue satisfecho o
no, como un resultado “exitoso” o “no exitoso”.
45
Oración completa
Una oración representa un pensamiento o idea completa.
Contiene un sustantivo, verbo y complementos.
Contiene sujeto y predicado.
Sujeto. Identificar a la persona o sistema que se referencia.
Predicado. Identificar la acción que se realiza.
Voz activa
Voz pasiva.
El tema es el objeto de la acción denotada por el verbo.
Voz activa.
El tema es el agente de la acción denotada por el verbo.
Permite identificar explícitamente el agente de la acción
45
46
47
48
49
50
51
52
53
54
55
56
57
58

MTA - 4 - TP1 - M2 Requerimientos de Software PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

MTA - 4 - TP1 - M2 Requerimientos de Software PDF

Cargado por

Copyright:

Formatos disponibles

Taller de proyectos 1 UPC Online

• Especificar los requerimientos de software.

En RUP (Rational Unified Process), la segunda disciplina es la de Requerimientos

Aquí tienes todas las actividades de la segunda disciplina de RUP

Los requerimientos del sistema se capturan en dos artefactos.

Adicionalmente también se tiene que:

A fin de poder identificar la necesidades debes tener en cuenta la trilogía de

En lo que corresponde a la información debes identificar:

En lo que corresponde a las personas, podrás identificar sus necesidades mediante:

Y en lo que corresponde a los procesos, puedes identificar necesidades durante:

Tomando como base las necesidades identificadas debes identificar los

Necesidades vs. Requerimientos

En lo que corresponde a las necesidades que están representadas en color naranja,

Y los requerimientos vienen a ser los acuerdos entre los usuarios/clientes,

En este gráfico puedes apreciar que hay requerimientos y necesidades que no

La intersección de las necesidades vs. Los requerimientos vienen a ser:

• Necesidades que se automatizarán.

Y los requerimientos que nacen de las necesidades que se muestran en la parte

• Aspectos de plataforma y del entorno que deben ser considerados en el sistema.

Un requerimiento funcional viene a ser una descripción de lo que un sistema debe

Cuando los requerimientos funcionales están orientados a operaciones y tareas, es

Los requerimientos funcionales están identificados teniendo en cuenta cada

En cambio si estamos en orientado a objetos.

Los requerimientos funcionales se identifican teniendo en cuenta el objeto

Recuerdas los atributos de calidad de las arquitecturas de SW.

Los requerimientos deben ser identificados orientados a objetos para permitir

Las arquitecturas orientadas a objetos se adaptan mejor a los cambios en las

También podría gustarte