4

Ingeniería de requerimientos

Objetivos

El objetivo de este capítulo es introducir requisitos de software y explicar los

procesos involucrados en descubrir y documentar estos requisitos. Cuando

haya leído el capítulo, usted:

comprender los conceptos de los requisitos del usuario y del sistema y por qué

estos requisitos deben escribirse de diferentes maneras;

comprender las diferencias entre los requisitos de software OA y funcionales y

no funcionales; E Yo O m entiendo los requisitos principales de las actividades

de ingeniería de obtención, análisis y validación, y las relaciones entre estas

actividades;

Comprenda por qué es necesaria la gestión de requisitos y cómo apoya otras

actividades de ingeniería de requisitos

Contenido

4.1 Requisitos funcionales y no funcionales

4.2 Procesos de ingeniería de requisitos

4.3 Obtención de requisitos

4.4 Especificación de requisitos

4.5 Validación de requisitos

4.6 Cambio de requisitos

Capítulo4 = Ingeniería de requisitos

Ingeniería de requerimientos

Los requisitos para un sistema son las descripciones de los servicios que un

sistema debe proporcionar y las restricciones sobre su funcionamiento. Estos

requisitos reflejan las necesidades de los clientes de un sistema que cumple un

determinado propósito, como controlar un dispositivo, realizar un pedido o

buscar información. El proceso de descubrir, analizar, documentar y verificar

estos servicios y restricciones se denomina ingeniería de requisitos (RE).

El término requisito no se usa de manera consistente en la industria del

software. En algunos casos, un requisito es simplemente una declaración

abstracta de alto nivel de un servicio que un sistema debe proporcionar o una

restricción en un sistema. En el otro extremo, es una definición formal detallada

de una función del sistema. Davis (Davis 1993) explica por qué existen estas

diferencias:

Si una compañía desea dejar un contrato para un gran proyecto de desarrollo

de software, debe definir sus necesidades de una manera suficientemente

abstracta para que una solución no esté predefinida. Los requisitos deben estar

escritos para que varios contratistas puedan ofertar por el contrato, ofreciendo,
quizás, diferentes formas de satisfacer las necesidades de la organización del

cliente. Una vez que se ha adjudicado un contrato, el contratista debe escribir

una definición del sistema para el cliente con más detalle para que el cliente

comprenda y pueda validar lo que hará el software. Ambos documentos

pueden denominarse documento de requisitos para el sistema.

Algunos de los problemas que surgen durante el proceso de ingeniería de

requisitos son el resultado de no hacer una separación clara entre estos

diferentes niveles de descripción. Distingo entre ellos usando el término

requisitos de usuario para referirme a los requisitos abstractos de alto nivel y

los requisitos del sistema para hacer referencia a la descripción detallada de lo

que debe hacer el sistema. Los requisitos del usuario y los requisitos del

sistema se pueden definir de la siguiente manera:

1. Los requisitos del usuario son declaraciones, en un lenguaje natural más

diagramas, de qué servicios se espera que el sistema brinde a los usuarios del
sistema y las restricciones bajo las cuales debe operar. Los requisitos del
usuario pueden variar desde declaraciones generales de las características del
sistema requeridas hasta descripciones detalladas y precisas de la
funcionalidad del sistema.

2. Los requisitos del sistema son descripciones más detalladas de las

funciones, servicios y restricciones operativas del sistema de software. El
documento de requisitos del sistema (a veces denominado especificación
funcional) debe definir exactamente lo que se debe implementar. Puede ser
parte del contrato entre el comprador del sistema y los desarrolladores de
software.
Se necesitan diferentes tipos de requisitos para comunicar información sobre
un sistema a diferentes tipos de lectores. La Figura 4.1 ilustra la distinción entre
los requisitos del usuario y del sistema. Este ejemplo del sistema de
información de pacientes de atención de salud mental (Mentcare) muestra
cómo un requisito de usuario puede ampliarse a varios requisitos del sistema.
Puede ver en la Figura 4.1 que el requisito del usuario es bastante
general. Los requisitos del sistema proporcionan información más específica
sobre los servicios y funciones del sistema que se implementará.

Figura 4.1 Requisitos del usuario y del sistema

Definición de requerimientos de usuario:

1- El sistema Mentcare generará informes mensuales de gestión.
mostrando el costo de los medicamentos recetados por cada clínica
durante ese mes.

Definición de Especificación de requerimientos del sistema:

1.1 El último día hábil de cada mes, se generará un resumen de los
medicamentos recetados, su costo y las clínicas de prescripción.
1.2 El sistema generará el informe para imprimir después de las 17.30 del
último día hábil del mes.
1.3 Se creará un informe para cada clínica y se enumerarán los nombres
individuales de los medicamentos, el número total de recetas, el número de
dosis prescritas y el costo total de los medicamentos recetados.
1.4 Si los medicamentos están disponibles en diferentes unidades de dosis (por
ejemplo, 10 mg, 20 mg, etc.), se crearán informes separados para cada unidad
de dosis.
1.5 El acceso a los informes de costos de medicamentos se restringirá a los
usuarios autorizados que figuran en una lista de control de acceso de gestión.

Figura 4.2 Lectores de diferentes tipos de especificación de requisitos

Definición de requisitos del usuario Especificación de requisitos del sistema.
Requerimientos de usuarios del sistema:
Gerentes de clientes.
Sistema de usuarios finales.
Ingenieros de clientes.
Gerentes de contratistas.
Arquitectos de sistemas.

Requerimientos del del sistema:

Sistema de usuarios finales.

Ingenieros de clientes

Arquitectos de sistemas.

Desarrolladores de software

Estudios de viabilidad

Un estudio de viabilidad es un estudio breve y centrado que debe realizarse al

principio del proceso de ER. Debería responder tres preguntas clave: (1) ¿El
sistema contribuye a los objetivos generales de la organización? (2) ¿Se puede

implementar el sistema dentro del cronograma y el presupuesto utilizando la

tecnología actual? y (3) ¿Se puede integrar el sistema con otros sistemas que

se utilizan?

Si la respuesta a cualquiera de estas preguntas es no, probablemente no

debería continuar con el proyecto.

Debe escribir los requisitos en diferentes niveles de detalle porque los diferentes

tipos de lectores los usan de diferentes maneras. La Figura 4.2 muestra los tipos

de lectores del usuario y los requisitos del sistema. Los lectores de los requisitos

del usuario no suelen estar interesados en cómo se implementará el sistema y

pueden ser gerentes que no están interesados en las instalaciones detalladas

del sistema. Los lectores de los requisitos del sistema deben saber con mayor

precisión qué hará el sistema porque les preocupa cómo respaldará los procesos

comerciales o porque están involucrados en la implementación del sistema.

Los diferentes tipos de lectores de documentos que se muestran en la Figura 4.2

son ejemplos de partes interesadas del sistema. Además de los usuarios,

muchas otras personas tienen algún tipo de interés en el sistema. Las partes

interesadas del sistema incluyen a cualquier persona afectada por el sistema de

alguna manera y, por lo tanto, cualquier persona que tenga un interés legítimo
en él. Las partes interesadas van desde los usuarios finales de un sistema hasta

los gerentes y las partes interesadas externas, como los reguladores, que

certifican la aceptabilidad del sistema. Por ejemplo, las partes interesadas del

sistema para el sistema Mentcare incluyen:

1. Pacientes cuya información se registra en el sistema y familiares de estos

pacientes.

2. Médicos responsables de evaluar y tratar a los pacientes.

3. Enfermeras que coordinan las consultas con los médicos y administran

algunos tratamientos.

4. Recepcionistas médicos que manejan las citas de los pacientes.

5. Personal de TI responsable de instalar y mantener el sistema.

6. Un gerente de ética médica que debe asegurarse de que el sistema cumpla

con las pautas éticas actuales para la atención al paciente.

7. Gerentes de atención médica que obtienen información de gestión del sistema.

8. Personal de registros médicos que es responsable de garantizar que la

información del sistema se pueda mantener y preservar, y que los

procedimientos de mantenimiento de registros se hayan implementado

adecuadamente.

La ingeniería de requisitos generalmente se presenta como la primera etapa del

proceso de ingeniería de software. Sin embargo, es posible que deba

desarrollarse una cierta comprensión de los requisitos del sistema antes de

tomar la decisión de continuar con la adquisición o el desarrollo de un sistema.

Este RE en etapa inicial establece una visión de alto nivel de lo que el sistema

podría hacer y los beneficios que podría proporcionar. Estos pueden entonces

ser considerados en un estudio de factibilidad, que trata de evaluar si el sistema

es o no técnica y financieramente viable. Los resultados de ese estudio ayudan

a la gerencia a decidir si seguir adelante con la adquisición o el desarrollo del

sistema.

En este capítulo, presento una visión "tradicional" de los requisitos en lugar de

los requisitos en los procesos ágiles, que discutí en el Capítulo 3. Para la

mayoría de los sistemas grandes, todavía es el caso de que hay una fase de

ingeniería de requisitos claramente identificable antes de que comience la

implementación del sistema. El resultado es un documento de requisitos, que

puede ser parte del contrato de desarrollo del sistema. Por supuesto, se

realizan cambios posteriores a los requisitos, y los requisitos del usuario

pueden ampliarse a requisitos del sistema más detallados. En ocasiones, se

puede utilizar un enfoque ágil para obtener los requisitos de forma simultánea a

medida que se desarrolla el sistema para agregar detalles y refinar los

requisitos del usuario.

Requisitos funcionales y no funcionales.

4.1.1
Los requisitos del sistema de software a menudo se clasifican como requisitos

funcionales o no funcionales:

1. Requisitos funcionales Estas son declaraciones de servicios que el sistema

debe proporcionar, cómo debe reaccionar el sistema a entradas particulares y

cómo debe comportarse el sistema en situaciones particulares. En algunos

casos, los requisitos funcionales también pueden indicar explícitamente lo que

el sistema no debe hacer.

2. Requisitos no funcionales Estas son restricciones en los servicios o

funciones que ofrece el sistema. Incluyen restricciones de tiempo, restricciones

en el proceso de desarrollo y restricciones impuestas por los estándares. Los

requisitos no funcionales a menudo se aplican al sistema como un todo en

lugar de las características o servicios individuales del sistema.

En realidad, la distinción entre diferentes tipos de requisitos no es tan clara

como sugieren estas simples definiciones. Un requisito de usuario relacionado

con la seguridad, como una declaración que limite el acceso a usuarios

autorizados, puede parecer un requisito no funcional. Sin embargo, cuando se

desarrolla con más detalle, este requisito puede generar otros requisitos que

son claramente funcionales, como la necesidad de incluir servicios de

autenticación de usuarios en el sistema.

Esto muestra que los requisitos no son independientes y que un requisito a

menudo genera o restringe otros requisitos. Por lo tanto, los requisitos del

sistema no solo especifican los servicios o las características del sistema que

se requieren; también especifican la funcionalidad necesaria para garantizar

que estos servicios / características se entreguen de manera efectiva.

Los requisitos de dominio se derivan del dominio de aplicación del sistema en

lugar de las necesidades específicas de los usuarios del sistema. Pueden ser

nuevos requisitos funcionales por derecho propio, restringir los requisitos

funcionales existentes o establecer cómo deben llevarse a cabo cálculos

particulares.

El problema con los requisitos del dominio es que los ingenieros de software

pueden no comprender las características del dominio en el que opera el

sistema. Esto significa que estos ingenieros pueden no saber si se ha omitido o

no un requisito de dominio o si entra en conflicto con otros requisitos.

http://software-engineering-book.com/web/domain-requirements/

Requerimientos funcionales:

Los requisitos funcionales para un sistema describen lo que debe hacer el

sistema. Estos requisitos dependen del tipo de software que se está

desarrollando, los usuarios esperados del software y el enfoque general

adoptado por la organización al redactar los requisitos. Cuando se expresan

como requisitos del usuario, los requisitos funcionales deben estar escritos en

lenguaje natural para que los usuarios y administradores del sistema puedan

entenderlos. Los requisitos funcionales del sistema amplían los requisitos del

usuario y están escritos para desarrolladores de sistemas. Deben describir las

funciones del sistema, sus entradas y salidas, y las excepciones en detalle. Los

requisitos funcionales del sistema varían de los requisitos generales que

cubren lo que debe hacer el sistema a requisitos muy específicos que reflejan

las formas locales de trabajo o los sistemas existentes de una organización.

Por ejemplo, aquí hay ejemplos de requisitos funcionales: para el sistema

Mentcare, utilizados para mantener información sobre pacientes que reciben

tratamiento por problemas de salud mental:

Requisitos para el sistema Mentcare, utilizado para mantener información sobre

pacientes que reciben tratamiento para problemas de salud mental:

1. Un usuario podrá buscar en las listas de citas de todas las clínicas.

2. El sistema generará cada día, para cada clínica, una lista de pacientes que

se espera que asistan a las citas ese día.

3. Cada miembro del personal que use el sistema se identificará de manera

única por su número de empleado de ocho dígitos.

Estos requisitos del usuario definen la funcionalidad específica que se debe

incluir en el sistema. Los requisitos muestran que los requisitos funcionales

pueden escribirse en diferentes niveles de detalle (requisitos de contraste 1 y

3).

Los requisitos funcionales, como su nombre indica, se han centrado

tradicionalmente en lo que debe hacer el sistema. Sin embargo, si una

organización decide que un producto de software de sistema existente puede

satisfacer sus necesidades, entonces no tiene mucho sentido desarrollar una

especificación funcional detallada. En tales casos, el enfoque debe estar en el

desarrollo de requisitos de información que especifiquen la información

necesaria para que las personas hagan su trabajo. Los requisitos de

información especifican la información necesaria y cómo se debe entregar y

organizar. Por lo tanto, un requisito de información para el sistema Mentcare

podría especificar qué información se debe incluir en la lista de pacientes que

se esperan para las citas ese día.

La imprecisión en la especificación de los requisitos puede generar disputas

entre los clientes y los desarrolladores de software. Es natural que un

desarrollador de sistemas interprete un requisito ambiguo de una manera que

simplifique su implementación. A menudo, sin embargo, esto no es lo que el

cliente quiere. Se deben establecer nuevos requisitos y realizar cambios en el

sistema. Por supuesto, esto retrasa la entrega del sistema y aumenta los

costos.

Por ejemplo, el primer requisito del sistema Mentcare en la lista anterior

establece que un usuario podrá buscar en las listas de citas de todas las

clínicas. La razón de este requisito es que los pacientes con problemas de

salud mental a veces se confunden.

Es posible que tengan una cita en una clínica, pero en realidad van a otra

clínica. Si tienen una cita, se registrarán como atendidos, independientemente

de la clínica.

Un miembro del personal médico que especifique un requisito de búsqueda

puede esperar que "buscar" signifique que, dado un nombre de paciente, el

sistema busca ese nombre en todas las citas en todas las clínicas. Sin

embargo, esto no es explícito en el requisito. Los desarrolladores del sistema

pueden interpretar el requisito para que sea más fácil de implementar. Su

función de búsqueda puede requerir que el usuario elija una clínica y luego

realice la búsqueda de los pacientes que asistieron a esa clínica. Esto implica

más información del usuario y, por lo tanto, lleva más tiempo completar la

búsqueda.
Idealmente, la especificación de requisitos funcionales de un sistema debe ser

completa y consistente. La integridad significa que se deben definir todos los

servicios e información requeridos por el usuario. La coherencia significa que

los requisitos no deben ser contradictorios.

En la práctica, solo es posible lograr la consistencia y la integridad de los

requisitos para sistemas de software muy pequeños. Una razón es que es fácil

cometer errores y omisiones al escribir especificaciones para sistemas grandes

y complejos. Otra razón es que los sistemas grandes tienen muchas partes

interesadas, con diferentes antecedentes y expectativas. Es probable que las

partes interesadas tengan necesidades diferentes, y a menudo inconsistentes.

Estas inconsistencias pueden no ser obvias cuando los requisitos se

especifican originalmente, y los requisitos inconsistentes solo se pueden

descubrir después de un análisis más profundo o durante el desarrollo del

sistema.

requerimientos no funcionales

Los requisitos no funcionales, como su nombre indica, son requisitos que no

están directamente relacionados con los servicios específicos que el sistema

brinda a sus usuarios. Estos requisitos no funcionales generalmente

especifican o restringen las características del sistema en su conjunto. Pueden

relacionarse con propiedades emergentes del sistema, como la confiabilidad, el

tiempo de respuesta y el uso de la memoria. Alternativamente, pueden definir

restricciones en la implementación del sistema, como las capacidades de los

dispositivos de I/O como las representaciones de datos utilizadas en las

interfaces con otros sistemas.

Los requisitos no funcionales son a menudo más críticos que los requisitos

funcionales individuales. Los usuarios del sistema generalmente pueden

encontrar formas de evitar una función del sistema que realmente no satisface

sus necesidades. Sin embargo, el incumplimiento de un requisito no funcional

puede significar que todo el sistema no se puede utilizar. Por ejemplo, si un

sistema de aeronave no cumple con sus requisitos de confiabilidad, no será

certificado como seguro para la operación; Si un sistema de control integrado

no cumple con sus requisitos de rendimiento, las funciones de control no

funcionarán correctamente.

Si bien a menudo es posible identificar qué componentes del sistema

implementan requisitos funcionales específicos (por ejemplo, puede haber

componentes de formato que implementen requisitos de informes), esto a

menudo es más difícil con requisitos no funcionales. La implementación de

estos requisitos puede extenderse a todo el sistema, por dos razones:

1. Los requisitos no funcionales pueden afectar la arquitectura general de un

sistema en lugar de los componentes individuales. Por ejemplo, para garantizar

que se cumplan los requisitos de rendimiento en un sistema integrado, es

posible que deba organizar el sistema para minimizar las comunicaciones entre

los componentes.

Ingeniería de requisitos Requisitos externos Requisitos del producto

Requerimientos organizacionales requerimientos no funcionales El | Requisitos

de eficiencia requisitos requisitos requisitos Requisitos de usabilidad -

Confiabilidad | Seguridad | Regulatorio | Requisitos éticos Desarrollo Operativo

Ambiental Requisitos legislativos requisitos requisitos requisitos UNA]

requisitos Actuación Espacio —— Requisitos contables requisitos requisitos |

Seguridad / seguridad |

Figura 4.3 Tipos de requisitos no funcionales

2. Un requisito no funcional individual, como un requisito de seguridad, puede

generar varios requisitos funcionales relacionados que definen nuevos servicios

del sistema que se requieren si se va a implementar el requisito no funcional.

Además, también puede generar requisitos que limitan los requisitos existentes;

por ejemplo, puede limitar el acceso a la información en el sistema.

Los requisitos no funcionales surgen de las necesidades del usuario debido a la

restricción presupuestaria

limitaciones, políticas organizacionales, la necesidad de interoperabilidad con

otros sistemas de software o hardware, o factores externos tales como

regulaciones de seguridad o legislación de privacidad.

La figura 4.3 es una clasificación de los requisitos no funcionales. Puede ver en

este diagrama que los requisitos no funcionales pueden provenir de las

características requeridas del software (requisitos del producto), la organización

que desarrolla el software (requisitos de la organización) o fuentes externas:

Requisitos del producto Estos requisitos especifican o restringen el

comportamiento en tiempo de ejecución del software. Los ejemplos incluyen

requisitos de rendimiento para la rapidez con que debe ejecutarse el sistema y

la cantidad de memoria que requiere; requisitos de confiabilidad que establecen

la tasa de falla aceptable; requerimientos de seguridad; y requisitos de

usabilidad.

Requisitos organizativos Estos requisitos son requisitos generales del sistema

derivados de políticas y procedimientos en las organizaciones de clientes y

desarrolladores. Los ejemplos incluyen los requisitos del proceso operativo que

definen cómo se utilizará el sistema; requisitos del proceso de desarrollo que

especifican el lenguaje de programación; el entorno de desarrollo o las normas

de proceso que se utilizarán; y requisitos ambientales que especifican el

entorno operativo del sistema.

3. Requisitos externos Este amplio encabezado cubre todos los requisitos

derivados de factores externos al sistema y su proceso de desarrollo. Estos

pueden incluir requisitos reglamentarios que establecen lo que debe hacerse

para que el sistema sea aprobado para su uso por un regulador, como una

autoridad de seguridad nuclear; requisitos legislativos que deben seguirse para

garantizar que el sistema funcione dentro de la ley; y requisitos éticos que

aseguran que el sistema sea aceptable para sus usuarios y el público en

general.

Figura 4.4 Ejemplos de posibles

requisitos no funcionales para el
sistema Mentcare
REQUERIMIENTO DEL PRODUCTO El sistema Mentcare estará disponible

para todas las clínicas durante las horas normales de trabajo (lunes a viernes,

08: 30-17: 30). El tiempo de inactividad dentro de las horas normales de trabajo

no debe exceder los 5 segundos en un solo día.

REQUISITO ORGANIZACIONAL Los usuarios del sistema Mentcare se

identificarán utilizando su tarjeta de identidad de autoridad sanitaria.

REQUISITO EXTERNO El sistema implementará las disposiciones de

privacidad del paciente establecidas en HStan-03-2006-priv.

La Figura 4.4 muestra ejemplos de requisitos de producto, organización y
externos que podrían incluirse en la especificación del sistema Mentcare. El
requisito del producto es un requisito de disponibilidad que define cuándo debe
estar disponible el sistema y el tiempo de inactividad permitido cada día. No
dice nada sobre la funcionalidad del sistema Mentcare e identifica claramente
una restricción que los diseñadores del sistema deben tener en cuenta. El
requisito organizativo especifica cómo los usuarios se autentican en el sistema.
La autoridad de salud que opera el sistema se está moviendo a un
procedimiento de autenticación estándar para todo el software donde, en lugar
de que los usuarios tengan un nombre de inicio de sesión, deslizan su tarjeta
de identidad a través de un lector para identificarse. El requisito externo se
deriva de la necesidad de que el sistema cumpla con la legislación de
privacidad. La privacidad es obviamente un tema muy importante en los
sistemas de atención médica, y el requisito especifica que el sistema debe
desarrollarse de acuerdo con un estándar nacional de privacidad. Un problema
común con los requisitos no funcionales es que las partes interesadas
proponen los requisitos como objetivos generales, como la facilidad de uso, la
capacidad del sistema para recuperarse de una falla o la respuesta rápida del
usuario. Los objetivos establecen buenas intenciones pero causan problemas a
los desarrolladores del sistema, ya que dejan margen para la interpretación y la
disputa posterior una vez que se entrega el sistema. Por ejemplo, el siguiente
objetivo 1 del sistema es típico de cómo un gerente puede expresar los
requisitos de usabilidad: El sistema debe ser fácil de usar por el personal
médico y debe organizarse de tal manera que se minimicen los errores del
usuario.
Medida Y Velocidad tamaño Facilidad de uso Confiabilidad Robustez
Portabilidad Transacciones procesadas / segundo Usuario / tiempo de
respuesta del evento Tiempo de actualización de pantalla Megabytes / Número
de chips ROM Tiempo de entrenamiento Número de cuadros de ayuda Tiempo
medio de falla Probabilidad de indisponibilidad Tasa de ocurrencia de falla
Disponibilidad Tiempo para reiniciar después de la falla Porcentaje de eventos
que causan la falla Probabilidad de corrupción de datos en caso de falla
Porcentaje de declaraciones dependientes del objetivo Número de sistemas
objetivo Figura:
4.5 Métricas para especificar requisitos no funcionales

TI ha reescrito esto para mostrar cómo el objetivo podría expresarse como un

requisito no funcional "comprobable". Es imposible verificar objetivamente el

objetivo del sistema, pero en la siguiente descripción puede incluir al menos

instrumentación de software para contar los errores cometidos por los usuarios

cuando prueban el sistema.

El personal médico podrá utilizar todas las funciones del sistema después de

dos horas de capacitación. Después de esta capacitación, el número promedio

de errores cometidos por usuarios experimentados no debe exceder dos por

hora de uso del sistema.

Siempre que sea posible, debe escribir requisitos no funcionales

cuantitativamente para que puedan ser probados objetivamente. La Figura 4.5

muestra las métricas que puede usar para especificar propiedades del sistema

no funcionales. Puede medir estas características cuando el sistema se está

probando para verificar si el sistema ha cumplido o no con sus requisitos no

funcionales.

En la práctica, a los clientes de un sistema a menudo les resulta difícil traducir

sus objetivos en requisitos medibles. Para algunos objetivos, como la

mantenibilidad, no hay métricas simples que se puedan utilizar. En otros casos,

incluso cuando es posible la especificación cuantitativa, es posible que los

clientes no puedan relacionar sus necesidades con estas especificaciones. No

entienden qué significan algunos números que definen la confiabilidad (por

ejemplo) en términos de su experiencia cotidiana con los sistemas informáticos.

Además, el costo de verificar objetivamente los requisitos mensurables y no

funcionales puede ser muy alto, y los clientes que pagan por el sistema pueden

no pensar que estos costos están justificados.

Los requisitos no funcionales a menudo entran en conflicto e interactúan con

otros requisitos funcionales o no funcionales. Por ejemplo, el requisito de
identificación en la Figura 4.4 requiere que se instale un lector de tarjetas con
cada computadora que se conecta al sistema. Sin embargo, puede haber otro
requisito que solicite acceso móvil al sistema desde tabletas o teléfonos
inteligentes de médicos o enfermeras. Estos no son normalmente equipado con
lectores de tarjetas, por lo que, en estas circunstancias, puede ser necesario
algún método de identificación alternativo. Es difícil separar los requisitos
funcionales y no funcionales en el documento de requisitos. Si los requisitos no
funcionales se establecen por separado de los requisitos funcionales, las
relaciones entre ellos pueden ser difíciles de entender. Sin embargo, lo ideal es
resaltar los requisitos que están claramente relacionados con las propiedades
emergentes del sistema, como el rendimiento o la confiabilidad. Puede hacer
esto colocándolos en una sección separada del documento de requisitos o
distinguiéndolos, de alguna manera, de otros requisitos del sistema. Los
requisitos no funcionales como los requisitos de confiabilidad, seguridad y
confidencialidad son particularmente importantes para los sistemas críticos.
Cubro estos requisitos de confiabilidad en la Parte 2, que describe formas de
especificar los requisitos de confiabilidad y seguridad.

Procesos de ingeniería de requisitos.

Como discutí en el Capítulo 2, la ingeniería de requisitos involucra tres

actividades clave. Estos son los requisitos de descubrimiento al interactuar con

las partes interesadas (obtención y análisis); convertir estos requisitos en una

forma estándar (especificación); y comprobar que los requisitos realmente

definen el sistema que el cliente desea (validación). Los he mostrado como

procesos secuenciales en la Figura 2.4. Sin embargo, en la práctica, la

ingeniería de requisitos es un proceso iterativo en el que las actividades se

entrelazan.

La figura 4.6 muestra este entrelazado. Las actividades se organizan como un

proceso iterativo alrededor de una espiral. El resultado del proceso RE es un

documento de requisitos del sistema. La cantidad de tiempo y esfuerzo

dedicado a cada actividad en una iteración depende de la etapa del proceso

general, el tipo de sistema que se está desarrollando y el presupuesto

disponible.

Al principio del proceso, se dedicará la mayor parte del esfuerzo a comprender

los requisitos empresariales y no funcionales de alto nivel, y los requisitos del

usuario para el sistema. Más adelante en el proceso, en los anillos exteriores

de la espiral, se dedicará más esfuerzo a obtener y comprender los requisitos

no funcionales y los requisitos del sistema más detallados.

Este modelo en espiral acomoda enfoques de desarrollo donde los requisitos

se desarrollan con diferentes niveles de detalle. El número de iteraciones

alrededor de la espiral puede variar para que la espiral pueda salir después de

que se hayan obtenido algunos o todos los requisitos del usuario. El desarrollo

ágil se puede utilizar en lugar de la creación de prototipos para que los

requisitos y la implementación del sistema se desarrollen juntos.

En prácticamente todos los sistemas, los requisitos cambian. Las personas

involucradas desarrollan una mejor comprensión de lo que quieren que haga el

software; la organización que compra el sistema cambia; y se realizan

modificaciones en el hardware, el software y el entorno organizacional del

sistema. Los cambios deben gestionarse para comprender el impacto en otros

requisitos y las implicaciones de costo y sistema de realizar el cambio. T

discuta este proceso de gestión de requisitos en la Sección 4.6. 112

Figura 4.6 Una vista en espiral

de en

Capítulo 4 = Ingeniería de requisitos

Especificación de requisitos

Especificación de requisitos del sistema y modelado

Especificación de requisitos del usuario

Especificación de requisitos comerciales

Requisitos

Validación de requerimientos

sonsacamiento

Elicitación de requisitos del usuario

sonsacamiento

Prototipos

Comentarios

los requisitos

Requisitos del sistema documento de proceso de ingeniería

4.3 Obtención de requisitos

Los objetivos del proceso de obtención de requisitos son comprender el trabajo

que realizan las partes interesadas y cómo podrían utilizar un nuevo sistema

para ayudar a respaldar ese trabajo. Durante la obtención de requisitos, los

ingenieros de software trabajan con las partes interesadas para conocer el

dominio de la aplicación, las actividades de trabajo, los servicios y las

características del sistema que las partes interesadas desean, el rendimiento

requerido del sistema, el control del hardware

cepas, y así sucesivamente.

Es difícil obtener y comprender los requisitos de los interesados del sistema.

proceso por varias razones:

1. Las partes interesadas a menudo no saben lo que quieren de un sistema

informático, excepto en los términos más generales; pueden encontrar difícil

articular lo que quieren que haga el sistema; pueden hacer demandas poco

realistas porque no saben

lo que es y no es factible 4.3 == Obtención de requisitos 113

Figura 4.7 El proceso de obtención y análisis de requisitos.

1. Descubrimiento de requisitos y

comprensión 4. Requisitos 2. Clasificación de documentación de requisitos y

organización

3. Requisitos

priorización y negociación

Las partes interesadas en un sistema expresan naturalmente los requisitos en

sus propios términos y con un conocimiento implícito de su propio trabajo. Los

ingenieros de requisitos, sin experiencia en el dominio del cliente, pueden no

entender estos requisitos.

Diferentes partes interesadas, con diversos requisitos, pueden expresar sus

requisitos de diferentes maneras. Los ingenieros de requisitos tienen que

descubrir todas las fuentes potenciales de requisitos y descubrir elementos

comunes y conflictos.
Los factores políticos pueden influir en los requisitos de un sistema. Los

gerentes pueden exigir requisitos específicos del sistema porque estos les

permitirán aumentar su influencia en la organización.

El entorno económico y empresarial en el que se realiza el análisis es

dinámico. Inevitablemente cambia durante el proceso de análisis. La

importancia de requisitos particulares puede cambiar. Pueden surgir nuevos

requisitos de nuevos interesados que no fueron consultados originalmente.

En la figura 4.7 se muestra un modelo de proceso del proceso de obtención y

análisis.

Cada organización tendrá su propia versión o instancia de este modelo general,

dependiendo de factores locales como la experiencia del personal, el tipo de

sistema que se desarrolla y los estándares utilizados.

Las actividades del proceso son:

Descubrimiento y comprensión de los requisitos Este es el proceso de
interacción con las partes interesadas del sistema para descubrir sus
requisitos. Los requisitos de dominio de las partes interesadas y la
documentación también se descubren durante esta actividad. Clasificación y
organización de requisitos Esta actividad toma la colección no estructurada de
requisitos, agrupa los requisitos relacionados y los organiza en grupos
coherentes. Priorización y negociación de requisitos Inevitablemente, cuando
participan múltiples partes interesadas, los requisitos entrarán en conflicto. Esta
actividad tiene que ver con priorizar requisitos y encontrar y resolver conflictos
de requisitos a través de la negociación. Por lo general, las partes interesadas
deben reunirse para resolver las diferencias y acordar los requisitos de
compromiso.
puntos de vista Un punto de vista es una forma de recopilar y organizar un
conjunto de requisitos de un grupo de partes interesadas que tienen algo en
común. Por lo tanto, cada punto de vista incluye un conjunto de requisitos del
sistema. Los puntos de vista pueden provenir de usuarios finales, gerentes u
otros. Ayudan a identificar a las personas que pueden proporcionar información
sobre sus requisitos y estructurar los requisitos para el análisis.
http://www.software-engineering-book.com/web/viewpoints/
4. Documentación de requisitos "Los requisitos se documentan y se ingresan
en la siguiente ronda de la espiral.
En esta etapa se puede producir un borrador inicial de los documentos de
requisitos de software, o los requisitos pueden simplemente mantenerse
informalmente en pizarras, wikis u otros espacios compartidos. La Figura 4.7
muestra que la obtención y el análisis de requisitos es un proceso iterativo con
retroalimentación continua de cada actividad a otras actividades. El ciclo del
proceso comienza con el descubrimiento de requisitos y termina con la
documentación de requisitos. La comprensión del analista de los requisitos
mejora con cada ronda del ciclo. El ciclo finaliza cuando se ha producido el
documento de requisitos. Para simplificar el análisis de los requisitos, es útil
organizar y agrupar la información de los interesados. Una forma de hacerlo es
considerar a cada grupo de partes interesadas como un punto de vista y reunir
todos los requisitos de ese grupo en el punto de vista. También puede incluir
puntos de vista para representar requisitos de dominio y restricciones de otros
sistemas. Alternativamente, puede usar un modelo de la arquitectura del
sistema para identificar subsistemas y asociar requisitos con cada subsistema.
Inevitablemente, diferentes partes interesadas tienen diferentes puntos de vista
sobre la importancia y la prioridad de los requisitos, y a veces estos puntos de
vista son contradictorios. Si algunas partes interesadas consideran que sus
puntos de vista no se han considerado adecuadamente, entonces pueden
intentar deliberadamente socavar el proceso de ER. Por lo tanto, es importante
que organice reuniones periódicas de partes interesadas. Las partes
interesadas deben tener la oportunidad de expresar sus inquietudes y acordar

compromisos de requisitos .

En la etapa de documentación de requisitos, es importante que utilice un

lenguaje y diagramas simples para describir los requisitos. Esto hace posible
que las partes interesadas comprendan y comenten estos requisitos. Para
facilitar el intercambio de información, es mejor usar un documento compartido
(por ejemplo, en Google Docs u Office 365) o un wiki que sea accesible para
todas las partes interesadas.
Técnicas de obtención de requisitos.

La obtención de requisitos implica reunirse con partes interesadas de diferentes

tipos para descubrir información sobre el sistema propuesto. Puede
complementar esta información con conocimiento de los sistemas existentes y
su uso e información de documentos de diversos tipos. Debe dedicar tiempo a
comprender cómo trabajan las personas, qué producen, cómo usan otros
sistemas y cómo pueden necesitar cambiar para acomodar un nuevo sistema.
Existen dos enfoques fundamentales para la obtención de requisitos:
1. Entrevistas, donde hablas con las personas sobre lo que hacen.
2. Observación o etnografía, donde observas a las personas hacer su trabajo
para ver qué artefactos usan, cómo los usan, etc. Debe usar una combinación
de entrevistas y observación para recopilar información y, a partir de eso,
deriva los requisitos, que son la base para futuras discusiones.
4.3.1.1 Entrevistas:
Las entrevistas formales o informales con las partes interesadas del sistema
son parte de la mayoría de los procesos de ingeniería de requisitos. En estas
entrevistas, el equipo de ingeniería de requisitos hace preguntas a las partes
interesadas sobre el sistema que utilizan actualmente y el sistema a
desarrollar. Los requisitos se derivan de las respuestas a estas preguntas.
Las entrevistas pueden ser de dos tipos:
1. Entrevistas cerradas, donde el interesado responde a un conjunto
predefinido de preguntas.
2. Entrevistas abiertas, en las que no hay una agenda predefinida. El equipo
de ingeniería de requisitos explora una variedad de problemas con las partes
interesadas del sistema y, por lo tanto, desarrolla una mejor comprensión de
sus necesidades. En la práctica, las entrevistas con las partes interesadas son
normalmente una mezcla de ambos. Es posible que tenga que obtener la
respuesta a ciertas preguntas, pero estas generalmente conducen a otros
problemas que se discuten de una manera menos estructurada. Las
discusiones completamente abiertas rara vez funcionan bien. Por lo general,
tiene que hacer algunas preguntas para comenzar y mantener la entrevista
enfocada en el sistema a desarrollar. Las entrevistas son buenas para obtener
una comprensión general de lo que hacen los interesados, cómo pueden
interactuar con el nuevo sistema y las dificultades que enfrentan con los
sistemas actuales. A las personas les gusta hablar sobre su trabajo, por lo que
generalmente están felices de participar en entrevistas. Sin embargo, a menos
que tenga un prototipo de sistema para demostrar, no debe esperar que las
partes interesadas sugieran requisitos específicos y detallados. A todos les
resulta difícil visualizar cómo podría ser un sistema. Debe analizar la
información recopilada y generar los requisitos a partir de esto.

Obtener conocimiento del dominio a través de entrevistas puede ser difícil, por

dos razones:

1. Todos los especialistas en aplicaciones usan jerga específica para su área

de trabajo. Es imposible para ellos discutir los requisitos del dominio sin utilizar

esta terminología. Normalmente usan palabras de una manera precisa y sutil

que los ingenieros de requisitos pueden malinterpretar.

2. Algunos interesados conocen tanto el dominio que les resulta difícil explicarlo

o piensan que es tan fundamental que no vale la pena mencionarlo. Por

ejemplo, para un bibliotecario, no hace falta decir que todas las adquisiciones

se catalogan antes de agregarlas a la biblioteca. Sin embargo, esto puede no

ser obvio para el entrevistador, por lo que no se tiene en cuenta en los

requisitos.

Las entrevistas no son una técnica efectiva para obtener conocimiento sobre

los requisitos y limitaciones de la organización porque existen relaciones sutiles

de poder entre las diferentes personas de la organización. Las estructuras

organizativas publicadas rara vez coinciden con la realidad de la toma de

decisiones en una organización, pero los entrevistados pueden no desear

revelar la estructura real en lugar de la teórica a un extraño. En general, la

mayoría de las personas son reacias a discutir asuntos políticos y organizativos

que pueden afectar los requisitos.

Para ser un entrevistador efectivo, debe tener en cuenta dos cosas:

1. Debe ser de mente abierta, evitar ideas preconcebidas sobre los requisitos y

estar dispuesto a escuchar a las partes interesadas. Si la parte interesada

presenta requisitos sorprendentes, entonces debería estar dispuesto a cambiar

de opinión sobre el sistema.

2. Debe solicitar al entrevistado que inicie las discusiones utilizando una

pregunta de trampolín o una propuesta de requisitos, o trabajando juntos en un

sistema de prototipo. Es poco probable que decirle a la gente "dime lo que

quieres" resultará en información útil. Les resulta mucho más fácil hablar en un

contexto definido que en términos generales.

La información de las entrevistas se utiliza junto con otra información sobre el

sistema de la documentación que describe los procesos comerciales o los

sistemas existentes, las observaciones de los usuarios y la experiencia del

desarrollador.

A veces, además de la información en los documentos del sistema, la

información de la entrevista puede ser la única fuente de información sobre los

requisitos del sistema. Sin embargo, las entrevistas por sí solas pueden perder
información esencial y, por lo tanto, deben usarse junto con otras técnicas de

obtención de requisitos.

4.3.1.2 Etnografía

Los sistemas de software no existen de forma aislada. Se utilizan en un entorno

social y organizacional, y ese entorno puede generar o restringir los requisitos

del sistema de software. Una razón por la cual muchos sistemas de software se

entregan pero nunca se usan es que sus requisitos no tienen en cuenta

adecuadamente cómo los factores sociales y organizacionales afectan la

operación práctica del sistema. Por lo tanto, es muy importante que, durante el

proceso de ingeniería de requisitos, intente comprender los problemas sociales

y organizativos que afectan el uso del sistema. La etnografía es una técnica de

observación que se puede utilizar para comprender los procesos operativos y

ayudar a derivar los requisitos para que el software respalde estos procesos.

Un analista se sumerge en el entorno de trabajo donde 4.3

Se utilizará el sistema. Se observa el trabajo diario y se toman notas de las

tareas reales en las que participan los participantes. El valor de la etnografía es

que ayuda a descubrir los requisitos implícitos del sistema que reflejan las

formas reales en que trabajan las personas, en lugar de los procesos formales

definidos por la organización.

A las personas a menudo les resulta muy difícil articular los detalles de su

trabajo porque es una segunda naturaleza para ellos. Entienden su propio

trabajo pero pueden no entender su relación con otro trabajo en la

organización. Los factores sociales y organizativos que afectan el trabajo, pero

que no son obvios para las personas, solo pueden aclararse cuando un

observador imparcial lo advierte. Por ejemplo, un grupo de trabajo puede

autoorganizarse para que los miembros conozcan el trabajo del otro y puedan

cubrirse si alguien está ausente. Esto puede no mencionarse durante una

entrevista, ya que el grupo podría no verlo como una parte integral de su

trabajo.

Suchman (Suchman 1983) fue pionero en el uso de la etnografía para estudiar

el trabajo de oficina. Encontró que las prácticas laborales reales eran mucho

más ricas, más complejas y más dinámicas que los modelos simples asumidos

por los sistemas de automatización de oficinas.

La diferencia entre el trabajo asumido y el real fue la razón más importante por

la que estos sistemas de oficina no tuvieron un efecto significativo en la

productividad. Crabtree (Crabtree 2003) analiza una amplia gama de estudios

desde entonces y describe, en general, el uso de la etnografía en el diseño de

sistemas. En mi propia investigación, he investigado métodos para integrar la

etnografía en el proceso de ingeniería de software al vincularla con métodos de

ingeniería de requisitos (Viller y Sommerville 2000) y documentar patrones de

interacción en sistemas cooperativos (Martin y Sommerville 2004).

La etnografía es particularmente efectiva para descubrir dos tipos de requisitos:

1. Requisitos derivados de la forma en que las personas realmente trabajan, en

lugar de la forma en que las definiciones de procesos de negocios dicen que

deberían funcionar. En la práctica, las personas nunca siguen procesos

formales. Por ejemplo, los controladores de tráfico aéreo pueden apagar un

sistema de alerta de conflicto que detecta aeronaves con rutas de vuelo que se

cruzan, a pesar de que los procedimientos de control normales especifican que

debe usarse. El sistema de alerta de conflicto es sensible y emite advertencias

audibles incluso cuando los aviones están muy separados. Los controladores

pueden encontrar estas distracciones y prefieren utilizar otras estrategias para

garantizar que los aviones no estén en rutas de vuelo en conflicto.

2. Requisitos derivados de la cooperación y la conciencia de las actividades de

otras personas. Por ejemplo, ¿los controladores de tránsito aéreo (ATC)

pueden usar el conocimiento de otros controles? trabajar para predecir el

número de aeronaves que ingresarán a su sector de control. Luego modifican

sus estrategias de control en función de la carga de trabajo prevista. Por lo

tanto, un sistema ATC automatizado debería permitir a los controladores de un

sector tener cierta visibilidad del trabajo en sectores adyacentes.

La etnografía se puede combinar con el desarrollo de un prototipo de sistema

(Figura 4.8). La etnografía informa el desarrollo del prototipo para que se

requieran menos ciclos de refinamiento del prototipo. Además, la creación de

prototipos enfoca la etnografía identificando problemas y preguntas que luego

pueden discutirse con el etnógrafo. Luego debe buscar las respuestas a estas

preguntas durante la siguiente fase del estudio del sistema (Sommerville et al.

1993). 118 Capítulo4 = Ingeniería de requisitos

Sistema de etnografía enfocada en prototipos

Informe etnográfico

reuniones de análisis

Figura 4.8 Etnografía Sistema genérico y creación de prototipos para el

desarrollo

análisis de requerimientos

Evaluación de prototipo

La etnografía es útil para comprender los sistemas existentes, pero esta

comprensión no siempre ayuda con la innovación. La innovación es

particularmente relevante para el desarrollo de nuevos productos. Los

comentaristas han sugerido que Nokia utilizó la etnografía para descubrir cómo

las personas usaban sus teléfonos y desarrollaron nuevos modelos de

teléfonos sobre esa base; Apple, por otro lado, ignoró el uso actual y

revolucionó el móvil
industria telefónica con la introducción del iPhone. Los estudios etnográficos
pueden revelar detalles críticos del proceso que a menudo pasan por alto otras
técnicas de obtención de requisitos. Sin embargo, debido a su enfoque en el
usuario final, este enfoque no es efectivo para descubrir requisitos
organizativos o de dominio más amplios o para sugerencias de innovaciones.
Por lo tanto, debe usar la etnografía. como una de una serie de técnicas para la
obtención de requisitos.
4.3.2 Historias y escenarios A las personas les resulta más fácil relacionarse
con ejemplos de la vida real que con descripciones abstractas. No son buenos
para decirle los requisitos del sistema. Sin embargo, pueden describir cómo
manejan situaciones particulares o imaginar cosas que podrían hacer en una
nueva forma de trabajar. Las historias y los escenarios son formas de capturar
este tipo de información. Luego puede usarlos cuando entrevista a grupos de
partes interesadas para discutir el sistema con otras partes interesadas y
desarrollar un sistema más específico. requisitos Las historias y los escenarios
son esencialmente lo mismo. Son una descripción de cómo se puede usar el
sistema para alguna tarea en particular. Describen qué hacen las personas,
qué información usan y producen, y qué sistemas pueden usar en este
proceso. La diferencia está en la forma en que se estructuran las descripciones
y en el nivel de detalle presentado. Las historias se escriben como texto
narrativo y presentan una descripción de alto nivel del uso del sistema; Los
escenarios generalmente se estructuran con información específica recopilada,
como entradas y salidas. Encuentro que las historias son efectivas para
establecer el "panorama general". Las partes de las historias pueden
desarrollarse con más detalle y representarse como escenarios. La Figura 4.9
es un ejemplo de una historia que desarrollé para comprender los requisitos
para el entorno de aprendizaje digital ¡Aprenda que presenté en el Capítulo 1.
Esta historia describe una situación en una escuela primaria (primaria) donde el
maestro está utilizando el entorno para apoyar proyectos estudiantiles en la
industria pesquera. Puedes ver que esta es una descripción de muy alto nivel.
Su propósito es facilitar la discusión sobre cómo se podría usar el sistema
¡Aprende y actuar como un punto de partida para obtener los requisitos para
ese sistema
4.3 4 Obtención de requisitos 119 Compartir fotos en el aula

Figura 4.9 Una historia de usuario para el sistema ¡Learn

Jack es profesor de primaria en Ullapool (un pueblo en el norte de Escocia).
Decidió que un proyecto de clase debería centrarse en la industria pesquera de
la zona, observando la historia, el desarrollo y el impacto económico de la
pesca. Como parte de este proyecto, se pide a los alumnos que reúnan y
compartan recuerdos de sus familiares, usen archivos de periódicos y recojan
fotografías antiguas relacionadas con la pesca y las comunidades pesqueras
de la zona. Los alumnos usan un wiki de ¡Learn para reunir historias de pesca y
SCRAN (un sitio de recursos de historia) para acceder a archivos y fotografías
de periódicos. Sin embargo, Jack también necesita un sitio para compartir fotos
porque quiere que los alumnos tomen y comenten las fotos de los demás y
carguen escaneos de fotografías antiguas que puedan tener en sus familias.
Jack envía un correo electrónico al grupo de maestros de primaria, del cual es
miembro, para ver si alguien puede recomendar un sistema apropiado. Dos
maestros responden, y ambos sugieren que use KidsTakePics, un sitio para
compartir fotos que les permite a los maestros verificar y moderar el contenido.
Como KidsTakePics no está integrado con el servicio de autenticación ¡Learn,
configura un maestro y una cuenta de clase. Utiliza el servicio de configuración
¡Learn para agregar KidsTakePics a los servicios vistos por los alumnos en su
clase para que cuando inicien sesión, puedan usar inmediatamente el sistema
para cargar fotos desde sus dispositivos móviles y computadoras de clase.

La ventaja de las historias es que todos pueden relacionarse fácilmente con

ellas. Encontramos que este enfoque es particularmente útil para obtener
información de una comunidad más amplia de la que podríamos entrevistar de
manera realista. Pusimos a disposición las historias en un wiki e invitamos a
maestros y estudiantes de todo el país a comentar sobre ellas. Estas historias
de alto nivel no entran en detalles sobre un sistema, pero pueden desarrollarse
en escenarios más específicos. Los escenarios son descripciones de sesiones
de interacción de usuario de ejemplo. Creo que es mejor presentar escenarios
de manera estructurada en lugar de como texto narrativo. Las historias de
usuario utilizadas en métodos ágiles, como la Programación extrema, son en
realidad escenarios narrativos en lugar de historias generales para ayudar a
obtener requisitos. Un escenario comienza con un resumen de la interacción.
Durante el proceso de obtención, se agregan detalles para crear una
descripción completa de esa interacción. En su forma más general, un
escenario puede incluir:
l. Una descripción de lo que el sistema y los usuarios esperan cuando
comienza el escenario. Una descripción del flujo normal de eventos en el
escenario. Una descripción de lo que puede salir mal y cómo se pueden
manejar los problemas resultantes. Información sobre otras actividades que
podrían estar ocurriendo al mismo tiempo.

A Pp Py

Una descripción del estado del sistema cuando finaliza el escenario.

Como ejemplo de un escenario, la Figura 4.10 describe lo que sucede cuando

un estudiante sube fotos al sistema KidsTakePics, como se explica en la Figura

4.9. La diferencia clave entre este sistema y otros sistemas es que un maestro

modera las fotos cargadas para verificar que sean adecuadas para compartir.

Puede ver que esta es una descripción mucho más detallada que la historia de

la Figura 4.9, por lo que puede usarse para proponer requisitos para el sistema

¡Learn. Al igual que las historias, los escenarios se pueden usar para facilitar

las discusiones con las partes interesadas que a veces pueden tener diferentes

formas de lograr el mismo resultado.

Subir fotos a KidsTakePics

Supuesto inicial: un usuario o un grupo de usuarios tienen una o más

fotografías digitales para cargar en el sitio para compartir imágenes. Estas fotos

se guardan en una tableta o una computadora portátil. Han iniciado sesión con

éxito en KidsTakePics.

Normal: el usuario elige cargar fotos y se le solicita que seleccione las fotos

que se cargarán en la computadora y que seleccione el nombre del proyecto en

el que se almacenarán las fotos. Los usuarios también deben tener la opción
de ingresar palabras clave que deben asociarse con cada foto cargada. Las

fotos cargadas se nombran creando una conjunción del nombre de usuario con

el nombre de archivo de la foto en la computadora local.

Al finalizar la carga, el sistema envía automáticamente un correo electrónico al

moderador del proyecto, solicitándole que verifique el contenido nuevo, y

genera un mensaje en pantalla para el usuario que indica que esta verificación

se ha realizado.

Qué puede salir mal: ningún moderador está asociado con el proyecto

seleccionado. Se genera automáticamente un correo electrónico para el

administrador de la escuela pidiéndole que nomine a un moderador del

proyecto. Los usuarios deben ser informados de una posible demora en hacer

visibles sus fotos.

Las fotos con el mismo nombre ya han sido cargadas por el mismo usuario. Se

debe preguntar al usuario si desea volver a cargar las fotos con el mismo

nombre, cambiar el nombre de las fotos o cancelar la carga. Si los usuarios

eligen volver a subir las fotos, se sobrescriben los originales. Si eligen cambiar

el nombre de las fotos, se genera automáticamente un nuevo nombre

agregando un número al nombre de archivo existente.

Otras actividades: el moderador puede iniciar sesión en el sistema y puede

aprobar las fotos a medida que se cargan.

Estado del sistema al finalizar: el usuario ha iniciado sesión. Las fotos

seleccionadas se han cargado y se les ha asignado un estado "en espera de

moderación". Las fotos son visibles para el moderador y para el usuario que las

cargó.

Figura 4.10 Escenario para cargar fotos en KidsTakePics

Especificación de requisitos

La especificación de requisitos es el proceso de anotar los requisitos del

usuario y del sistema en un documento de requisitos. Idealmente, los requisitos

del usuario y del sistema deben ser claros, inequívocos, fáciles de entender,

completos y coherentes. En la práctica, esto es casi imposible de lograr. Las

partes interesadas interpretan los requisitos de diferentes maneras, y a menudo

hay conflictos inherentes e inconsistencias en los requisitos.

Los requisitos del usuario casi siempre se escriben en lenguaje natural

complementado con diagramas y tablas apropiadas en el documento de

requisitos. Los requisitos del sistema también se pueden escribir en lenguaje

natural, pero también se pueden usar otras anotaciones basadas en formas,

modelos de sistemas matemáticos o de forma esférica. La figura 4.11 resume

las posibles anotaciones para escribir los requisitos del sistema.

Los requisitos del usuario para un sistema deben describir los requisitos

funcionales y no funcionales para que sean entendibles por los usuarios del
sistema que no tienen un conocimiento técnico detallado. Idealmente, deberían

especificar solo el comportamiento externo del sistema. El documento de

requisitos no debe incluir detalles de la arquitectura o diseño del sistema. En

consecuencia, si está escribiendo requisitos de usuario, no debe usar jerga de

software, anotaciones estructuradas o anotaciones formales. Debe escribir los

requisitos del usuario en lenguaje natural, con tablas simples, formularios y

diagramas intuitivos.

4.4 E Especificación de requisitos 121

NE DE iieÍ

Lenguaje natural

frases

Estructurado natural

idioma

Notaciones gráficas

Especificaciones matematicas

Los requisitos se escriben usando oraciones numeradas en lenguaje natural.

Cada oración debe expresar un requisito.

Los requisitos están escritos en lenguaje natural en un formulario o plantilla

estándar. Cada campo proporciona información sobre un aspecto del requisito.

Los modelos gráficos, complementados con anotaciones de texto, se utilizan

para definir los requisitos funcionales del sistema. Los diagramas de uso y

secuencia de uso UML (lenguaje de modelado unificado) se usan comúnmente.

Estas anotaciones se basan en conceptos matemáticos como máquinas o

conjuntos de estados finitos. Aunque estas especificaciones inequívocas

pueden reducir la ambigüedad en un documento de requisitos, la mayoría de

los clientes no entienden una especificación formal. No pueden verificar que

represente lo que quieren y son reacios a aceptarlo como un contrato del

sistema. (Discuto este enfoque, en el Capítulo 10, que cubre la confiabilidad del

sistema).

Figura 4.11 Anotaciones

para sistema de escritura

requisitos

4.4.1

Los requisitos del sistema son versiones ampliadas de los requisitos del

usuario que los ingenieros de software utilizan como punto de partida para el

diseño del sistema. Añaden detalles y explican cómo el sistema debe

proporcionar los requisitos del usuario. Se pueden usar como parte del contrato

para la implementación del sistema y, por lo tanto, deben ser una

especificación completa y detallada de todo el sistema.

Idealmente, los requisitos del sistema solo deberían describir el

comportamiento externo del sistema y sus limitaciones operativas. No deben

preocuparse por cómo se debe diseñar o implementar el sistema. Sin embargo,

al nivel de detalle requerido para especificar completamente un sistema de

software complejo, no es posible ni deseable excluir toda la información de

diseño. Hay varias razones para esto:

1. Puede que tenga que diseñar una arquitectura inicial del sistema para

ayudar a estructurar la especificación de requisitos. Los requisitos del sistema

se organizan de acuerdo con los diferentes subsistemas que conforman el

sistema. Hicimos esto cuando definimos los requisitos para el sistema ¡Learn,

donde propusimos la arquitectura que se muestra en la Figura 1.8.

2. En la mayoría de los casos, los sistemas deben interactuar con los sistemas

existentes, lo que restringe el diseño e impone requisitos al nuevo sistema.

3. Puede ser necesario el uso de una arquitectura específica para satisfacer los

requisitos no funcionales, como la programación de la versión N para lograr la

confiabilidad, discutida en el Capítulo 11. Un regulador externo que necesita

certificar que el sistema es seguro puede especificar que se debe usar un

diseño arquitectónico que ya haya sido certificado.

Especificación del lenguaje natural

El lenguaje natural se ha utilizado para escribir requisitos para el software

desde la década de 1950. Es expresivo, intuitivo y universal. También es

potencialmente vago y ambiguo, y su interpretación depende de los

antecedentes del lector. Como resultado, hay 122 Capítulo4 == Ingeniería de

requisitos

3.2 El sistema medirá el azúcar en la sangre y administrará insulina, si es

necesario, cada 10 minutos. (Los cambios en el azúcar en la sangre son

relativamente lentos, por lo que una medición más frecuente es innecesaria;

una medición menos frecuente podría conducir a niveles de azúcar

innecesariamente altos).

3.6 El sistema ejecutará una rutina de autocomprobación cada minuto con las

condiciones a probar y las acciones asociadas definidas en la Tabla 1. (4 la

rutina de autocomprobación puede descubrir problemas de hardware y

software y alertar al usuario sobre el hecho de que la operación normal puede

ser imposible.)

Figura 4.12 Requisitos de ejemplo para el

software de bomba de insulina

sistema

4.4.2

Ha habido muchas propuestas de formas alternativas de redactar requisitos.

Sin embargo, ninguna de estas propuestas ha sido ampliamente adoptada, y el

lenguaje natural seguirá siendo la forma más utilizada de especificar los

requisitos del sistema y el software.

Para minimizar los malentendidos al escribir requisitos de lenguaje natural, le

recomiendo que siga estas pautas simples:

1. Inventa el formato estándar y asegura que todas las definiciones de

requisitos se adhieran a ese formato. La estandarización del formato hace que

las omisiones sean menos probables y los requisitos más fáciles de verificar.

Sugiero que, siempre que sea posible, debe escribir el requisito en una o dos

oraciones de lenguaje natural.

2. Use el lenguaje constantemente para distinguir entre los requisitos

obligatorios y los deseables. Los requisitos obligatorios son requisitos que el

sistema debe admitir y, por lo general, se escriben usando "debe". Los

requisitos deseables no son esenciales y se escriben usando "debería".

3. Utilice el resaltado de texto (negrita, cursiva o color) para seleccionar partes

clave del requisito.

4. No asuma que los lectores entienden el lenguaje técnico de ingeniería de

software. Es fácil que no se entiendan palabras como "arquitectura" y "módulo".

Siempre que sea posible, debe evitar el uso de jerga, abreviaturas y siglas.

5. Siempre que sea posible, debe intentar asociar una justificación con cada

requisito del usuario. La razón debe explicar por qué se ha incluido el requisito

y quién propuso el requisito (la fuente del requisito), para que sepa a quién

consultar si el requisito tiene que cambiarse. La justificación de los requisitos es

particularmente útil cuando se cambian los requisitos, ya que puede ayudar a

decidir qué cambios serían indeseables.

La figura 4.12 ilustra cómo se pueden usar estas pautas. Incluye dos requisitos

para el software integrado para la bomba de insulina automatizada, presentado

en el Capítulo 1. Otros requisitos para este sistema integrado se definen en el

documento de requisitos de la bomba de insulina, que puede descargarse de

las páginas web del libro.

Especificaciones estructuradas

El lenguaje natural estructurado es una forma de escribir los requisitos del

sistema donde los requisitos se escriben de forma estándar en lugar de como

texto de forma libre. Este enfoque mantiene la mayor parte de la expresividad y

la comprensibilidad del lenguaje natural, pero 4.4 E Especificación de requisitos

123

O Problemas con el uso del lenguaje natural para la especificación de

requisitos. La flexibilidad del lenguaje natural, que es tan útil para la

especificación, a menudo causa problemas. Hay margen para escribir

requisitos poco claros, y los lectores (los diseñadores) pueden malinterpretar

los requisitos porque tienen una formación diferente para el usuario. Es fácil

fusionar varios requisitos en una sola oración, y estructurar los requisitos del

lenguaje natural puede ser difícil.

http://software-engineering-book.com/web/natural-language/

asegura que se imponga cierta uniformidad en la especificación. Las

anotaciones de lenguaje estructurado usan plantillas para especificar los

requisitos del sistema. La especificación puede usar construcciones de

lenguaje de programación para mostrar alternativas e iteraciones, y puede

resaltar elementos clave usando sombreado o fuentes diferentes.

Los Robertson (Robertson y Robertson 2013), en su libro sobre el método de

ingeniería de requisitos VOLERE, recomiendan que los requisitos del usuario

se escriban inicialmente en tarjetas, un requisito por tarjeta. Sugieren una serie

de campos en cada tarjeta, como la justificación de los requisitos, las

dependencias de otros requisitos, la fuente de los requisitos y los materiales de

apoyo. Esto es similar al enfoque utilizado en el ejemplo de una especificación

estructurada que se muestra en la Figura 4.13.

Para utilizar un enfoque estructurado para especificar los requisitos del

sistema, defina una o más plantillas estándar para los requisitos y represente

estas plantillas como formularios estructurados. La especificación puede

estructurarse en torno a los objetos manipulados por el sistema, las funciones

realizadas por el sistema o los eventos procesados por el sistema. En la Figura

4.13 se muestra un ejemplo de una especificación basada en formularios, en

este caso, una que define cómo calcular la dosis de insulina que se

administrará cuando el azúcar en la sangre está dentro de una banda segura.

Cuando se utiliza un formato estándar para especificar requisitos funcionales,

se debe incluir la siguiente información:

1. Una descripción de la función o entidad que se especifica.

2. Una descripción de sus entradas y el origen de estas entradas.

3. Una descripción de sus salidas y el destino de estas salidas.

4. Información sobre la información necesaria para el cálculo u otras entidades

en el sistema que se requieren (la parte "requiere").

5. Una descripción de la acción a tomar.

Si se utiliza un enfoque funcional, una condición previa que establece lo que

debe ser verdadero antes de que se llame a la función, y una condición

posterior que especifica qué es verdadero después de que se llama a la

función.

7. Una descripción de los efectos secundarios (1f cualquiera) de la operación.

El uso de especificaciones estructuradas elimina algunos de los problemas de

la especificación del lenguaje natural. La variabilidad en la especificación se

reduce y los requisitos están

Bomba de insulina / Software de control / SRS / 3.3.2

Función descriptiva

Entradas Fuente Salidas Destino Acción:

Requiere precondición Poscondición Efectos secundarios

Figura 4.13 El

Calcular la dosis de insulina: nivel de azúcar seguro.

Calcula la dosis de insulina que se administrará cuando el nivel de azúcar

medido actual esté en la zona segura entre 3 y 7 unidades.

Lectura actual de azúcar (r2), las dos lecturas anteriores (rO y r1). Lectura

actual de azúcar del sensor. Otras lecturas de memoria. CompDose: la dosis

de insulina que se administrará.

Bucle de control principal.

CompDose es cero si el nivel de azúcar es estable o está disminuyendo o si el

nivel está aumentando pero la tasa de aumento está disminuyendo. Si el nivel

aumenta y la tasa de aumento aumenta, entonces CompDose se calcula

dividiendo la diferencia entre el nivel de azúcar actual y el nivel anterior entre 4

y redondeando el resultado. Si el resultado se redondea a cero, CompDose se

establece en la dosis mínima que se puede administrar. (ver Figura 4.14)

Dos lecturas previas para poder calcular la tasa de cambio del nivel de azúcar.

El depósito de insulina contiene al menos la dosis única máxima permitida de

insulina. rO se reemplaza por r1 y luego r1 se reemplaza por r2.

Ninguna.
especificación estructurada

de un requisito para una bomba de insulina

Figura 4.14 La especificación tabular del cálculo en una bomba de insulina

más eficazmente. Sin embargo, a veces todavía es difícil escribir los requisitos

de una manera clara y sin ambigüedades, particularmente cuando se deben

especificar cálculos complejos (por ejemplo, cómo calcular la dosis de insulina).

Para resolver este problema, puede agregar información adicional a los

requisitos del lenguaje natural, por ejemplo, utilizando tablas o modelos

gráficos del sistema. Estos pueden mostrar cómo proceden los cálculos, cómo

cambia el estado del sistema, cómo interactúan los usuarios con el sistema y

cómo se realizan las secuencias de acciones.

Las tablas son particularmente útiles cuando hay una serie de posibles

situaciones alternativas y necesita describir las acciones a tomar para cada una

de ellas. La bomba de insulina basa sus cálculos del requerimiento de insulina

en la tasa de cambio de los niveles de azúcar en la sangre. Las tasas de

cambio se calculan utilizando las lecturas actuales y anteriores. La figura 4.14

es una descripción tabular de cómo se usa la tasa de cambio de azúcar en la

sangre para calcular la cantidad de insulina que se administrará.

Condición ito)
Caída del nivel de azúcar (r2 <r1) CompDose = 0

Nivel de azúcar estable (r2 = r1) CompDose = 0

Aumento del nivel de azúcar y tasa de aumento CompDose = 0

decreciente ((r2 - r1) <(r1 —r0))

Aumento del nivel de azúcar y tasa de aumento CompDose estable = redondo

((r2 - r1) / 4) o aumento de r2> r1 8 ((r2 —r1) = (r1 - r0)) Si el resultado

redondeado = O entonces

CompDose = Dosis mínima

4.4 E Especificación de requisitos 125 Registro Exportar estadísticas de

pacientes q Ver Administrador Generar informe

UNA

Recepcionista medico

2 >> 2. Médico

Consulta de configuración de enfermería

información personal.

Figura 4.15 Casos de uso para el sistema Mentcare

4.4.3 Casos de uso

Los casos de uso son una forma de describir las interacciones entre los

usuarios y un sistema utilizando un modelo erafico y texto estructurado. Se

introdujeron por primera vez en el método Objectory (Jacobsen et al. 1993) y

ahora se han convertido en una característica fundamental del lenguaje de

modelado unificado (UML). En su forma más simple, un caso de uso identifica a

los actores involucrados en una interacción y nombra el tipo de interacción.

Luego agrega información adicional que describe la interacción con el sistema.

La información adicional puede ser una descripción textual o uno o más

modelos gráficos, como la secuencia UML o los cuadros de estado (consulte el

Capítulo 5).

Los casos de uso se documentan mediante un diagrama de casos de uso de

alto nivel. El conjunto de casos de uso representa todas las posibles

interacciones que se describirán en los requisitos del sistema. Los actores en el

proceso, que pueden ser humanos u otros sistemas, están representados como

figuras de palo. Cada clase de interacción se representa como una elipse con

nombre. Las líneas vinculan a los actores con la interacción. Opcionalmente, se

pueden agregar puntas de flecha a las líneas para mostrar cómo se inicia la

interacción. Esto se ilustra en la Figura 4.15, que muestra algunos de los casos

de uso del sistema Mentcare.

Los casos de uso identifican las interacciones individuales entre el sistema y

sus usuarios u otros sistemas. Cada caso de uso debe documentarse con una

descripción textual. Estos se pueden vincular a otros modelos en el UML que

desarrollarán el escenario con más detalle. Por ejemplo, una breve descripción

del caso de uso de Consulta de instalación de la Figura 4.15 podría ser:

La consulta de configuración permite que dos o más médicos, que trabajan en

diferentes consultorios, vean el mismo registro de pacientes al mismo tiempo.

Un médico inicia la consulta eligiendo a las personas involucradas de un menú

desplegable de médicos que están en línea. El registro del paciente se muestra

en sus pantallas, pero solo el médico que inicia puede editar el registro.

Además, se crea una ventana de chat de texto

para ayudar a coordinar acciones. Se supone que una llamada telefónica para

la comunicación de voz se puede organizar por separado.

El UML es un estándar para el modelado orientado a objetos, por lo que los

casos de uso y la obtención basada en casos de uso se utilizan en el proceso

de ingeniería de requisitos. Sin embargo, mi experiencia con los casos de uso

es que son demasiado finos para ser útiles para analizar los requisitos. Las

partes interesadas no entienden el término caso de uso; no encuentran útil el

modelo gráfico y, a menudo, no les interesa una descripción detallada de cada

interacción del sistema. En consecuencia, considero que los casos de uso son

más útiles en el diseño de sistemas que en la ingeniería de requisitos. Discuto

los casos de uso más adelante en el Capítulo 5, que muestra cómo se usan

junto con otros modelos de sistema para documentar un diseño de sistema.

Algunas personas piensan que cada caso de uso es un escenario de

interacción único de bajo nivel. Otros, como Stevens y Pooley (Stevens y

Pooley 2006), sugieren que cada caso de uso incluye un conjunto de

escenarios relacionados de bajo nivel. Cada uno de estos escenarios es un hilo

único a través del caso de uso. Por lo tanto, habría un escenario para la

interacción normal más escenarios para cada posible excepción. En la práctica,

puede usarlos de cualquier manera.

El documento de requisitos de software

El documento de requisitos de software (a veces llamado la especificación de

requisitos de software o SRS) es una declaración oficial de lo que los

desarrolladores de sistemas deben implementar. Puede incluir tanto los

requisitos del usuario para un sistema como una especificación detallada de los

requisitos del sistema. En ocasiones, los requisitos del usuario y del sistema se

integran en una sola descripción. En otros casos, los requisitos del usuario se

describen en un capítulo introductorio en la especificación de requisitos del

sistema.

Los documentos de requisitos son esenciales cuando los sistemas se

subcontratan para el desarrollo, cuando diferentes equipos desarrollan

diferentes partes del sistema y cuando es obligatorio un análisis detallado de

los requisitos. En otras circunstancias, como el desarrollo de productos de

software o sistemas de negocios, puede que no se necesite un documento de

requisitos detallado.

Los métodos ágiles sostienen que los requisitos cambian tan rápidamente que

un documento de requisitos está desactualizado tan pronto como está escrito,

por lo que el esfuerzo se desperdicia en gran medida. En lugar de un

documento formal, los enfoques ágiles a menudo recopilan los requisitos de los

usuarios de forma gradual y los escriben en tarjetas o pizarras como historias

cortas de los usuarios. Luego, el usuario prioriza estas historias para su

implementación en el próximo incremento del sistema.

Para los sistemas empresariales donde los requisitos son inestables, creo que

este enfoque es bueno. Sin embargo, creo que todavía es útil escribir un breve

documento de respaldo que defina los requisitos comerciales y de confiabilidad

del sistema; Es fácil olvidar los requisitos que se aplican al sistema en su

conjunto al centrarse en los requisitos funcionales para la próxima versión del

sistema.

El documento de requisitos tiene un conjunto diverso de usuarios, que van

desde la alta gerencia de la organización que paga el sistema hasta los

ingenieros responsables del desarrollo del software. La figura 4.16 muestra los

posibles usuarios del documento y cómo lo usan. 4.4 5 Especificación de

requisitos 127
Figura 4.16 Usuarios de un documento de requisitos

Especifique los requisitos y léalos para verificar que satisfacen sus

necesidades. Los clientes especifican cambios a los requisitos.

Clientes del sistema

Use el documento de requisitos para planificar una oferta para el sistema y

para planificar el proceso de desarrollo del sistema.

Gerentes

Use los requisitos para comprender qué sistema se va a desarrollar.

Ingenieros de sistemas

Prueba del sistema Utilice los requisitos para que los ingenieros desarrollen

pruebas de validación para el sistema.

SIGLO DE DELE

Use los requisitos para comprender el sistema y las relaciones entre sus

partes.

Ingenieros de mantenimiento del sistema

La diversidad de posibles usuarios significa que el documento de requisitos

debe ser un compromiso. Tiene que describir los requisitos para los clientes,

definir los requisitos en detalle preciso para desarrolladores y probadores, así

como incluir información sobre la evolución futura del sistema. La información

sobre los cambios anticipados ayuda a los diseñadores de sistemas a evitar

decisiones de diseño restrictivas y a los ingenieros de mantenimiento a adaptar

el sistema a los nuevos requisitos.

El nivel de detalle que debe incluir en un documento de requisitos depende del

tipo de sistema que se está desarrollando y del proceso de desarrollo utilizado.

Los sistemas críticos necesitan requisitos detallados porque la seguridad y la

protección deben analizarse en detalle para encontrar posibles errores de

requisitos. Cuando el sistema debe ser desarrollado por una compañía

separada (por ejemplo, a través de la contratación externa), las

especificaciones del sistema deben ser detalladas y precisas. Si se utiliza un

proceso de desarrollo iterativo interno, el documento de requisitos puede ser

menos detallado. Se pueden agregar detalles a los requisitos y ambigüedades

resueltos durante el desarrollo del sistema.

La Figura 4.17 muestra una posible organización para un documento de

requisitos que se basa en un estándar IEEE para documentos de requisitos

(IEEE 1998). Este estándar es genérico y se puede adaptar a usos específicos.

En este caso, el estándar se ha ampliado para incluir información sobre la

evolución prevista del sistema. Esta información ayuda a los encargados del

mantenimiento del sistema y permite a los diseñadores incluir soporte para

futuras funciones del sistema. 128 Capítulo4 Ingeniería de requisitos de HE

Capítulo DEA

Prefacio Esto define los lectores esperados del documento y describe su

historial de versiones, incluida una justificación para la creación de una nueva

versión y un resumen de los cambios realizados en cada versión.

Introducción Esto describe la necesidad del sistema. Debe describir

brevemente las funciones del sistema y explicar cómo funcionará con otros

sistemas. También debe describir cómo el sistema se ajusta a los objetivos

comerciales o estratégicos generales de la organización que encarga el

software.

Glosario Define los términos técnicos utilizados en el documento. No debe

hacer suposiciones sobre la experiencia o los conocimientos del lector. Usuario

Aquí, usted describe los servicios provistos para el usuario. Los requisitos de

requisitos del sistema no funcionales también deben describirse en esta

sección. Esta descripción puede usar lenguaje de definición natural, diagramas

u otras anotaciones que sean comprensibles para los clientes. Deben

especificarse los estándares de producto y proceso que deben seguirse.

Sistema Este capítulo presenta una descripción general de alto nivel de la

arquitectura del sistema anticipada, mostrando a la arquitectura la distribución

de funciones entre los módulos del sistema. Los componentes arquitectónicos

que se reutilizan deben resaltarse. Sistema Esto describe los requisitos

funcionales y no funcionales con más detalle. Si es necesario, también se

pueden agregar detalles adicionales a los requisitos no funcionales. Se pueden

definir interfaces con otros sistemas de especificación.

Sistema Este capítulo incluye modelos de sistemas gráficos que muestran las

relaciones entre los componentes del sistema de modelos y el sistema y su

entorno. Ejemplos de posibles modelos son modelos de objetos, modelos de

flujo de datos o modelos de datos semánticos. Sistema Describe los supuestos

fundamentales en los que se basa el sistema, y cualquier evolución anticipa

cambios debido a la evolución del hardware, las necesidades cambiantes del

usuario, etc. Esta

La sección es útil para los diseñadores de sistemas, ya que puede ayudarlos a

evitar decisiones de diseño que limitarían los posibles cambios futuros en el

sistema.

Apéndices Proporcionan información detallada y específica relacionada con la

aplicación que se está desarrollando, por ejemplo, descripciones de hardware y

bases de datos. Los requisitos de hardware definen las configuraciones

mínimas y óptimas para el sistema. Los requisitos de la base de datos definen

la organización lógica de los datos utilizados por el sistema y las relaciones

entre los datos.

Índice Se pueden incluir varios índices del documento. Además de un índice

alfabético normal, puede haber un índice de diagramas, un índice de funciones,

etc.
Figura 4.17 La estructura de un requisito OCUTACIÓN Naturalmente, la
información incluida en un documento de requisitos depende de tipo de
software que se está desarrollando y el enfoque de desarrollo que se utilizará.
Se podría producir un documento de requisitos con una estructura como la que
se muestra en la Figura 4.17 para un sistema de ingeniería complejo que
incluye hardware y software desarrollado por diferentes compañías. Es
probable que el documento de requisitos sea largo y detallado. Por lo tanto, es
importante incluir una tabla completa de contenido e índice de documentos
para que los lectores puedan encontrar fácilmente la información que
necesitan. Por el contrario, el documento de requisitos para un producto de
software interno dejará de lado muchos de los capítulos detallados sugeridos
anteriormente. La atención se centrará en definir los requisitos del usuario y los
requisitos del sistema no funcionales de alto nivel. Los diseñadores y
programadores del sistema utilizan su criterio para decidir cómo cumplir con los
requisitos de usuario del sistema.
Normas del documento de requisitos Varias organizaciones grandes, como el
Departamento de Defensa de EE. UU. Y el IEEE, han definido estándares para
los documentos de requisitos. Suelen ser muy genéricos pero, sin embargo,
son útiles como base para desarrollar estándares organizacionales más
detallados. El Instituto de Ingenieros Eléctricos y Electrónicos de EE. UU.
(IEEE) es uno de los proveedores de estándares más conocidos, y han
desarrollado un estándar para la estructura de los documentos de requisitos.
Este estándar es el más apropiado para sistemas como el comando militar y los
sistemas de control que tienen una larga vida útil y generalmente son
desarrollados por un grupo de organizaciones. http://software-engineering-
book.com/web/requirements-standard/ Validación de requerimientos La
validación de requisitos es el proceso de verificar que los requisitos definen el
sistema que el cliente realmente desea. Se superpone con la obtención y el
análisis, ya que se ocupa de encontrar problemas con los requisitos. La
validación de requisitos es de vital importancia porque los errores en un
documento de requisitos pueden generar costos de reprocesamiento extensos
cuando se descubren estos problemas durante el desarrollo o después de que
el sistema esté en servicio. El costo de solucionar un problema de requisitos
haciendo un cambio en el sistema suele ser mucho mayor que reparar errores
de diseño o codificación. Un cambio en los requisitos generalmente significa
que el diseño y la implementación del sistema también deben cambiarse.
Además, el sistema debe volver a probarse. Durante el proceso de validación
de requisitos, se deben llevar a cabo diferentes tipos de verificaciones de los
requisitos en el documento de requisitos. Estos controles incluyen:
l. Verificaciones de validez Verifican que los requisitos reflejen las necesidades

reales de los usuarios del sistema. Debido a circunstancias cambiantes, los

requisitos del usuario pueden haber cambiado desde que se obtuvieron

originalmente.

2. Verificaciones de consistencia Los requisitos en el documento no deben

entrar en conflicto. Es decir, no debe haber restricciones contradictorias o

diferentes descripciones de la misma función del sistema.

3. Verificaciones de integridad El documento de requisitos debe incluir

requisitos que definan todas las funciones y las restricciones previstas por el

usuario del sistema.

4. Verificaciones del realismo Al utilizar el conocimiento de las tecnologías

existentes, se deben verificar los requisitos para garantizar que puedan

implementarse dentro del presupuesto propuesto para el sistema. Estas

verificaciones también deben tener en cuenta el presupuesto y el cronograma

para el desarrollo del sistema.

5. Verificabilidad Para reducir la posibilidad de disputa entre el cliente y el

contratista, los requisitos del sistema siempre deben escribirse de manera que

sean verificables. Esto significa que debe poder escribir un conjunto de pruebas

que puedan demostrar que el sistema entregado cumple con cada requisito

especificado.

O Revisiones de requisitos
Una revisión de requisitos es un proceso en el que un grupo de personas del

cliente del sistema y del desarrollador del sistema leen el documento de

requisitos en detalle y verifican errores, anomalías e inconsistencias. Una vez

que se han detectado y registrado, corresponde al cliente y al desarrollador

negociar cómo se deben resolver los problemas identificados.

http://software-engineering-book.com/web/requirements-reviews/

Se pueden usar varias técnicas de validación de requisitos de forma individual

o en conjunto:

1. Revisiones de requisitos Los requisitos son analizados sistemáticamente por

un equipo de revisores que verifican errores e inconsistencias.

2. Creación de prototipos Esto implica desarrollar un modelo ejecutable de un

sistema y usarlo con usuarios finales y clientes para ver si

satisface sus necesidades y expectativas. Las partes interesadas experimentan

con el sistema y retroalimentan los cambios de requisitos al equipo de

desarrollo.

3. Generación de casos de prueba Los requisitos deben ser comprobables. Si

las pruebas para los requisitos se diseñan como parte del proceso de

validación, esto a menudo revela problemas de requisitos. Si una prueba es

difícil o imposible de diseñar, esto generalmente significa que los requisitos

serán difíciles de implementar y deben ser considerados. El desarrollo de

pruebas a partir de los requisitos del usuario antes de escribir cualquier código

es una parte integral del desarrollo basado en pruebas.

No debe subestimar los problemas involucrados en la validación de requisitos.

En última instancia, es difícil demostrar que un conjunto de requisitos realmente
satisface las necesidades de un usuario. Los usuarios necesitan visualizar el
sistema en funcionamiento e imaginar cómo ese sistema encajaría en su
trabajo. Es difícil incluso para los profesionales informáticos capacitados
realizar este tipo de análisis abstracto y aún más difícil para los usuarios del
sistema. Como resultado, rara vez encuentra todos los problemas de requisitos
durante el proceso de validación de requisitos. Inevitablemente, se necesitarán
más cambios en los requisitos para corregir las omisiones y malentendidos
después de llegar a un acuerdo sobre el documento de requisitos. Cambio de
requisitos Los requisitos para grandes sistemas de software siempre están
cambiando. Una razón para los cambios frecuentes es que estos sistemas a
menudo se desarrollan para abordar problemas "perversos", problemas que no
se pueden definir completamente (Rittel y Webber 1973). Debido a que el
problema no se puede definir completamente, los requisitos de software están
vinculados a 4
.6 Cambio de requisitos 131 Figura 4.18
Evolución de requisitos Cambio inicial de comprensión comprensión del
problema del problema Requisitos de los requisitos de cambio inicial Hora estar
incompleto Durante el proceso de desarrollo de software, la comprensión del
problema por parte de las partes interesadas cambia constantemente (Figura
4.18). Los requisitos del sistema deben evolucionar para reflejar este cambio
en la comprensión del problema. Una vez que se ha instalado un sistema y se
utiliza regularmente, inevitablemente surgen nuevos requisitos. Esto es en
parte consecuencia de errores y omisiones en los requisitos originales que
deben corregirse. Sin embargo, la mayoría de los cambios en los requisitos del
sistema surgen debido a los cambios en el entorno empresarial del sistema:
1. El entorno comercial y técnico del sistema siempre cambia después de la
instalación. Se puede introducir nuevo hardware y actualizar el hardware
existente. Puede ser necesario interconectar el sistema con otros sistemas. Las
prioridades comerciales pueden cambiar (con los consiguientes cambios en el
soporte del sistema requerido), y se pueden introducir nuevas leyes y
regulaciones que requieren el cumplimiento del sistema.
2. Las personas que pagan por un sistema y los usuarios de ese sistema rara
vez son las mismas personas. Los clientes del sistema imponen requisitos
debido a restricciones organizativas y presupuestarias. Estos pueden entrar en
conflicto con los requisitos del usuario final y, después de la entrega, es posible
que se deban agregar nuevas funciones para el soporte del usuario si el
sistema cumple con sus objetivos.

3. Los sistemas grandes generalmente tienen una comunidad diversa de partes

interesadas, con partes interesadas que tienen diferentes requisitos. Sus
prioridades pueden ser contradictorias o contradictorias. Los requisitos finales
del sistema son inevitablemente un compromiso, y algunas partes interesadas
deben tener prioridad. Con experiencia, a menudo se descubre que el equilibrio
de apoyo brindado a diferentes partes interesadas debe cambiarse y los
requisitos deben priorizarse nuevamente.

A medida que los requisitos evolucionan, debe realizar un seguimiento de los

requisitos individuales y mantener vínculos entre los requisitos dependientes

para poder evaluar el impacto de los cambios en los requisitos. Por lo tanto,

necesita un proceso formal para hacer propuestas de cambio y vincularlas con

los requisitos del sistema. Este proceso de “gestión de requisitos” debe

comenzar tan pronto como esté disponible una versión borrador del documento

de requisitos.

Los procesos de desarrollo ágiles se han diseñado para hacer frente a los

requisitos que cambian durante el proceso de desarrollo. En estos procesos,

cuando un usuario propone un cambio de requisitos, este cambio no pasa por

una gestión de cambio de proceso formal. Por el contrario, el usuario debe

priorizar ese cambio y, si es de alta prioridad, decidir qué características del

sistema que se planificaron para la próxima iteración se deben descartar para

que el cambio se implemente.

El problema con este enfoque es que los usuarios no son necesariamente las

mejores personas para decidir si un cambio de requisitos es rentable o no. En

sistemas con múltiples partes interesadas, los cambios beneficiarán a algunas

partes interesadas y no a otras. A menudo es mejor que una autoridad

independiente, que puede equilibrar las necesidades de todos los interesados,

decida sobre los cambios que deberían aceptarse.

4.6.1

O Requisitos duraderos y volátiles.

Algunos requisitos son más susceptibles de cambio que otros. Los requisitos

duraderos son los requisitos que están asociados con las actividades centrales

y de lento cambio de una organización. Los requisitos duraderos están

asociados con actividades laborales fundamentales. Los requisitos volátiles

tienen más probabilidades de cambiar. Por lo general, están asociados con

actividades de apoyo que reflejan cómo la organización realiza su trabajo en

lugar del trabajo en sí.

http://software-engineering-book.com/web/changing-requirements/
Planificación de la gestión de requisitos.

La planificación de la gestión de requisitos se refiere a establecer cómo se

gestionará un conjunto de requisitos en evolución. Durante la etapa de

planificación, debe decidir sobre una serie de cuestiones:

l. Identificación de requisitos Cada requisito debe ser identificado de manera

única para que pueda ser referenciado con otros requisitos y utilizado en
evaluaciones de trazabilidad.
2. Un proceso de gestión de cambios Este es el conjunto de actividades que
evalúan el impacto y el costo de los cambios. Discuto este proceso con más
detalle en la siguiente sección.
3. Políticas de trazabilidad Estas políticas definen las relaciones entre cada
requisito y entre los requisitos y el diseño del sistema que deben registrarse. La
política de trazabilidad también debe definir cómo se deben mantener estos
registros.
4. Soporte de herramientas La gestión de requisitos implica el procesamiento
de grandes cantidades de información sobre los requisitos. Las herramientas
que se pueden utilizar van desde sistemas de gestión de requisitos
especializados hasta hojas de cálculo compartidas y sistemas de bases de
datos simples. La gestión de requisitos necesita soporte automatizado, y las
herramientas de software para esto deben elegirse durante la fase de
planificación. Necesita soporte de herramientas para:
1. Almacenamiento de requisitos Los requisitos deben mantenerse en un
almacén de datos seguro y administrado que sea accesible para todos los
involucrados en el proceso de ingeniería de requisitos.
4.6 E Modificación de requisitos 133 Problema identificado
Figura 4.19 Revisado Cambio de requisitos administración
Análisis de problemas y especificación de cambios requisitos
Análisis de cambio y costeo
Cambiar implementación
 2. Gestión del cambio El proceso de gestión del cambio (Figura 4.19) se
simplifica si el soporte de herramienta activa está disponible. Las herramientas
pueden realizar un seguimiento de los cambios sugeridos y las respuestas a
estas sugerencias. 3. Gestión de la trazabilidad Como se mencionó
anteriormente, el soporte de herramientas para la trazabilidad permite descubrir
los requisitos relacionados. Se encuentran disponibles algunas herramientas
que utilizan técnicas de procesamiento de lenguaje natural para ayudar a
descubrir posibles relaciones entre los requisitos.

Para sistemas pequeños, no necesita utilizar herramientas especializadas de

gestión de requisitos. La gestión de requisitos se puede admitir mediante
documentos web compartidos, hojas de cálculo y bases de datos. Sin embargo,
para sistemas más grandes, el soporte de herramientas más especializado,
que utiliza sistemas como DOORS (IBM 2013), hace que sea mucho más fácil
hacer un seguimiento de una gran cantidad de requisitos cambiantes. Gestión
de cambios de requisitos La gestión del cambio de requisitos (Figura 4.19)
debe aplicarse a todos los propuestos cambios a los requisitos de un sistema
después de que se haya aprobado el documento de requisitos. La gestión del
cambio es esencial porque debe decidir si los beneficios de implementar
Mencionar los nuevos requisitos se justifica por los costos de implementación.
La ventaja de usar un proceso formal para la gestión del cambio es que todas
las propuestas de cambio son tratadas constantemente y los cambios en el
documento de requisitos se realizan de forma controlada. Hay tres etapas
principales en un proceso de gestión de cambios:
1. Análisis de problemas y especificación de cambios: El proceso comienza con
un problema de requisitos identificados o, a veces, con una propuesta de
cambio específica. Durante esta etapa, se analiza el problema o la propuesta
de cambio para verificar que 1t 1s sea válido. Este análisis se retroalimenta al
solicitante de cambio, que puede responder con una propuesta de cambio de
requisitos más específica o decidir retirar la solicitud.
2. Análisis de cambio y costeo El efecto del cambio propuesto se evalúa
utilizando información de trazabilidad y conocimiento general de los requisitos
del sistema. El costo de realizar el cambio se estima en términos de
modificaciones al documento de requisitos y, si corresponde, al diseño e
implementación del sistema. Una vez que se completa este análisis, se toma la
decisión de proceder o no con el cambio de requisitos. O Trazabilidad de
requisitos Debe realizar un seguimiento de las relaciones entre los requisitos,
sus fuentes y el diseño del sistema para poder analizar los motivos de los
cambios propuestos y el impacto que estos cambios pueden tener en otras
partes del sistema. Debe poder rastrear cómo un cambio se abre paso a través
del sistema. ¿Por qué? http://software-engineering-book.com/web/traceability/
3. Cambiar la implementación Se modifica el documento de requisitos y,
cuando sea necesario, el diseño y la implementación del sistema. Debe
organizar el documento de requisitos para poder realizar cambios en 1t sin

reescritura o reorganización. Al igual que con los programas, la capacidad de

cambio en los documentos se logra minimizando las referencias externas y

haciendo que las secciones del documento sean lo más modulares posible. Por

lo tanto, las secciones individuales se pueden cambiar y reemplazar sin afectar

otras partes del documento.

Si se debe implementar urgentemente un nuevo requisito, siempre existe la

tentación de cambiar el sistema y luego modificar retrospectivamente el

documento de requisitos. Esto casi inevitablemente lleva a que la

especificación de requisitos y la implementación del sistema se salgan del

paso. Una vez que se han realizado cambios en el sistema, es fácil olvidar

incluir estos cambios en el documento de requisitos. En algunas circunstancias,

se deben realizar cambios de emergencia en un sistema. En esos casos, es

importante que actualice el documento de requisitos lo antes posible para

incluir los requisitos revisados.

PUNTOS CLAVE

Los requisitos para un sistema de software establecen lo que debe hacer el

sistema y definen las restricciones en su operación e implementación.

Los requisitos funcionales son declaraciones de los servicios que el sistema

debe proporcionar o son descripciones de cómo se deben realizar algunos

cálculos.

Los requisitos no funcionales a menudo limitan el sistema que se desarrolla y

el proceso de desarrollo que se utiliza. Estos pueden ser requisitos del

producto, requisitos organizativos o requisitos externos. A menudo se

relacionan con las propiedades emergentes del sistema y, por lo tanto, se

aplican al sistema como un todo.

El proceso de ingeniería de requisitos incluye obtención de requisitos,

especificación de requisitos, validación de requisitos y gestión de requisitos.

La obtención de requisitos es un proceso iterativo que puede representarse

como una espiral de actividades: descubrimiento de requisitos, clasificación y

organización de requisitos, negociación de requisitos y documentación de

requisitos.

La especificación de requisitos es el proceso de documentar formalmente los

requisitos del usuario y del sistema y crear un documento de requisitos de

software.

El documento de requisitos de software es una declaración acordada de los

requisitos del sistema. Debe organizarse para que tanto los clientes del sistema

como los desarrolladores de software puedan usarlo,

La validación de requisitos es el proceso de verificar los requisitos de validez,

consistencia, integridad, realismo y verificabilidad.

Los cambios empresariales, organizativos y técnicos inevitablemente conducen

a cambios en los requisitos de un sistema de software. La gestión de requisitos

es el proceso de gestionar y controlar estos cambios.

OTRAS LECTURAS

“Ingeniería de requisitos integrados: un tutorial”. Este es un documento de

tutorial que analiza las actividades de ingeniería de requisitos y cómo se

pueden adaptar para adaptarse a la práctica moderna de ingeniería de

software. (l. Sommerville, / EEE Software, 22 (1), enero-febrero de 2005) http:

//dx.doi.org/10.1109/ MS.2005.13.

“Direcciones de investigación en ingeniería de requisitos”. Esta es una buena

encuesta de investigación de ingeniería de requisitos que destaca los desafíos

de investigación futuros en el área para abordar temas como la escala y la

agilidad. (B. H. C. Cheng y]. M. Atlee, Proc. Conf. Sobre el Futuro de la

Ingeniería del Software, lEEE Computer Society, 2007)

http://dx.doi.org/10.1109/FOSE.2007.17.

Dominar el proceso de requisitos, 3ª ed. Un libro bien escrito y fácil de leer que

se basa en un método particular (VOLERE) pero que también incluye muchos

buenos consejos generales sobre la ingeniería de requisitos. (S. Robertson y J.

Robertson, 2013, Addison-Wesley).

SITIO WEB

Diapositivas de PowerPoint para este capítulo:

www.pearsonglobaleditions.com/Sommerville

Enlaces a videos de apoyo:

http: //software-engineering-book.com/videos/requirements-and-design/

Documento de requisitos para la bomba de insulina:

http: //software-engineering-book.com/case-studies/insulin-pump/ Información

de requisitos del sistema Mentcare:

http: //software-engineering-book.com/case-studies/mentcare-system/ 136

Capítulo4 = Ingeniería de requisitos

CEREMONIAS

4.1.

4.2.

4.3.

4.4,

4.5.

4.6.

4.7.

4.8.
4.9.

4.10.

Identifique y describa brevemente cuatro tipos de requisitos que pueden

definirse para un sistema basado en computadora. Descubra ambigüedades u
omisiones en la siguiente declaración de los requisitos para parte de un
sistema de drones destinado a búsqueda y recuperación:
El dron, un helicóptero cuádruple, será muy útil en operaciones de búsqueda y
recuperación, especialmente en áreas remotas o en condiciones climáticas
extremas. (definir cuantitativamente que tan remoto son esos lugares en km, y
las características de temperatura o humedad, de ese clima “extremo”).
Hará clic en imágenes de alta resolución(cuanta es esa resolución).
Volará de acuerdo con una ruta preestablecida por un operador terrestre, pero
podrá evitar obstáculos por sí solo, volviendo a su ruta original siempre que sea
posible. El dron también podrá identificar varios objetos y unirlos al objetivo que
está buscando. Vuelva a escribir la descripción anterior utilizando el enfoque
estructurado descrito en este capítulo. Resuelva las ambigüedades
identificadas de una manera sensata.
Escriba un conjunto de requisitos no funcionales para el sistema de drones,
estableciendo su seguridad esperada y el tiempo de respuesta. Utilizando la
técnica sugerida aquí, donde las descripciones del lenguaje natural se
presentan en un formato estándar, escriba requisitos de usuario plausibles para
las siguientes funciones:
Un sistema de bomba de gasolina (gas) desatendido que incluye un lector de
tarjetas de crédito. El cliente pasa la tarjeta por el lector, luego especifica la
cantidad de combustible requerida. Se entrega el combustible y se carga la
cuenta del cliente.
La función de despacho de efectivo en un cajero automático bancario. En un
sistema de banca por Internet, una instalación que permite a los clientes
transferir fondos de una cuenta mantenida en el banco a otra cuenta con el
mismo banco. Sugiera cómo un ingeniero responsable de elaborar una
especificación de requisitos del sistema podría realizar un seguimiento de las
relaciones entre los requisitos funcionales y no funcionales. Usando su
conocimiento de cómo se usa un cajero automático, desarrolle un conjunto de
casos de uso que podrían servir como base para comprender los requisitos
para un sistema de cajero automático.
Para minimizar los errores durante una revisión de requisitos, una organización
decide asignar dos escribas para documentar la sesión de revisión. Explica
cómo se puede hacer esto. Cuando se deben realizar cambios de emergencia
en los sistemas, el software del sistema puede tener que modificarse antes de
que se aprueben los cambios a los requisitos.
Sugiera un modelo de proceso para realizar estas modificaciones que
garantice que el documento de requisitos y la implementación del sistema
no sean inconsistentes????????????????.

Has tomado un trabajo con un usuario de software que ha contratado a tu

empleador anterior para desarrollar un sistema para ellos. Usted descubre que
la interpretación de los requisitos de su compañía es diferente de la
interpretación tomada por su empleador anterior. Discuta lo que usted Capítulo
4 debería hacer en tal situación. Usted sabe que los costos para su empleador
actual aumentarán si no se resuelven las ambigüedades. Sin embargo, también
tiene una responsabilidad de confidencialidad con su empleador anterior.