Ingenieria Requerimientos Sesion 6

Universidad
Universidad PeruanaPeruana de Ciencias

de Ciencias Aplicadas
Aplicadas
Ingeniería de requerimientos
Requerimientos del software

© Todos los derechos de propiedad intelectual de esta obra pertenecen en exclusiva a

la Universidad Peruana de Ciencias Aplicadas. Queda terminantemente prohibida la
reproducción, puesta a disposición del público y en general cualquier otra forma de
explotación de toda o parte de la misma. La utilización no autorizada de esta obra, así
como los perjuicios ocasionados en los derechos de propiedad intelectual e industrial
de la Universidad Peruana de Ciencias Aplicadas., darán lugar al ejercicio de las
acciones que legalmente le correspondan y, en su caso, a las responsabilidades que de
dicho ejercicio se deriven.
2
© Universidad Peruana de Ciencias Aplicadas
Índice del tema
Introducción al curso ..................................................................................................................... 4

Logros de aprendizaje ................................................................................................................... 5
¿Cómo son interpretados los requerimientos? ............................................................................. 6
Interpretaciones del requerimiento ............................................................................................ 6
¿Qué es un requerimiento?........................................................................................................... 7
Necesidades versus Requerimientos ............................................................................................ 7
Deseos y Necesidades .................................................................................................................. 8
Zona Intermedia ............................................................................................................................ 8
Requerimientos ............................................................................................................................. 8
Disciplina de requerimientos ......................................................................................................... 9
Objetivos de los requerimientos .............................................................................................. 10
Requerimientos: Workflow ...................................................................................................... 10
Requerimientos: Artefactos ..................................................................................................... 11
Identificar Requerimientos del sistema ....................................................................................... 12
Repercusión en la arquitectura del sistema ............................................................................ 13
Pregunta .................................................................................................................................. 13
Requerimientos no funcionales ............................................................................................... 14
Usabilidad .......................................................................................................................................... 14
Confiabilidad ...................................................................................................................................... 14
Rendimiento ....................................................................................................................................... 15
Soporte............................................................................................................................................... 15
Restricciones de diseño ..................................................................................................................... 16
Documentación en línea del usuario y sistema de ayuda .................................................................. 16
Componentes Adquiridos ................................................................................................................... 16
Interfaces ........................................................................................................................................... 16
Licenciamiento ................................................................................................................................... 16
Aspectos legales, derecho de autor y otros ....................................................................................... 16
Normas aplicables .............................................................................................................................. 17
Principios para especificar requerimientos ................................................................................. 17
Necesario ................................................................................................................................ 17
Alcanzable ............................................................................................................................... 17
Medible .................................................................................................................................... 17
Verificable ................................................................................................................................ 17
Único ....................................................................................................................................... 18
Consistente.............................................................................................................................. 18
Conclusiones ............................................................................................................................... 18
Bibliografía................................................................................................................................... 19
3
Introducción al curso
El avance en el desarrollo de software conjugado con una sociedad cada

vez más tecnificada, lleva al profesional en Ingeniería de Sistemas a la
necesidad de conocer, dominar y aplicar las mejores prácticas para el
análisis de las necesidades de información de las organizaciones y la
recopilación de los requerimientos del software.
En el curso Ingeniería de Requerimientos se imparten los conocimientos

necesarios para aplicar nuevos métodos, técnicas y herramientas en la
gestión de los deseos, necesidades y expectativas de los clientes y
convertirlas en requerimientos funcionales y no funcionales, acordados con
los interesados involucrados y a ser satisfechos a través de un sistema
informático.
Las competencias generales de la carrera Ingeniería de Sistemas

que se desarrollan en el curso son:
- Diseño de sistemas y procesos. Habilidad para diseñar sistemas,
componentes o procesos en base a necesidades y considerando
restricciones económicas, sociales, políticas, éticas, de salud, seguridad,
medio ambiente, de manufactura y sostenibilidad.
- Trabajo en equipo. Habilidad para formar equipos multidisciplinarios.
- Comunicación. Habilidad para comunicarse eficientemente en forma oral,
escrita con informes o artefactos en sistemas de información.
4
Logros de aprendizaje
Al término de la sesión, el alumno diseña un modelado de negocio desde la descripción

de la organización hasta la realización de los casos de usos de negocio.
5
¿Cómo son interpretados los requerimientos?

Empecemos por ver cómo son interpretados los requerimientos. Para entenderlo mejor
vamos a seguir este ejemplo: Un cliente nos ha pedido algo para balancearse bajo un
árbol.
En la imagen de la derecha vemos como debería ser el resultado de lo que el cliente nos
explicó. Ahora veremos cómo de un mismo requerimiento se pueden sacar diferentes
interpretaciones y resultados.
Interpretaciones del requerimiento

Como se muestra en las imágenes, podemos obtener 8 resultados distintos y que
ninguno sea lo que el cliente esperaba.
Por ello, es importante que recordemos que:

 La parte más difícil de construir un sistema de software es decidir qué construir.
 Ninguna otra tarea afecta tanto negativamente al sistema, al final, si se realiza
de manera incorrecta, al inicio.
 La construcción del sistema no es el problema. El verdadero problema radica en
saber cuáles son los requerimientos que deben ser construidos y los que no.
6
¿Qué es un requerimiento?
Según Merlin Dorfman y Richard H. Thayer, un requerimiento es “Es la capacidad de
software necesitada por el usuario para resolver un problema y, por tanto, lograr un
objetivo.”
Por otro lado, Suzzane Robertson lo define como “algo que el sistema debe hacer o
cualidad que debe tener. Los requerimientos existen porque el producto en
construcción exige cierta funcionalidad o porque el usuario quiere que el producto
cumpla con ciertas condiciones”.
El Instituto de Ingeniería Eléctrica y Electrónica da tres definiciones de requerimiento:
 Condición o capacidad que un usuario necesita para resolver un problema o
lograr un objetivo.
 Condición o capacidad que debe tener un sistema o un componente de un
sistema para satisfacer un contrato, una norma, una especificación u otro
documento formal.
 Una representación en forma de documento de una condición o capacidad como
las expresadas en (a) o en (b).
Por tanto, nuestra definición es que “Un requerimiento es una condición o una
capacidad a la cual el sistema debe ajustarse”.
Los requerimientos deben ser:
 Acordados. Hay que establecer y mantener acuerdos entre el proyecto y los
interesados, y comprometer formalmente la construcción de los requerimientos.
 Comprendidos. Tenemos que proveer al equipo de proyecto un mejor
entendimiento del requerimiento para permitir al cliente verificar la satisfacción
al final del proyecto.
 Documentados. Se deben especificar de forma semántica y textual, con nivel de
detalle suficiente. Esto servirá para mantener una evidencia de los compromisos
adquiridos.
 Modelados. Hay que representarlos gráficamente usando un lenguaje de
modelado y hablar el mismo idioma entre los diferentes profesionales del
proyecto.
Necesidades versus Requerimientos

A continuación vamos a ver las diferencias entre los deseos/necesidades y los
requerimientos.
Los deseos y las necesidades se enfocan en peticiones especiales y en los problemas de
información del negocio. Y, los requerimientos son los acuerdos entre los
usuarios/clientes interesados y el equipo de proyecto, sobre lo que el sistema debe
cumplir. Vamos a ampliar esta información.
7
Deseos y Necesidades
En la primera zona encontramos los deseos y las necesidades del cliente. Su naturaleza
no exige automatizar esas necesidades y los interesados no están dispuestos a esperar
el tiempo que demora la automatización ni a pagar el costo que supone. Además, el
equipo de proyecto no puede garantizar la automatización de todas esas necesidades ni
existen TICs para ello. Por tanto, no todas serán incluidas en el alcance del sistema.
Zona Intermedia
Entremedias de los deseos/necesidades y los requerimientos encontramos una zona
donde se encuentran aquellas necesidades que constituyen parte del alcance del
sistema y que los usuarios/clientes y el equipo han acordado que serán automatizadas
ya que, las funcionalidades están dentro de las fronteras del sistema.
Requerimientos
En el otro lado se encuentran los requerimientos, que es la zona dónde se analizan los
aspectos de la plataforma y el entorno que deben ser considerados en el sistema y
aquellos que no tienen relación directa con las necesidades de los clientes/usuarios.
Aquí también se tiene en cuenta los requisitos de soporte al sistema.
También se pueden añadir otros aspectos no considerados en las necesidades y/o
peticiones especiales de interesados clave.
Los requerimientos también constituyen parte del alcance del sistema y de las
funcionalidades que se encuentran dentro de éste.
Pregunta 1
Por tanto, ¿el alcance del sistema será automatizar todos los deseos y necesidades de
los clientes y usuarios? No, los deseos y necesidades que el sistema automatizará serán
solo los acordados junto al equipo del proyecto.
Algunos deseos y necesidades pueden quedar fuera del alcance del sistema.
8
Pregunta 2
¿El sistema solo debe automatizar los requerimientos acordados? Sí, los únicos aspectos
a automatizar en un sistema serán aquellos acordados entre los interesados y el equipo
del proyecto. El sistema puede automatizar aspectos adicionales a los deseos y las
necesidades como compromisos sobre la plataforma y el entorno del sistema.
Pregunta 3
¿Una necesidad y un requerimiento es lo mismo? No, ambos están relacionados. Las
necesidades deben ser tomadas en cuenta para identificar los requerimientos del
sistema.
Disciplina de requerimientos
En este apartado vamos a tratar la disciplina de requerimientos, centrándonos en
el Proceso Unificado de Rational (RUP), el cual constituye la metodología estándar más
utilizada para el análisis, diseño, implementación y documentación de sistemas
orientados a objetos. Esta metodología es la que se usa a la hora de realizar un proyecto.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y a las necesidades.
En la gráfica podemos ver el ciclo de vida del RUP, que organiza las tareas en fases e
interacciones.
El proceso se divide en cuatro fases (inicio, elaboración, construcción y transición),
dentro de las cuales se realizan varias iteraciones que dependerán de las necesidades
del proyecto y en las que se hace un mayor o menor hincapié en las distintas disciplinas.
Estas disciplinas son:
 Modelado del negocio
 Análisis de requisitos
 Análisis y diseño
 Implementación
 Test
 Distribución
 Gestión de configuración y cambios
 Gestión del proyecto
 Gestión del entorno
9
Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo
de la fase el esfuerzo dedicado a una disciplina varía. Por ejemplo, en la primera fase
(inicio) las interacciones se enfocan hacia el modelado del negocio, el análisis de
requisitos, la gestión del proyecto y la gestión del entorno.
Este proceso ayudará a definir y gestionar los requerimientos para que se desarrollen
de la manera más eficaz posible.
Objetivos de los requerimientos

Gracias a este proceso, los requerimientos acordados podrán cumplir sus objetivos que
son:
 Establecer y mantener un acuerdo formal con los clientes y usuarios finales sobre
lo que el sistema debe hacer.
 Proporcionar a los desarrolladores del proyecto un mejor entendimiento de los
requerimientos del sistema.
 Definir las fronteras del sistema.
 Proporcionar las bases para la planificación del contenido técnico de las
iteraciones.
 Proporcionar las bases para estimar los costos y el tiempo para el desarrollo del
sistema.
 Definir la interfaz gráfica del sistema centrada en las necesidades y metas de los
usuarios.
Requerimientos: Workflow
Vamos a centrarnos en las actividades del Proceso Unificado de Rational y para ello,
utilizaremos el workflow (flujo de trabajo).
El flujo de trabajo es el estudio de los aspectos operacionales de una actividad de
trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo,
cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace
10
seguimiento al cumplimiento de las tareas. Es decir, es una secuencia de actividades que

produce un resultado de valor observable.
La mayor parte del trabajo de éste Workflow ocurre justo al principio del ciclo de vida
del proyecto (fases de inicio y elaboración).
Por cada flujo de trabajo también se presenta una visión general de actividad. La visión
general de actividades muestra todas las actividades en el flujo de trabajo junto con el
trabajador que realiza la actividad.
Requerimientos: Artefactos
Aquí se presenta un diagrama general artefacto. Un artefacto es, en su definición más
básica, un subproducto de un proceso de desarrollo.
Este diagrama muestra todos los artefactos y los trabajadores involucrados en el flujo
de trabajo.
11
Identificar Requerimientos del sistema

Los requerimientos del sistema se pueden clasificar en funcionales y no funcionales.
Los requerimientos funcionales dan una descripción de lo que el sistema debe realizar.
Nombran las condiciones que el sistema debe realizar sin tener en cuenta restricciones
físicas. También incorporan los acuerdos con el cliente y los interesados.
Y los requerimientos no funcionales se centrar en los atributos del sistema, en las
características de la plataforma, el entorno y el ambiente. Además, presentan la
compatibilidad con otros sistemas y aplicables al sistema. También recogen los acuerdos
con el cliente y los interesados.
Dentro de los requerimientos funcionales podemos encontrar dos tipos:

Los orientados a las operaciones y tareas que acuerden que el sistema debe realizar.
Cuyas funciones son:
− Agregar información de los clientes.
− Modificar información de los clientes.
− Eliminar información de los clientes.
− Consultar información de los clientes.
− Imprimir información de los clientes.
Esta manera de enunciar los requerimientos funcionales está orientada a las tareas que
realizan los objetos de tipo CLIENTE. Los requerimientos funcionales están identificados
teniendo en cuentan cada operación necesitada
Y el otro tipo son los orientados a objetos de información que contengan las operaciones
o tareas que se acuerde que el sistema debe realizar. Que tienen por función actualizar
la información de los clientes.
12
Esta manera de enunciar los requerimientos funcionales está orientada a los objetos de
tipo CLIENTE que realizan las operaciones o tareas. Los requerimientos funcionales se
identifican teniendo en cuenta el objeto involucrado.
Repercusión en la arquitectura del sistema

Los requerimientos funcionales generan una serie de características en la arquitectura
del sistema que son:
 Mantenibilidad (Maintainability)
Capacidad del software para ser reparado y mejorado de forma eficiente, de
manera rápida y a bajo costo.
 Modificabilidad (Modifiability)
Capacidad del software para ser sometido a cambios futuros.
 Escalabilidad (Scalability)
Es el grado con el que se pueden ampliar la arquitectura de software, de datos o
los requerimientos funcionales.
 Portabilidad (Portability).
Capacidad del software para ser transferido de un entorno a otro, sea la
organización, platahardware o software.
Pregunta
Ahora que ya hemos visto ambos tipos nos preguntamos ¿cuál de las dos maneras de
identificar los requerimientos funcionales es mejor?
Los sistemas orientados a objetos permiten arquitecturas más escalables, modificables,
mantenibles y portables que los estructurados u orientados a operaciones.
13
Las arquitecturas orientadas a objetos se adaptan mejor a los cambios en las

necesidades y los requerimientos.
Por tanto, los requerimientos deben ser identificados orientados a objetos para permitir
arquitecturas de software y sistemas más escalables, modificables, mantenibles y
portables.
Requerimientos no funcionales
Existen 11 tipos de requerimientos no funcionales. Vamos a verlos.
Usabilidad
Es el tiempo de entrenamiento requerido, tanto para los usuarios potenciales como para
los normales, para ser productivos ante operaciones particulares. Tiempo aceptable
para realizar tareas típicas. Se puede tomar como base la capacidad de uso de otros
sistemas que los usuarios gustan y conocen. Estos requerimientos se establecen de
manera que estén conformes con estándares comunes como los CUA de IBM o los GUI
de Microsoft. Ejemplo:
 El sistema debe permitir al asistente de biblioteca registrar el préstamo de un
libro como promedio en 30 segundos.
 El aspecto de la interfaz gráfica y el lenguaje utilizado en el sistema debe estar
orientado a niños entre 3 y 5 años.
 El diseño de la interfaz gráfica del sistema debe alinearse al estándar AB-45
definido en la empresa para las aplicaciones Web.
Confiabilidad
Que se divide en:
 Disponibilidad: porcentaje de tiempo en que el sistema está disponible, horas de
uso, operaciones de tiempo degradado y otras más.
 Tiempo promedio entre falla (Mean Time Between Failures-MTBF): Se especifica
normalmente en horas, días, meses o años.
 Duración promedio de reparaciones (Mean Time To Repair-MTTR): ¿Cuánto
tiempo se permite el sistema fuera de operación después de que ha fallado?
 Exactitud: Especifica precisión (resolución) y fidelidad (sobre la base de un
estándar conocido) de que algo es realmente requerido por el sistema.
 Máximo número de errores o ratio de defectos (Maximum Bugs or Defect Rate):
Usualmente expresado en términos de errores por miles de líneas de código
(bugs/KLOC) o errores por punto de función (bugs/function-point).
 Ratio de errores o defectos (Bugs or Defect Rate): Clasificado en términos de
error “menor”, “significativo” y “crítico”. El(los) requerimiento(s) deben definir
qué significa error crítico. Ejemplo: Pérdida de los datos completa o
inhabilitación para usar ciertas partes de la funcionalidad del sistema.
Unos ejemplos de confiabilidad son:
 El sistema debe estar disponible 24x7x52 días al año.
 El tiempo promedio entre fallas (MTBF) del sistema será de 30 días
14
 La duración promedio de una reparación (MTTR) del sistema no debe ser mayor
de 20 minutos.
 El sistema estará disponible al 95 por ciento entre las 8:00 AM y las 6:00 PM.
 El sistema cumplirá los procedimientos definidos en el reglamento de la
Institución GA-2006JX.
Rendimiento
Formado por:
 Tiempo de respuesta para una transacción: como promedio, como máximo.
 Rendimiento de procesamiento. Por ejemplo, transacciones por segundo.
 Capacidad. Por ejemplo, el número de clientes o transacciones que el sistema
puede alojar.
 Modos de degradación. Cuál es el modo aceptable de operación cuando el
sistema se ha visto degradado de cierta manera.
 Utilización óptima de recursos. Tales como memoria, espacio en disco,
comunicaciones y otros más.
Ejemplos de este requerimiento son:
 Durante el proceso de matrícula el sistema debe permitir el acceso concurrente
de 100 estudiantes como promedio.
 El sistema debe permitir almacenar la información de hasta 50000 libros y 40000
archivos.
 El tiempo máximo de carga de las páginas del sistema es de 8 segundos.
 El 95 por ciento de las transacciones del sistema no deben exceder los 5
segundos.
 El sistema debe soportar un promedio de 50 transacciones por minuto.
Soporte
Se refiere a cualquier requerimiento que puede mejorar el soporte y la continuidad del
sistema que se está desarrollando, tales como:
 Estándares de codificación.
 Convenciones de nombres.
 Librerías de clases.
 Acceso al mantenimiento.
 Utilidades de mantenimiento.
Ejemplos de soporte:
 El cliente Web del sistema debe soportar los siguientes navegadores: Microsoft
Internet Explorer 6.0 o superior y FireFox 1.5 o superior para Linux y para
Windows
 El sistema debe ser compatible con Windows 2000 profesional y Windows XP.
 El sistema debe permitir a un usuario su instalación sin entrenamiento previo.
15
Restricciones de diseño
Indica cualquier restricción de diseño para el sistema en construcción. Representan
decisiones de diseño que han sido establecidas y con las cuales el sistema debe
alinearse. Los ejemplos incluyen, lenguajes de programación, requerimientos de
procesamiento, uso de herramientas de desarrollo prescritas, restricciones de la
arquitectura, componentes comprados, etc.
Documentación en línea del usuario y sistema de ayuda
Describe los requerimientos relacionados con la documentación de usuarios puesta en
línea, sistemas de ayuda, ayudas en base a avisos y otros tópicos relacionados .
Componentes Adquiridos
Describe cualquier componente comprado que será usado con el sistema, cualquier
clase de licencia y restricción de uso y cualquier estándar asociado de compatibilidad,
interoperabilidad e interfaz.
Interfaces
Define las interfaces que deben ser soportadas por la aplicación. Debe contener
especificaciones claras, protocolos, puertos y direcciones lógicas de forma tal que el
software pueda ser desarrollado y verificado a través de estos requerimientos. Se
clasifican en:
 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 y 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.
Licenciamiento
Define cualquier tipo de licencia o regulación legal o algún tipo de restricción acerca del
uso integral del software que deberá exhibirse en la instalación y uso del software.
Aspectos legales, derecho de autor y otros
Describe cualquier requerimiento necesario, como:
 Descargos legales.
 Garantías.
 Avisos de derecho de uso (copyright).
 Avisos de patente.
16
 Marca de palabra, marca comercial o procedimientos para autorizar el uso de un

logo para el software.
Normas aplicables
Describe, por referencia, cualquier estándar aplicable y las secciones específicas que
aplicarán al sistema descrito. Por ejemplo, esto puede incluir estándares legales, de
calidad y regulaciones, normas de la industria, interoperabilidad, internacionalización,
reglas del sistema operativo y otros.
Principios para especificar requerimientos

Antes de terminar, vamos a exponer los principios que deben cumplir los requerimientos
para poder ser especificados. Vamos a verlos uno por uno.
Necesario
El requerimiento especificado debe ser necesario para el producto. Para ello, tenemos
que preguntarnos si el requerimiento es más una característica o una función deseada.
Alcanzable
El requerimiento debe ser realista, posible de ser alcanzado con los recursos disponibles
en el proyecto: dinero, tiempo, personas, etc. También debe ser relevante desde el
punto de vista de las capacidades del proyecto para llevarlo a cabo. Las preguntas claves
son: ¿Es técnicamente viable? ¿Está dentro del presupuesto? ¿Está dentro del
cronograma? El requerimiento estaría mal especificado si explica que el equipo del
proyecto no cuenta con los recursos técnicos para desarrollar dicho requerimiento. Para
estar bien especificado tendría que decir que el sistema permitirá evitar la alerta de fin
de inspección a los revisores fuera del área de cobertura.
Medible
El requerimiento debe ser tangible. Tiene que incluir métricas y medidas en su
enunciado. Tenemos que preguntarnos: ¿Se puede definir algún valor para su medición?
El requerimiento estaría mal especificado si decimos que el Sistema emitirá el informe
de ventas lo más rápido posible. Para estar bien especificado tiene que decir que el
Sistema emitirá el informe de ventas en máximo 10 segundos.
Otro ejemplo de mal especificado es decir que el sistema tendrá una interfaz fácil y
amigable para el usuario, lo correcto es que la interfaz de usuario cumplirá con la norma
GUI XRS-45 de la organización. Y el último ejemplo es que decir que el sistema estará
disponible en el horario laboral no daría la característica de medible, tiene que decir que
el sistema estará disponible al 95% entre las 8:00 AM y las 6:00 PM, de lunes a viernes.
Verificable
El proyecto cuenta con medios, técnicas y herramientas para comprobarlo. El resultado
se puede comprobar “satisfecho o no”, “exitoso o no”. Para ver ese principio tenemos
que preguntar: ¿existe un medio por el cuál puede comprobar su logro?
17
Único
Un requerimiento no debe contener otro. Hay que evitar dos o más cláusulas porque
pueden cumplirse de forma diferente en el proyecto. Las preguntas claves son: ¿Hay un
solo pensamiento por cada requerimiento establecido? ¿Las palabras no son ambiguas?
Ejemplos de mal y bien especificado:
 Mal especificado: el usuario introducirá un PIN para aceptar el cambio de forma
de pago por lo que el sistema debe ser accesible desde una plataforma web. Lo
correcto es: El usuario introducirá un PIN para aceptar el cambio de forma de
pago. El sistema debe ser accesible desde una plataforma web.
 Mal especificado: El sistema debe soportar un promedio de 50 transacciones por
minuto y el 95% de las transacciones no deben exceder los 5 segundos. Bien
especificado: El sistema debe soportar un promedio de 50 transacciones por
minuto. El 95% de las transacciones del sistema no deben exceder los 5
segundos.
Consistente
Un requisito no debe entrar en conflicto con otro, no debe contradecir otro requisito.
Ejemplos de mal y bien especificado:
 Mal especificado: La aplicación soportará 1000 usuarios concurrentes. Bien
especificado: La aplicación soportará 250 usuarios concurrentes.
 Mal especificado: El tiempo máximo de respuesta de cualquier proceso del
sistema es de 8 segundos. Bien especificado: El tiempo mínimo de respuesta de
cualquier proceso del sistema es de 8 segundos.
Conclusiones
Para terminar esta sesión sobre requerimientos del software, vamos a recordar dos
ideas claves:
• La identificación de los requerimientos funcionales llevará a la proyección de las
funciones del sistema.
• La descripción de los requerimientos no funcionales facilitarán la construcción
de la plataforma del sistema.
18
Bibliografía
 BOOCH, Grady (1999) The unified modeling language: user

guide. Reading, MA : Addison-Wesley (005.117 BOOC/U)
 Jacobson, Ivar (2000) El proceso unificado de desarrollo de software / 005.1068
JACO Madrid: Pearson Educación, 2000.
 BRUEGGE, Bernd (2002) Ingeniería de software orientado a

objetos. México, D.F.: Pearson Educación (005.117 BRUE)
 IBM (2009)Rational Software 21 de abril de 2009 (http://www-
01.ibm.com/software/rational/)
 OMG (2009) Sitio web de Object Management Group 21 de abril de
2009 (http://www.omg.org/)
 PRESSMAN, Roger S. (2005) Ingeniería de software: un enfoque
práctico. México, D.F. : McGraw-Hill
19

Ingenieria Requerimientos Sesion 6

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

Ingenieria Requerimientos Sesion 6

Cargado por

Copyright:

Formatos disponibles

Universidad

Universidad PeruanaPeruana de Ciencias

Requerimientos del software

© Todos los derechos de propiedad intelectual de esta obra pertenecen en exclusiva a

Índice del tema

Introducción al curso ..................................................................................................................... 4

El avance en el desarrollo de software conjugado con una sociedad cada

En el curso Ingeniería de Requerimientos se imparten los conocimientos

Las competencias generales de la carrera Ingeniería de Sistemas

Al término de la sesión, el alumno diseña un modelado de negocio desde la descripción

¿Cómo son interpretados los requerimientos?

Interpretaciones del requerimiento

Por ello, es importante que recordemos que:

Necesidades versus Requerimientos

Objetivos de los requerimientos

seguimiento al cumplimiento de las tareas. Es decir, es una secuencia de actividades que

Identificar Requerimientos del sistema

Dentro de los requerimientos funcionales podemos encontrar dos tipos:

Repercusión en la arquitectura del sistema

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

 Marca de palabra, marca comercial o procedimientos para autorizar el uso de un

Principios para especificar requerimientos

 BOOCH, Grady (1999) The unified modeling language: user

 BRUEGGE, Bernd (2002) Ingeniería de software orientado a

También podría gustarte