Software Requirements 3rd Edition

Name: Isocrates De La Cruz.

Enrollment: 2018-0510.

Task: Summary Chapter 1-2.

Chapter 1: The essential software requirement.

Siempre han existido varias definiciones acerca de lo que es un requisito,

décadas han pasado desde la invención de la programación de software y
todavía hoy en día se tornan fuertes debates sobre lo que son. Existe una
definición que reconoce los diversos tipos de información que
conjuntamente son reconocidos como requisitos, esta dice así: “Los
requisitos son una especificación de lo que debería ser implementado. Son
descripciones de como el sistema debe comportarse, o de una propiedad o
atributo del sistema. Pueden ser una limitación en el proceso de desarrollo
de software”.

Los requisitos abarcan tanto la visión del usuario sobre como funciona el
sistema por fuera como la visión del desarrollador sobre propiedades
internas. Incluyen tanto el comportamiento del sistema en condiciones
específicas como también aquellas propiedades que hacen que el sistema
sea adecuado, e incluso agradable, para su uso.

Los requisitos de software incluyen una dimensión temporal. Podrían estar

en tiempo presente, describiendo las capacidades del sistema actual. O
podrían ser a corto plazo (alta prioridad), a medio plazo (prioridad media) o
hipotéticos (prioridad baja) en el futuro. Incluso pueden ser en pasado,
refiriéndose a necesidades que una vez fueron especificadas y luego
descartadas.
Ya que existen diferentes tipos de información sobre los requisitos, se
necesita un conjunto de adjetivos para modificar el gran sobrecargado
término “requisito”. Estos son:

 Requisito de Negocio. Los requisitos del negocio describen por qué

la organización está implementando el sistema, los beneficios del
negocio que se esperan lograr.

 Regla de negocio. Las reglas de negocio describen las operaciones,

definiciones y restricciones que se aplican a una organización.

 Restricción. Las restricciones de diseño e implementación imponen

restricciones sobre las opciones disponibles para el desarrollador
durante la construcción del producto.

 Requisito de Interfaz externa. Describen las interfaces externas entre

el sistema y el mundo exterior, esto incluye conexiones a otros
sistemas de software, componentes de hardware y usuarios, así como
interfaces de comunicación.

 Características. Una característica consiste en una o más capacidades

de sistema relacionadas lógicamente que proporcionan valor a un
usuario y se describen mediante un conjunto de requisitos
funcionales.

 Requisitos Funcionales. Los requisitos funcionales detallan los

comportamientos que el producto exhibirá bajo condiciones
específicas.

 Requisitos No Funcionales. Los requerimientos no funcionales, como

su nombre lo indica, son aquellos requerimientos que no se refieren
directamente a las funciones específicas que proporciona el sistema,
sino a las propiedades emergentes de este como la fiabilidad, el
tiempo de respuesta y la capacidad de almacenamiento.
  Atributos de Calidad. Los atributos de calidad (también cualidades
del software) son características no funcionales que se consideran
deseables en un sistema de software.

 Requisito de Sistema. Los requisitos del sistema indican lo que el

sistema debería tener para ser capaz de ejecutar el producto.

 Requisito de Usuario. Los requisitos de usuario describen los

objetivos o tareas que los usuarios deben poder realizar con el
producto, básicamente indican lo que la aplicación debe hacer o
tener para satisfacer las necesidades del usuario.

INGENIERIA DE REQUISITOS: Desarrollo de requisitos.

Según el libro, el desarrollo de requisitos se divide en varias subdisciplinas
que abarcan todas las actividades relacionadas con explorar, evaluar,
documentar y confirmar los requisitos de un producto:

 Obtención. La obtención abarca todas las actividades relacionadas

con el descubrimiento de requisitos, tales como entrevistas, talleres,
análisis de documentos, creación de prototipos y otros.

 Análisis. El análisis de los requisitos implica alcanzar una comprensión

más rica y precisa de cada uno de ellos y representar conjuntos de
requisitos de múltiples maneras.

 Especificación. La especificación de requisitos implica representar y

almacenar el conocimiento de los requisitos recopilados de forma
persistente y bien organizada.

 Validación. La validación de requisitos confirma que usted tiene el

conjunto correcto de información de requisitos que permitirá a los
desarrolladores construir una solución que satisfaga el objetivo del
negocio.
INGENIERIA DE REQUISITOS: Gestión de requisitos.

La gestión de requisitos incluye lo siguiente:

 Definir la línea de base de los requisitos, una vista panorámica en el

tiempo que representa un conjunto acordado, revisado y aprobado
de requisitos funcionales y no funcionales, a menudo para una
iteración específica de lanzamiento o desarrollo de un producto.

 Evaluar el impacto de los cambios de requisitos propuestos e

incorporar los cambios aprobados en el proyecto de manera
controlada.

 Mantener los planes de proyecto actualizados con los requisitos a

medida que evolucionan.

 Negociación de nuevos compromisos sobre la base del impacto

estimado de los cambios en las necesidades.

 Definir las relaciones y dependencias que existen entre los requisitos.

 Seguimiento de los requisitos individuales a sus correspondientes

diseños, código fuente y pruebas.

 Seguimiento del estado de los requisitos y de la actividad de cambio

a lo largo del proyecto.

El objetivo de la gestión de requisitos no es sofocar el cambio ni

dificultarlo. Es anticipar y acomodar los cambios reales que siempre se
pueden esperar para minimizar su impacto negativo en el proyecto.
La gente a veces se resiste a gastar el tiempo que se necesita para escribir
los requisitos de software. Pero escribir los requisitos no es la parte difícil.
Lo difícil es determinar los requisitos. Escribir los requisitos es cuestión de
aclarar, elaborar y registrar lo que has aprendido. Una sólida comprensión
de los requisitos de un producto asegura que su equipo trabaje en el
problema correcto y diseñe la mejor solución para ese problema. Sin
conocer los requisitos, no se puede saber cuándo está terminado el
proyecto, ni tampoco saber si se han alcanzado los objetivos o si se
deberían tomar decisiones de compensación cuando son necesarios ajustes
en el alcance.

Cabe agregar también que una participación insuficiente de los usuarios

conduce a requisitos de última hora que generan retrabajos y demoras en
la finalización. También podrían aparecer requisitos ambiguos, los
requisitos ambiguos causan pérdida de tiempo cuando los desarrolladores
implementan una solución para el problema equivocado. Los probadores
que esperan que el producto se comporte de manera diferente a lo que los
desarrolladores construyeron, pierden tiempo resolviendo las diferencias.
Cualquier software tiene actores que depende de él. El tiempo dedicado a
entender sus necesidades es una inversión de alto apalancamiento en el
éxito del proyecto. Usted nunca va a obtener requisitos perfectos, el
objetivo es acumular una comprensión compartida de los requisitos que
sea lo suficientemente buena como para permitir la construcción de la
siguiente parte del producto, ya sea el 1 por ciento o el 100 por ciento de
todo el producto, para proceder a un nivel de riesgo aceptable.

Para concluir, unas palabras de Frederick Brooks: “La parte más difícil de
construir un sistema de software es decidir exactamente qué construir.
Ninguna otra parte del trabajo conceptual es tan difícil como establecer los
requisitos técnicos detallados, incluyendo todas las interfaces con las
personas, las máquinas y otros sistemas de software. Ninguna otra parte
del trabajo paralizará tanto el sistema resultante si se hace mal. Ninguna
otra parte es más difícil de rectificar más tarde”.