Fases del ciclo de

vida del software

Análisis y Diseño de Sistemas

Ciclo de vida clásico
 Ingeniería y análisis del
sistema
 Definición del problema y establecimiento del proyecto de
desarrollo

 Análisis de dominio: Es la identificación, el análisis y la

especificación de requisitos comunes de un dominio
especifico de aplicación, para que de manera típica,
puedan reutilizarlo en múltiples proyectos dentro de ese
dominio de aplicación.
El análisis de dominio tiene como meta el encontrar o crear
aquellas clases de análisis o funciones y características
comunes que se aplican ampliamente para que puedan
reutilizarse.  
 En la ingeniería de sistemas, un
requerimiento o requisito es una necesidad
documentada sobre el contenido, forma o
funcionalidad de un producto o servicio.
Establecen QUÉ debe hacer el sistema, pero
NO CÓMO hacerlo.
Análisis de los
requerimientos
 Visión profunda del problema desde el punto de vista
de todos los interesados en el sistema (Stakeholders)

 En esta fase se analizan las necesidades de los

usuarios finales del software para determinar qué
objetivos debe cubrir.

 Es importante señalar que en esta etapa se debe

consensuar todo lo que se requiere del sistema y será
aquello lo que seguirá en las siguientes etapas, no
pudiéndose requerir nuevos resultados a mitad del
proceso de elaboración del software.
Análisis de los requerimientos
Tipos de requerimientos

En ingeniería de sistemas existen tres tipos de requerimientos.

 Un requerimiento funcional puede ser una descripción de lo que

un sistema debe hacer. Este tipo de requerimiento especifica algo
que el sistema entregado debe ser capaz de realizar.

 Un requerimiento no funcional: de rendimiento, de calidad, etc;

especifica algo sobre el propio sistema, y cómo debe realizar sus
funciones. Algunos ejemplos de aspectos solicitables son la
disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.

 Otros tipos de limitaciones externas, que afectan en una forma

indirecta al producto. Estas pueden ir desde la compatibilidad con
cierto sistema operativo hasta la adecuación a leyes o regulaciones
aplicables al producto

Una colección de requerimientos describe las características o

atributos del sistema deseado.
Análisis de los
requerimientos
Definición de requerimientos

 Un requerimiento bien formulado satisface las

siguientes características:

 Necesario: Lo que pida un requerimiento debe ser

necesario para el producto.

 No ambiguo: El texto debe ser claro, preciso y tener

una única interpretación posible.

 Conciso: Debe redactarse en un lenguaje

comprensible por los stakeholders en lugar de uno de
tipo técnico y especializado, aunque aún así debe
referenciar los aspectos importantes
…
Análisis de los
requerimientos
Definición de requerimientos

 Consistente: Ningún requerimiento debe entrar en conflicto con

otro requerimiento diferente, ni con parte de otro. Asimismo, el
lenguaje empleado entre los distintos requerimientos debe ser
consistente también.

 Completo: Los requerimientos deben contener en sí mismos toda

la información necesaria, y no remitir a otras fuentes externas que
los expliquen con más detalle.

 Alcanzable: Un requerimiento debe ser un objetivo realista,

posible de ser alcanzado con el presupuesto, tiempo y recursos
disponibles.

 Verificable: Se debe poder verificar con absoluta certeza, si el

requerimiento fue satisfecho o no. Esta verificación puede lograrse
mediante inspección, análisis, demostración o testeo.
Análisis de los
requerimientos
Actividades en la toma de requerimientos
1. Obtener requisitos: A través de entrevistas o comunicación con
clientes o usuarios, para saber cuáles son sus deseos.

2. Analizar requisitos: Detectar y corregir las falencias

comunicativas, transformando los requisitos obtenidos de
entrevistas y requisitos, en condiciones apropiadas para ser
tratados por el diseño.

3. Documentar requisitos: Igual que todas las etapas, los requisitos

deben estar debidamente documentados.

4. Verificar los requisitos: Consiste en comprobar el correcto

funcionamiento de un requisito en la aplicación

5. Validar los requisitos: Comprobar que los requisitos

implementados se corresponden con lo que inicialmente se
pretendía.
Análisis de los
requerimientos
Técnicas para toma de requerimientos
 Entrevistas: pueden ser personales o grupales, se
realiza una selección de personas que represente a
todos los sectores críticos de la organización, con el
énfasis puesto en los sectores más afectados o que
harán un uso más frecuente del nuevo sistema.

 Talleres: las personas implicadas participan en

discusiones para descubrir requisitos, analizan sus
detalles y las implicaciones cruzadas.

 Forma de contrato: se pueden llenar formularios o

contratos indicando los requisitos. DERCAS
(Documento de Especificaciones, Requerimientos y
Criterios )
Análisis de los
requerimientos
Técnicas para toma de requerimientos
 Prototipos:Un prototipo es una pequeña muestra, de funcionalidad
limitada, de cómo sería el producto final una vez terminado.
Ayudan a conocer la opinión de los usuarios y rectificar algunos
aspectos antes de llegar al producto terminado.

 Historias de usuario: representación de un requerimiento de

software escrito en una o dos frases utilizando el lenguaje común
del usuario. Las historias de usuario son utilizadas en las
metodologías de desarrollo ágiles para la especificación de
requerimientos (acompañadas de las discusiones con los usuarios
y las pruebas de validación).

 Casos de uso: técnica para documentar posibles requisitos,

graficando la relación del sistema con los usuarios u otros
sistemas. Dado que el propio sistema aparece como una caja
negra, y sólo se representa su interacción con entidades externas,
permite omitir dichos aspectos y determinar los que realmente
corresponden a las entidades externas
Análisis de los
requerimientos
Especificación de requerimientos
 Una especificación de requisitos del software es una
descripción completa del comportamiento del sistema a
desarrollar. Incluye un conjunto de casos de uso que
describen todas las interacciones que se prevén que los
usuarios tendrán con el software. También contiene
requisitos no funcionales (o suplementarios). Los requisitos
no funcionales son los requisitos que imponen restricciones
al diseño o funcionamiento del sistema (tal como requisitos
de funcionamiento, estándares de calidad, o requisitos del
diseño).

 Las estrategias recomendadas para la especificación de los

requisitos del software están descritas por IEEE 830-1998.
Este estándar describe las estructuras posibles, contenido
deseable, y calidades de una especificación de requisitos
del software.

SRS IEE & Doc. De vision

 EJERCICIO:
Análisis de los requerimientos

 Se le ha solicitado a su empresa la elaboración de un software para el apoyo en las gestiones de

contratación de personal en una empresa que se dedica a el reclutamiento, se necesita:
 Gestión de candidatos
 Gestión de perfiles
 Gestión de rangos salariales por perfil
 Gestión de citación a candidatos e informe de obtención de plaza vía electrónica y vía telefónica
(guardar registro)
 Registro digital de resultados de evaluaciones y almacenamiento de perfiles a ser tomados en
cuenta para plazas futuras.
 Debido a que es una multinacional, se lleva registro de candidatos alrededor del mundo y el
sistema debe ser Web, centralizado y administrado en Guatemala pero accesible desde todos los
continentes.
 El cliente desea un sistema dividido en módulos para hacer la transición del modo de manejo
actual de esta información al nuevo sistema informático lo mas pronto posible pero con avances
estables, por lo que requiere varias entregas, de igual manera la empresa cuenta con un
departamento interno de sistemas, el cual se encargara de mantener este sistema y hacerlo
crecer si fuese necesario.

 Usted va a realizar un segundo contacto con el cliente dentro de una semana pero este ya le ha
solicitado una estimación de presupuesto y agenda para la finalización del proyecto:
 Que procede?
 Liste los requerimientos que percibe.
 Es necesario mas requerimientos? Como los obtendría?
 Que tipo de metodología, a primera vista, podría usted utilizar para llevar a cabo este proyecto?
 TAREA:
Investigar:
 Patrones de diseño.
 Requerimientos No Funcionales de Software:
 rendimiento
 escalabilidad
 mantenimiento
 fiabilidad
 disponibilidad
 seguridad
 usabilidad