Análisis SWEBOK

Referencia del artículo: SWEBOK (Guide to the software Engineering body of knowledge)
Nombre de los autores	IEEE
Nombre del artículo	Software Requeriments (Requisitos de software)

El documento habla, sobre el análisis, la especificación y validación de los requisitos del software, define un requisito como una característica que se debe exhibir para solucionar cierto problema. Se habla de los diferentes tipos de requisitos que se pueden extraer de los Stakeholders  (tipos de usuario que interactuan directamente con el sistema) según las metodologías que se pueden utilizar para la extracción de datos (entrevistas, prototipos, reuniones, escenarios) con el fin de capturar información lo suficientemente clara y verídica como para tener un listado de requisitos confiables y comprobables para el proceso del software. La comunicación entre los usuarios del software y los ingenieros es vital para el éxito del sistema pues con base a esta es posible que el ingeniero del software detecte las inconsistencias y puntos críticos de los requisitos entregados por los Stakeholders y pueda llevarlos a un punto medio de satisfacción para los usuarios ya que es casi imposible satisfacer a plenitud todos los requisitos entregados por estos.

Se deben formular metas reales, aterrizadas para la realización de software, basándose en el entorno operacional donde el software se estará ejecutando y también se debe tener en cuenta el proceso del negocio ya que de este saldrá la estructura y las políticas para el sistema. También se habla de los tipos de requisitos con los que podemos trabajar funcionales (describen las funciones que el software va a ejecutar)o no funcionales (actúan para obligar la situación), si el requisito está derivado de uno o mas requisitos de alto nivel (características inesperadas), su prioridad (altamente deseable, el mas esencial para satisfacer las metas finales del software), según su alcance (que tanto afectan al software y sus componentes) y su volatilidad y estabilidad (que tanto fluctúan sus reglas o normas), después de tener los requisitos es necesario realizar una validación donde se examine el documento que se realizo para asegurarse que define correctamente  el software, estas revisiones pueden constituir el final del documento

Palabras Claves

• Requisito:

Característica que se debe exhibir para solucionar cierto problema del mundo real

• Stakeholders

Usuarios que interactuan directamente con el sistema

• Software

Producto final, Conjunto de instrucciones y datos codificados para ser leídas e interpretadas por una computadora

• Característica

Detalle, actividad a realizar dentro del software

• Captura

Tomar, substraer.

• Negociación

Punto medio y/o acuerdo entre los Stakeholders y los ingenieros de software

• Especificaciones

Conjunto de reglas y características para un requisito.

Ideas clave

• 
  Una característica esencial de todos los requerimientos del software es que sean comprobables 

Todos los requisitos que se levanten deben ser validados y comprobados con los usuarios de alto      nivel de las organizaciones, con los documentos de validación creados, y de estar forma evitar     añoranzas y/o   sueños de los usuarios finales del sistema y de esta forma  no dejar ningún requisito en el aíre.

• Los requisitos se deben acentuar en términos de coste, puntualidad y satisfacción al cliente.

Se debe vender la idea en las empresas de las buenas practicas de la ingeniería de requisitos, pues con base a este trabajo se puede evitar mucho re-proceso en el desarrollo de sistemas, tanto en el que debe hacer el programa y en el como lo va a hacer.

• Debe existir una buena comunicación entre los usuarios del software y los ingenieros de software

Teniendo una buena comunicación entre los usuarios y los ingenieros de software y con unas buenas técnicas de recolección de datos, podemos levantar de forma mas óptima y oportuna los requerimientos funcionales del sistema.

• Se debe conocer el medio y/o ambiente en el que trabajará el sistema.

Cuando se levanta un requerimiento para una empresa, no solo se debe tener en cuenta el que y como va a funcionar el sistema si no que se debe conocer el medio donde se ejecutará el programa y la forma de utilizarlo, pues aunque en el papel un requerimiento sea igual a otro según la organización donde se aplique puede tener una interpretación y/o funcionamiento diferente.

• Se debe validar constantemente los requisitos levantados.

Constantemente se debe de estar retro alimentando la base del conocimiento realizado en el levantamiento de requerimientos hecho para una organizaciones, pues constantemente existirán actualizaciones que permitirán tener una mejor visión del que y como se va hacer cada requerimiento.

Análisis SWEBOK

Aspectos que me llamaron la atención

• Mejorar la comunicación entre usuarios e ingenieros de software
• Las revisiones y validaciones frecuentes a los requerimientos y manejo de versiones.
• Las diferentes formas de capturar información para los requerimientos
• Los tipos de usuario que intervienen en el proceso del software
• Los diferentes tipos de requisitos que existen en especial los volátiles que son muy frecuentes con el cambio de reglas hechas por ejemplo por el gobierno Colombiano.

Aspectos en los que me gustaría profundizar

• En las diferentes formas de capturar información, como realizar correctamente una entrevista a un usuario o grupo de usuarios, como analizar correctamente el entorno donde trabajará el sistema para tomar un buen requerimiento.

Referencia bibliográficas:
Referencia	Cita
IEEE	SWEBOK GUIDE 2004
Guide to the Software Engineering Body of Knowledge (SWEBOK)	http://www2.computer.org/portal/web/swebok

Acerca de aquirozr

Soy Ingeniero Informático del Politécnico Colombiano Jaime Isaza Cadavid, especialista en desarrollo de software de la Universidad EAFIT y un enamorado de la tecnología y el desarrollo de software, Antioqueño de cuna, con 27 años de edad.

El modelo de negocios como marco de referencia para el desarrollo de servicios de información ›

Publicado en Desarrollo de Software