Semana 10 – Requisitos del Software

Los requisitos software son la descripción de las características y las funcionalidades del
sistema que se desea implementar.

Los requisitos nos comunican las expectativas de los consumidores de productos software.

Los requisitos pueden ser obvios o estar ocultos, conocidos o desconocidos, esperados o
inesperados, desde el punto de vista del cliente.

Ingeniería de requisitos
El proceso de recogida de información, análisis y documentación sobre los requisitos del
software es del cliente, se conoce como ingeniería de requisitos.

El objetivo de este tipo de Ingeniería es el de desarrollar y mantener un documento de

especificación de requisitos del sistema de forma sofisticada y descriptiva.

Proceso de la Ingeniería de requisitos

Es un proceso que consta de cuatro pasos.

 Estudio de viabilidad
 Recogida de requisitos
 Requisitos del Software
 Validación de los requisitos de Software

Estudio de viabilidad
Cuando el cliente se acerca a la organización para obtener el producto deseado
desarrollado, expone una idea aproximada de las funciones que el software debe
cumplir y qué características se esperan del software.
Refiriéndose a esta información, los analistas elaboran un estudio detallado sobre la
viabilidad del sistema deseado y de sus funcionalidades, para proceder a desarrollarlo.

Este estudio de viabilidad se centra en el objetivo de la organización. El estudio analiza

la materialización práctica del producto software respecto a su implementación, la
contribución de proyecto a la organización, los límites de costes, y según los objetivos y
valores de la organización. Explora aspectos técnicos del proyecto y del producto,
como la utilidad, el mantenimiento, la productividad y la capacidad de integración.

El resultado (output) de esta fase debe ser un informe del estudio de viabilidad,
conteniendo comentarios adecuados y recomendaciones para la gestión sobre si se
debe tirar adelante o no el proyecto.

Recogida de requisitos
Si el informe de viabilidad es positivo en relación a tomar el proyecto, la siguiente fase
empieza con la recolección de requisitos por parte del consumidor.

Analistas e Ingenieros se comunican con el cliente y los consumidores para conocer sus
ideas sobre qué debe aportar el software y qué características quieren que incluya
éste.
Requisitos del Software [Software Requirements Specification (SRS)]
El SRS es un documento creado por los analistas de sistema después de recoger los
requisitos.

El SRS define cómo va a interactuar el software que quiere crearse con el hardware, las
interfaces externas, la velocidad operativa, el tiempo de respuesta del sistema, la
portabilidad del software en las diversas plataformas, el mantenimiento, la velocidad
de reponerse después de estropearse, su seguridad, calidad, limitaciones, etc.

Los requisitos recibidos por parte del cliente se escriben en lenguaje natural. Es
responsabilidad del analista de sistemas documentar sobre los requisitos en lenguaje
tecnológico para que puedan ser útiles y comprendidos por el equipo de desarrollo de
software.

El SRS debe venir con las siguientes características:

 Los requisitos del usuario se deben expresar en lenguaje natural.

  Los requisitos técnicos se deben expresar en lenguaje estructurado, el cual
se usará dentro de la organización.
 La descripción del diseño se debe escribir en pseudocódigo.

 Anotaciones condicionales y matemáticas para DFDs (editor de diagramas

de flujo) etc.

Validación de los requisitos de Software

Después del desarrollo de los requisitos, los que se mencionen en este documento
serán validados. El usuario puede que pida soluciones ilegales y poco prácticas, y los
expertos puede que interpreten los requisitos de forma incorrecta. Estos resultados se
incrementan en coste si no se cortan de raíz. Los requisitos se pueden evaluar en
contraste con las siguientes condiciones.

 Si pueden ser implementados de manera práctica.

 Si son válidos a nivel de funcionalidad y dominio del software
 Si hay alguna ambigüedad
 Si se han completado
 Si se pueden demostrar

Proceso de reducción de requisitos

El Proceso de reducción de requisitos se puede representar usando el siguiente diagrama:

 Recogida de requisitos - Los desarrolladores hablan con el cliente y los consumidores

finales para conocer sus expectativas respecto al software.
 Organizar requisitos - Los desarrolladores priorizan y organizan los requisitos en orden
de importancia, urgencia, y conveniencia.
 Negociación y debate - Si los requisitos son ambiguos o hay algún conflicto en los
requisitos de varios accionistas, hay una negociación y un debate con ellos. Los
requisitos entonces, se priorizan y se acuerdan de manera razonable. Los requisitos
vienen de varios accionistas. Para eliminar cualquier ambigüedad o conflicto, se
debate para encontrar claridad y corrección. Los requisitos surrealistas se acuerdan de
forma razonable.
 Documentación - Los requisitos formales y no formales, funcionales y no funcionales,
son documentados y se ponen disponibles para procesar en la siguiente fase.
Técnicas de reducción de requisitos
La reducción de requisitos es un proceso para encontrar los requisitos para un sistema de
software que se intenta desarrollar, usando la comunicación con el cliente, los consumidores
finales, usuarios del sistema y otros que tienen algún papel en el desarrollo del sistema de
software.

Hay varios caminos para descubrir requisitos

Entrevistas
Las entrevistas son medios de recogida de requisitos medianamente fuertes. La
organización puede conducir muchos tipos de entrevistas, tales como:

 Entrevistas estructuradas (cerradas), donde cada información que se recoge es

decidida con antelación, siguen patrones y temas de debate de forma firme.

 Las entrevistas no estructuradas (abiertas), donde la información que se busca

no se decide con antelación, es más flexible y menos tendenciosa.

 Entrevistas orales

 Entrevistas por escrito

 Entrevistas cara a cara entre 2 personas

 Entrevistas de grupo que se llevan a cabo entre grupos de participantes.

Ayudan a destapar cualquier requisito que falte, ya que mucha gente está
incluida.

Encuestas
La organización puede conducir encuestas o sondeos entre varios accionistas pidiendo
sus expectativas y requisitos para el sistema que se va a desarrollar.

Cuestionarios
Un documento con preguntas objetivas definidas previamente con sus opciones
respectivas. Se entrega a todos los accionistas para que las respondan, se recogen y se
recopilan.

Una limitación de esta técnica es que si una opción por algún asunto no se menciona
en el cuestionario, el asunto puede quedar desatendido.

Análisis de tareas
El equipo de ingenieros y de desarrolladores puede analizar la operación por la cual se
requiere el nuevo sistema. Si el cliente ya tiene algún software para realizar ciertas
operaciones, se estudia y los requisitos del sistema propuesto se recogen.

Análisis de dominio
Cada software pertenece a unas categorías de dominio. Los expertos en dominio
pueden ser de gran ayuda para analizar requisitos generales y específicos.

Lluvia de ideas
Un debate informal se lleva a cabo entre varios accionistas y todos los inputs o
entradas se graban para el análisis de requisitos posterior.
 Modelo de prototipos
Se basa en construir interfaces de usuario sin añadir detalles de las funcionalidades
para que el usuario interprete las características del producto software que se quiere
desarrollar. Ayuda aportando una mejor idea de los requisitos. Si el consumidor final
no tiene el software instalado para que el desarrollador lo tome como referencia y el
cliente no sabe cuáles son sus propios requisitos, el desarrollador crea un prototipo
basado en los requisitos mencionados al inicio. El prototipo se muestra al cliente y el
feedback que se obtiene se registra. El feedback del cliente sirve d input o entrada
para la recogida de requisitos.

Observación
El equipo de expertos visita la organización o el lugar de trabajo de los clientes.
Observan el funcionamiento de los sistemas instalados ya existentes. También
observan el flujo de trabajo y cómo se tratan los problemas de ejecución. El equipo
traza las conclusiones que ayudan a formar los requisitos esperados para el software.

Características de los requisitos del Software

La recogida de requisitos de software es la fundación de la totalidad del proyecto de desarrollo
software. Por ello, debe de ser clara, correcta y bien definida.

Una completa especificación de requisitos Software debe ser:

 Clara
 Correcta
 Consistente
 Coherente
 Comprensible
 Modificable
 Verificable
 Priorizada
 sin ambigüedades
 Trazable
 Origen creíble

Requisitos de Software
Debemos intentar entender qué tipo de requisitos pueden aparecer en la fase de educción de
requisitos y qué tipo de requisitos se esperan del sistema de software.

En líneas generales los requisitos de software se deben caracterizar en dos categorías:

Requisitos funcionales
Requisitos que se relacionan a aspectos funcionales del software irían en esta categoría.

Definen las funciones y la funcionalidad en y desde el sistema de software.

Ejemplos -

 Buscar una opción dada al usuario para buscar desde varias facturas.
 El usuario debe ser capaz de enviar por correo electrónico cualquier informe a la
Dirección.
 Los usuarios se pueden dividir en grupos y los grupos pueden tener derechos
diferentes.
  Debe cumplir reglas empresariales y funciones administrativas.
 El Software se desarrolla manteniendo intacta la compatibilidad en descenso.

Requisitos no funcionales
Los requisitos, los cuales no están relacionados con aspectos funcionales del software, están
en esta categoría. Son características del software implícitas o esperadas, asumidas por los
usuarios.

Los requisitos no funcionales incluyen -

 Seguridad
 Acceso
 Almacenaje
 Configuración
 Actuación
 Coste
 Interoperabilidad
 Flexibilidad
 Recuperación de desastre
 Accesibilidad

Los requisitos se categorizan de forma lógica como

 Tienen que tener : El Software no puede ser operacional sin ellos.

 Deben tener : Motivando la funcionalidad del software.
 Pueden tener : El Software aún puede funcionar bien con estos requisitos.
 Lista de deseo : Estos requisitos no contienen ningún objetivo de software.

Mientras se desarrolla el software, el ‘tiene que tener’ se debe implementar, el ‘debe tener’ es
un asunto de debate y negociación, en cambio el ‘puede tener’ y la ‘lita de deseo’ se pueden
mantener para futuras actualizaciones del software.

Requisitos de la interfaz de usuario

La UI es una parte importante de cualquier software, hardware o sistema híbrido. Un software
es ampliamente aceptado si es -

 Fácil de manejar
 rápido en responder
 efectivo tratando errores operacionales
 aportando interfaces de usuario simples y consistentes

La aceptación del usuario mayormente depende de cómo éste pueda usar el software. La UI es
el único camino para percibir el sistema por parte de los usuarios. Un sistema software de
buena actuación también debe estar equipado con interfaces de usuario atractivas, claras,
consistentes y receptivas. En caso contrario las funcionalidades del sistema software no
pueden usarse de una manera conveniente.

 Presentación de contenido
 De fácil navegación
 Interfaces simples
 Receptivo
 Elementos consistentes de UI
  Mecanismo de retroalimentación
 Configuración Default
 Disposición significante
 Uso estratégico del color y la textura.
 Aportar información de ayuda.
 Aproximación centrada en el usuario.
 Vista de la configuración basada en el grupo.

Analista de sistemas Software

El analista de sistemas es una persona de una organización informática, que analiza los
requisitos del sistema propuesto y asegura que los requisitos sean concebidos y documentados
correctamente. El papel del analista empieza durante la fase del SDLC de análisis del Software.
El analista tiene la responsabilidad de asegurar que el software que se desarrolle cumpla los
requisitos del cliente.

Los analistas de sistemas tienen las siguientes responsabilidades:

 Analizar y entender los requisitos del software deseado.

 Entender cómo será la contribución del proyecto en los objetivos de la
organización.
 Identificar el origen de los requisitos.
 Validación de requisitos.
 Desarrollo e implementación el plan de gestión de requisitos.
 Documentación empresarial, técnica, de proceso, y requisitos del producto.
 Coordinación con los clientes para priorizar requisitos y eliminar ambigüedad.
 Terminar la aceptación de criterios con el cliente y otros accionistas.

Auditorias de Software
Una auditoría es una actividad de revisión mediante la cual puede verificarse el cumplimiento
de un Sistema de Gestión establecido y la efectividad de dicho sistema y, en caso contrario,
evaluar la necesidad de una mejora o de una acción correctiva.

Como condición previa a la auditoria es necesario que existan unas reglas de juego conocidas
por ambas partes, auditor y auditado, que afectan a la empresa. Estas reglas consisten en
estándares o requisitos de referencia que pueden estar contenidos, por ejemplo, en
las normas ISO de sistemas de gestión.

Características de las auditorías

Los adjetivos que describen a las auditorías son:

 Sistemática. Ajustarla a un método, aumentando su objetividad y permitiendo

establecer comparaciones.

 Documentada. Basada en datos fiables y suficientes que garanticen un diagnóstico real

y completo.

 Independiente. Presenta una situación real, sin manipulaciones, por lo que la realizan
personas que no tengan responsabilidad directa en los sectores que se desea auditar.

El éxito y la eficacia de una auditoría dependen de la cooperación de todas las partes

involucradas.
Tipos de auditorías
Existen diferentes criterios para clasificar las auditorías.

En función de su origen pueden ser:

 Auditoría externa: es la desarrollada por personas o entidades ajenas a la organización

y por lo tanto, externa a sus procedimientos y gestión. La realiza una empresa sobre
sus propios proveedores o subcontratistas, o un cliente sobre ella. Los objetivos de
este tipo de auditoría son: determinar la adecuación de los proveedores y evaluar la
validez de los proveedores o subcontratistas.

 Auditoría interna: la realiza la organización para verificar la efectividad de sus propios

sistemas y procedimientos del sistema o sistemas de gestión implantados, y de esta
forma comprobar si se precisa algún cambio. Los objetivos de la auditoría interna son
los siguientes: asegurar que se cumplen los planes para la gestión de la organización y
que el sistema ha sido adecuadamente implantado y mantenido además de informar a
la dirección de la situación del sistema de gestión. Estas auditorías son realizadas por
personal de la propia empresa, o subcontratado por la misma, pero siempre se debe a
la iniciativa propia de la organización y siguiendo su metodología.

En función del objetivo de la auditoria, ésta puede ser:

 Auditoría de primera parte, correspondería a la auditoría interna.

 Auditoría de segunda parte, haría referencia a la auditoría externa llevada a cabo por

un contratista en una organización que provee de productos/servicios. Los objetivos
de este tipo de auditoría son: determinar la adecuación y evaluar la validez como
proveedores o subcontratistas.

 Auditoría de tercera parte, es la auditoría externa realizada por una entidad o persona
ajena a las actividades de la organización y sin intereses en la misma. Esta auditoría es
realizada por un organismo independiente de la organización. Generalmente, la realiza
un organismo acreditado conforme a una norma en la que se basa el sistema de
gestión y, por lo tanto, conduce a la obtención de una certificación. Tiene varias
ventajas, ya que al estar hecha por alguien independiente y con credibilidad, es
probable que los clientes decidan no efectuar otras auditorias, con el consiguiente
ahorro económico y de tiempo para ambas partes (cliente y proveedor).

Ámbitos de las auditorías

Las auditorias no necesariamente tienen que cubrir la totalidad del sistema de una vez, sino
que pueden cubrir elementos o partes del mismo.

En todo caso, la persona o personas que actúan como auditores han de ser independientes del
área a auditar. La independencia se asegura mediante auditores que no tengan
responsabilidad directa sobre el área auditada y preferiblemente trabajando en colaboración
con personal relevante de la misma.

De este modo, las opiniones vertidas respecto al cumplimiento de la norma o estándar de

referencia son más objetivos que si la persona que las realiza fuera a la vez juez y parte del
proceso a auditar.
Softwares para Auditoría de Sistemas

https://www.youtube.com/watch?v=77t2lCX0zU8