Requerimientos Sistemas de Información

Natalia Solano Lozano

Código 36181003

Universidad de la Salle
Agosto 26 de 2018

1. ¿Qué es un requerimiento?
2. ¿Qué características deben tener los requerimientos?

Fuente Nº1
Somerville, Ian. (9 Ed.).2010. Software Engineering. Recuperado de:
https://edisciplinas.usp.br/pluginfile.php/2150022/mod_resource/content/1/1429431793.203
Software%20Engineering%20by%20Somerville.pdf

1. ¿Qué es un requerimiento?
El concepto que da Ian Somerville en la novena edición de su libro Software Engineering
(2010) sobre los requerimientos es que son “las descripciones de lo que el sistema debería
hacerlos servicios que brinda y las limitaciones de su funcionamiento”. Somerville añade
también que en los requerimientos reflejan lo que los clientes necesitan de un sistema que
satisface un propósito establecido, como pueden ser la realización de un pedido, el control de
un dispositivo o la búsqueda de información.

(Somerville.I.,2010, p.83)

2. ¿Qué características deben tener los requerimientos?

De acuerdo a lo que expone Somerville, los SRS (Software Requirements Systems) se pueden
clasificar como: Requerimientos Funcionales o Requerimientos No Funcionales
(Somerville.I.,2010, p.84)

Requerimientos Funcionales Somerville los define como “declaraciones de servicios que el

sistema debe proporcionar, cómo debe reaccionar el sistema ante determinadas entradas y
cómo debe reaccionar el sistema y cómo debe comportarse el sistema en determinadas
situaciones”. Los requisitos funcionales en ocasiones también pueden indicar explícitamente lo
que el sistema no debe hacer. (Somerville.I.,2010, p.84,85)

Requerimientos No-Funcionales Somerville los define como “restricciones a los servicios o

funciones que ofrece el sistema”. Estos pueden ser las limitaciones de tiempo, las limitaciones
en el proceso de desarrollo y las limitaciones impuestas por las normas. Los requisitos no
funcionales con frecuencia se integran al sistema en su conjunto, en lugar de a las características
o servicios individuales del sistema. (Somerville.I.,2010, p.85)

Sin embargo, Somerville dice que la diferencia entre los requerimientos funcionales y los no-
funcionales no siempre es tan clara. Para explicarlo pone de ejemplo, el caso de un requisito de
usuario relacionado a la seguridad, determinándolo como una “declaración que pone un límite
al acceso de usuarios autorizados y que a primera vista no parece un requerimiento funcional”.
A pesar de ello, Somerville expone que, si se el requerimiento se desarrolla de forma detallada,
puede producir otros requerimientos que si sean funcionales.

En resumen, de lo anterior Somerville, dice que los requerimientos no son independientes, y

que un requerimiento tiene tanto la posibilidad de generar o restringir otros requerimientos.

(Somerville.I.,2010, p.85).

En cuanto a los requerimientos funcionales Somerville explica que cuando los requerimientos
funcionales, se describen como requerimientos de software, estos son descritos de forma
abstracta siendo comprensibles para los usuarios. Cuando es al contrario y los requerimientos
funcionales son más específicos, estos describen las funciones del sistema, entradas, salidas,
excepciones entre otros. (Somerville.I.,2010, p.86).

Los requerimientos funcionales pueden ser generales o específicos dice Somerville. Los primeros
se encargan de describir lo que hace el sistema y los segundos que muestran los sistemas que
existen en una organización o las formas de trabajo local. (Somerville.I.,2010, p.86).

Una de las problemáticas de la ingeniería de software, más comunes en la especificación de los

requerimientos, según Somerville, es la falta de precisión al hacerlos. El desarrollador de un
sistema, puede interpretar de una determinada forma un requerimiento ambiguo
(contradictorio)buscando que su implementación sea simple, pero que no puede ser del agrado
del usuario. (Somerville.I.,2010, p.86).

Por lo anterior Somerville, propone que para evitar dichos problemas las especificaciones de los
requerimientos de un sistema deben ser completos y coherentes desde un principio. La
compleción (el hecho de que algo está completo) significa que todos los servicios requeridos por
el usuario deben estar definidos y la coherencia se refiere a que los requerimientos no deben
presentar contradicciones. (Somerville.I.,2010, p.86).
Fuente Nº2

Ortega, G. Y., Izquierdo, R. E., & Stuart, C. M. L. (2005). El ingeniero industrial en la concepción
de los sistemas informativos empresariales. Recuperado de https://ebookcentral-proquest-
com.hemeroteca.lasalle.edu.co

Link directo: https://ebookcentral-proquest-

com.hemeroteca.lasalle.edu.co/lib/bibliounisallesp/reader.action?docID=3191647

1. ¿Qué es un requerimiento?
Los requerimientos hacen parte de los primeras fases o etapas del ciclo de vida de un software.
Es una parte donde apenas se está empezando a pulir una idea primitiva para el desarrollo del
sistema, hasta que ésta esté completamente establecida, y por ende se pueda dar paso a los
siguientes procesos. En la primera parte de desarrollo del sistema, se deben dejar bien definidos
las funcionalidades que solicitan los clientes (Ortega, G., Izquierdo, R. E.,2005., p.91)
La ingeniería de requerimientos permite un desarrollo más fácil en la comprensión de lo que un
cliente requiere, haciendo un análisis de las necesidades que este tiene, corroborando si es
factible de realizar, buscando negociar de forma justa, especificando los requerimientos de
forma no ambigua, validando las especificaciones y gestionando los requerimientos para que se
conviertan en un sistema operacional. (Ortega, G., Izquierdo, R. E.,2005., p.99)
Los requerimientos se presentan en los servicios como también en las limitaciones del producto
que ha sido solicitado.
2. Características requerimientos:
(Somerville (2002) citado por Ortega, G., Izquierdo, R. E (2005, p.) expone que existen 2 clase de
requerimientos: Los del cliente y los del software. Los primeros en los que se manifiesta los
servicios que debe presentar el software que se requiere. Los segundos donde se especifica lo
que pueden brindan los desarrolladores del sistema y la tecnología a usar.

Dentro de las técnicas de obtención requerimientos en la ingeniería de requerimientos, se

encuentran: 1. Las entrevistas 2. Desarrollo conjunto de aplicaciones, las tormentas de ideas, y
la utilización de casos de uso (Ortega, G., Izquierdo, R. E.,2005., p.97,98,99)
1. Entrevistas: Una de las técnicas más usadas por ser una manera natural de entablar
comunicación entre personas. Y cuenta con 3 procesos.
El primero de preparación donde se hace un estudio de la complejidad del problema. Se
debe conocer las categorías y conceptos que conforman el entorno de los clientes o
usuarios para comprender las necesidades que tiene la organización. En esta primera
etapa se realiza una selección de las personas que se van a entrevistar. Se debe
establecer el objetivo y los temas a tratar en la entrevista y la metodología a usar.

En segundo lugar, la realización que tiene 3 partes: apertura, desarrollo y finalización.

En este paso se establecen las condiciones y la manera de manejar la entrevista. En la
apertura donde se debe hacer una presentación ante el entrevistado e informarlo sobre el
propósito de la entrevista y el uso que tendrá la información obtenida. En el desarrollo
 se debe evitar el no dejar hablar al entrevistado, se debe tener una cierta autoridad en la
entrevista y al finalizar se debe dar un agradecimiento.

En tercer lugar, el análisis en el que se pasa a limpio las anotaciones obtenidas de la

entrevista, se compara con otras entrevistas entre otras cosas.

2. El desarrollo conjunto de aplicaciones es otra técnica de obtención de requerimientos

desarrollada en 1977 por IBM. Tiene 4 principios dinámica de grupo, ayudas visuales
para una mejor comunicación, procurar llevar un proceso organizado y racional. Por
último, tener una filosofía de documentación

3. Tormenta de ideas: reuniones en grupo en el que se evitan realizar críticas y juicios

durante el proceso en el que se están generando las ideas.

4. Casos de Uso: los casos de uso son los repositorios de los requerimientos obtenidos

La ingeniería de requerimientos involucra los dos tipos de requerimientos ya mencionados en

sus procesos de validación, consideración de dominio y también se encuentra vinculado con los
Sistemas Normalizados de Gestión de Calidad:
El último se divide en 6 pasos: identificación, análisis y negociación, especificación, modelado
del sistema, validación y gestión.
(Ortega, G., Izquierdo, R. E.,2005., p100)

Fuente Nº 3

Reengineering of Software Requirement Specification

Abeer AlSanad and Azedine Chikh
AlSanad A., Chikh A. (2014) Reengineering of Software Requirement Specification. In:
Rocha Á., Correia A., Tan F., Stroetmann K. (eds) New Perspectives in Information
Systems and Technologies, Volume 2. Advances in Intelligent Systems and Computing, vol
276. Springer, Cham
DOI https://doi.org/10.1007/978-3-319-05948-8_10

1. ¿Qué es un requerimiento?

Según Abeer AlSanad and Azedine Chikh es:

La ingeniería de software puede definirse como una disciplina de ingeniería que se ocupa de
todos los aspectos de la producción de software. Sus actividades genéricas en todos los
procesos de software son: especificación de requisitos que describe lo que el sistema debería
hacer y sus limitaciones de desarrollo, desarrollo: producción del sistema de software real,
validación: comprobación de que el software es lo que el cliente realmente quiere, y
evolución: que está cambiando el software en respuesta a las demandas cambiantes [1]

(A. AlSanad , A. Chikh.,2014, p.96)

2. ¿Qué características deben tener los requerimientos?

Los SRS (Software Requirements Specification) en español especificación de requisitos de

software, es el documento derivado del proceso que deben realizar los desarrolladores de
software, para la compilación de requisitos de software al iniciar un proyecto. ((A. AlSanad , A.
Chikh.,2014, p.96)
Según el Centro de tecnología de aseguramiento de software de la NASA existen 10 criterios que
cualquier SRS deben tener en cuenta para ser considerado de alta calidad. AlSanad, y A. Chikh. Muestran
en una tabla cómo cualquier SRS escrito basado en su esquema cumplía con estos diez criterios (Ver tabla
pag 96)

1) Completo:
Cada SRS escrito de acuerdo con su esquema se completa automáticamente porque el esquema
en sí está completo. Define todas las situaciones posibles que puede tener cualquier SRS y aclara
las respuestas apropiadas a cada una de estas situaciones.

2) Consistente
La consistencia de una instancia SRS está asegurada por la consistencia del esquema en sí mismo.
Todos los requisitos de las funciones del sistema son compatibles con requisitos de rendimiento.
Esta compatibilidad está garantizada por los Atributos de requisito no funcionales Fun_ID. Este
atributo enlaza cada requisito no funcional con un requisito funcional que debería ser compatible
con.

3) Correcto
Su esquema divide el SRS en pequeños elementos detallados y cada elemento es completo y
preciso. Además, algunos elementos tienen atributos que elevan el nivel de detalles. Ya que la
información escrita en el esquema es muy detallada, esto hará que la operación de comprobación
sea fácil de realizar. Por lo tanto, garantizar la la corrección es más simple y definitiva. Además,
nuestro esquema ha cruzado característica de referencia. Por ejemplo, Author_ID y validator_ID
de cualquier hará referencia a Member_ID. Esta característica asegurará que la la corrección. Por
ejemplo, si se ha introducido un Author_ID incorrecto de una necesidad, un se producirá un error
porque no hay una referencia correcta de ese Author_ID en ID_miembro.
 4) Modificable
El SRS es fácil de modificar ya que está dividido en distintas partes. Esto facilita el alcance de la
pieza que se pretende cambiar. Dado que SRS está escrito en un formato semiestructurado, es
fácil y rápido de mantener.

5) Clasificado
El rango de las declaraciones de especificación de requisitos está especificado por su importancia.
Nuestro esquema asegura que cada requisito se clasifique a través del atributo Rango. El valor de
rango puede ser alto, medio o bajo.

6) Comprobable
El esquema XML comprueba cada requisito para asegurarse de que es comprobable. Esta
verificación se realiza en su esquema para cada requerimiento a través del atributo Testability.
Este atributo muestra si el requisito se somete a ensayo antes o no.

7) Rastreable
Su esquema asegura la trazabilidad de cada requerimiento a través de atributos de trazabilidad.

8) Sin ambigüedades
Las declaraciones de requisitos son inequívocas. Esto se debe a la posibilidad de utilizar
conocimientos explícitos sobre el requisito categorías, estilos, niveles, etc.

9) Válido
Su esquema ofrece un elemento de validación para cada requisito. Este elemento contiene
Validator_ID y estado de validación. Validation_ID referido a nombre del validador y
validation_status que tiene "acuerdo" "justo" o Valores de "desacuerdo".

10) Verifiable
Su esquema garantiza la verificación de SRS al tener Parent_Req_ID como un atributo para cada
requisito.