Ingeniería de Sistemas y TelecomunicacionesINGENIERÍA DEL SOFWARE IIRequerimientos

Requirements: concept/definition

At its most basic, a software requirement is a property which must be exhibited in order

to solve some problem in the real world.

–IEEE, 2004

Problemas con los requerimientos: 34.2%

¿Ingeniería de Requerimientos (IR)?

Así, como en su momento la disciplina para crear software fue denominada Ingeniería del software, hay quienes proponen que los requerimientos son toda una disciplina ya que se enfoca en la definición de algo fundamental: lo que se desea producir.

De acuerdo con Rational Software Corporation (IBM) "La Ingeniería de Requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto".

Objetivos de la IR

• Comprender todas las actividades que permitan crear y mantener el documento y los formatos relacionados con los requerimientos del sistema, en el que se describa con claridad, sin ambigüedades el comportamiento del sistema.

• Facilitar la comprensión de los requerimientos y necesidades del cliente, de tal manera que se puedan transformar en un sistema operacional o aplicativo.

• Permitir la adecuada gestión de los requerimientos durante el proceso de desarrollo.

Software Requirements Fundamentals, IEEE

• Product and Process Requirements

distinction can be drawn between product parameters and process parameters. Product parameters are requirements on software to be developed (for example, “The software shall verify that a student meets all prerequisites before he or she registers for a course.”). A process parameter is essentially a constraint on the development of the software (for example, “The software shall be written in C#.”).

Software Requirements Fundamentals, IEEE

• Functional and Nonfunctional Requirements

Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities. Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements.

Software Requirements Fundamentals, IEEE

• Emergent Properties

Some requirements represent emergent properties of software—that is, requirements which cannot be addressed by a single component, but which depend for their satisfaction on how all the software components interoperate. The throughput requirement for a call center would, for example, depend on how the telephone system, information system, and the operators all interacted under actual operating conditions. Emergent properties are crucially dependent on the system architecture.

Software Requirements Fundamentals, IEEE

• Quantifiable RequirementsSoftware requirements should be stated as clearly and as unambiguously as possible, and, where appropriate, quantitatively. It is important to avoid vague andunverifiable requirements which depend for their interpretation on subjective judgment (“the software shall be reliable”; “the software shall be user-friendly”). This is particularly important for nonfunctional requirements.Two examples of quantified requirements are the following: a call center’s software must increase the center’s throughput by 20%; and a system shall have a probability of generating a fatal error during any hour of operation of less than 1 * 10−8. The throughput requirement is at a very high level and will need to be used to derive a number of detailed requirements. The reliability requirement will tightly constrain the system architecture.

• El sistema debe ser confiable

• El sistema debe permitir que muchos usuarios se conecten al mismo tiempo

• Permitir que la factura de venta sea exportada

• Que la base de datos soporte grandes cantidades de información

Trabajo con requerimientos desde la IEEE

• Requirements Process• Requirements Elicitation• Requirements Analysis• Requirements Specification• Requirements Validations

Existen cuatro actividades genéricas dentro del proceso de la ingeniería de requerimientos

(1) Estudio de factibilidad del sistema, (2) obtención y análisis de requerimientos, (3) Especificación y documentación de los requerimientos, y (4) Validación de los requerimientos.

Somerville

Somerville

El Estudio de factibilidad es una descripción resumida del sistema y de cómo se utilizará dentro de una organización. Este estudio recomienda si es conveniente o no llevar a cabo la IR y el desarrollo del sistema propuesto.

Dicho en otras palabras nos ayuda a evaluar si el sistema:

Contribuye a los objetivos de la organización.

Se puede implementar con la tecnología actual dentro del costo y tiempo propuestos.

Puede integrarse a otros sistemas existentes dentro de la organización.

Somerville

La obtención y análisis de requerimientos sirve para determinar el dominio del software cuales servicios debe proporcionar el sistema, así como su desempeño requerido, las restricciones de hardware, etc.

Se trabaja estrechamente con los usuarios a fin de conocer la problemática en detalle. Las actividades que cubren son:

Comprensión del dominio Recolección de

requerimientos Clasificación de

requerimientos Resolución de conflictos Priorización Verificación de

requerimientos

Somerville

La Especificación y documentación de los requerimientos se enfoca al proceso de documentación del comportamiento deseado del sistema. Es un acuerdo -entre usuarios y el equipo encargado del desarrollo del software- y debe tener al menos las siguientes características: Contener todos los

requerimientos deseados. Cada requerimiento solo tiene

una interpretación posible. Planificación y Modelado Proceso

de la Ingeniería de Requerimientos

Ingeniería en Sistemas Computacionales

El cumplimiento de cualquier requerimiento no provoque conflictos con el cumplimiento de otro requerimiento, es decir, que sea consistente.

Prioridades definidas.

Somerville

Por último la actividad de validación de los requerimientos tiene mucho en común con el análisis, ya que implica encontrar problemas con los requerimientos. Sin embargo, son procesos distintos puesto que la validación comprende un bosquejo completo del documento de requerimientos mientras que el análisis implica trabajar con los requerimientos incompletos.

Durante esta actividad se deben llevar a cabo diferentes tipos de verificación en el documento de requerimientos que incluyen verificaciones de:

Validez Consistencia Integridad Realismo Verificabilidad

• Requerimientos de proceso

• Requerimientos de usuarios

• Requerimientos para el análisis y la negociación

• Requerimientos para la gestión

• Requerimientos del sistema

• Requerimientos del equipo encargado del proyecto

• Requerimientos de la organización

Clasificación

• Consultar la clasificación de los requerimientos

• Elaborar el formato de levantamiento de requerimientos

• Avanzar en el proyecto:• Introducción• Presentación de la organización• Objetivo general• Objetivos específicos• Planteamiento del problema• Definición del problema

• Metodología• Modelo y enfoque de

desarrollo

• Propuesta de formato de levantamiento de requerimientos

• Propuesta de requerimientos

Tarea