Análisis de requerimientos (parte 1)

Aprovechando que estoy estudiando teórico y soy una negada para retener las cosas como si fuera un loro, he querido redactar un poco sobre análisis de requerimientos para la asignatura de Ingenieria del Software. Creo que es la única manera de aprenderme conceptos tan teóricos.

El post tendrá dos partes: la primera es la que se muestra a continuación, introduciendo unos cuantos conceptos básicos y explicando en que consiste el análisis del sistema y que cosas hay que tener en cuenta; la segunda la subiré más tarde, o mañana, y englobará las técnicas de determinación de requerimientos, su posterior análisis y cómo han de especificarse.

Para empezar, vamos a definir unos cuantos conceptos...

Un sistema informático es un conjunto de elementos organizados para realizar algún método, procedimiento o control mediante el procesamiento de información. Dentro de un sistema informático no sólo encontramos software o hardware, sino que también diferentes roles de personas, bases de datos, documentos o procedimientos.

Un requisito, propiamente dicho, es la condición o capacidad necesitada por el usuario para poder llegar a solucionar un problema (o cumplir unos objetivos). En otras palabras, es lo que tiene que llegar a hacer el sistema.

La solución a un problema, puede resolverse de 4 maneras: manualmente, mediante software, mediante hardware o mediante la combinación de las tres.
Dicha solución puede ser simple (mediante un software simple) o compuesta (mediante un sistema más complejo, automatizando todas las acciones). En el caso del sistema compuesto es necesario diseñar el sistema global antes de diseñar el software que se integre.

La ingeniería de sistemas informáticos es la actividad que se encarga de resolver estos problemas. Para ello, es necesario que el cliente que nos pide la integración participe en el desarrollo (en general) del producto aportando los objetivos y restricciones que debe tener el sistema. El ingeniero es quién desarrolla la solución; en un primer momento será él el que analice el sistema delimitando el ámbito de funcionamiento, el rendimiento y las funciones. Con esta información tendrá que determinar una serie de soluciones entre las que escogerá la mejor teniendo en cuenta, entre otras cosas, la existencia de un producto en el mercado que resuelva sus necesidades (“es el caso de la necesidad de tener una hoja de cálculo, no la desarrollaremos porque ya existe”), el coste que podría suponer, el tipo de tecnología o las necesidades reales a cubrir.

ETAPAS DEL ANÁLISIS DEL SISTEMA

1. Identificar las necesidades del cliente. Podremos determinar los objetivos a conseguir. Si se trata de un producto con el que se espere mucho impacto entre los usuarios, se deberá hacer un estudio de mercado.
2. Estudiar la viabilidad del sistema. Esto incluye la económica (analizar impacto del coste-beneficio), la técnica (ver si se puede realizar o no), la legal (determinar las infracciones o ilegalidades que pueda provocar el sistema) y las alternativas (estudiar las diferentes soluciones presentadas).
3. Hacer un análisis económico-técnico más profundo.
4. Determinar las funciones necesarias y asignarlas a elementos del sistema.
5. Crear un documento donde se especifique la definición del sistema. Este documento servirá como base para todo el desarrollo del sistema posterior.

Tanto si la solución es simple, como si es compuesta (sistema complejo) tendremos que realizar un análisis de los requerimientos del software. Una vez comprendamos el problema mediante el estudio del sistema hemos de plasmar esta comprensión es un documento. Esto es lo que se llama especificación de requerimientos. Los requerimientos que hemos de tener en cuenta pueden ser:

• Funcionales: describen las entradas y salidas del sistema, y las operaciones que se hacen entre ellas.
• No funcionales: definen las cualidades generales que ha de tener el sistema. En otras palabras, podemos definir estos requerimientos como los límites de las posibles soluciones. Estos pueden ser de rendimiento, de diseño (cumplimiento de estándares, requisitos hardware, control de errores, seguridad), de interfícies externas (todo lo relacionado con la interacción de las personas, con el hardware o con otro tipo de software), de calidad (que sea fácil de usar, de mantener, que sea ampliable...) o sobre decisiones de diseño (implementaciones de módulos).