Requerimientos de un sistema y desarrollo del prototipo caracteristicas tipos

2. Normalmente, un tema de la Ingeniería de Software
tiene diferentes significados. De las muchas definiciones
que existen para requerimiento, ha continuación se
presenta la definición que aparece en el glosario de la
IEEE .
1. Una condición o necesidad de un usuario para resolver
un problema o alcanzar un objetivo.
2. Una condición o capacidad que debe estar presente en
un sistema o componentes de sistema para satisfacer un
contrato, estándar, especificación u otro documento
formal.
3. Una representación documentada de una condición o
capacidad como en 1 o 2.

3.  Los requerimientos no son obvios y vienen de muchas
fuentes.
 Son difíciles de expresar en palabras (el lenguaje es
ambiguo).
 Existen muchos tipos de requerimientos y diferentes
niveles de detalle.
 La cantidad de requerimientos en un proyecto puede ser
difícil de manejar.
 Nunca son iguales. Algunos son más difíciles, más
riesgosos, más importantes o más estables que otros.

4.  Los requerimientos están relacionados unos con otros,
y a su vez se relacionan con otras partes del proceso.
 Cada requerimiento tiene propiedades únicas y abarcan
áreas funcionales específicas.
 Un requerimiento puede cambiar a lo largo del ciclo de
desarrollo.
 Son difíciles de cuantificar, ya que cada conjunto de
requerimientos es particular para cada proyecto.

5.  Obtener información acerca de lo que los usuarios
desean.
 Clasificar esos deseos para comenzar a estructurar
requerimientos.
 Identificar los niveles de jerarquía del sistema y empezar a
alojar los ya clasificados requerimientos en cada nivel.
 Especificar formalmente los requerimientos de acuerdo al
nivel de audiencia que se desea..

6. 1. Requerimiento Funcional
2. Requerimiento no Funcional
3. Otros tipos de limitaciones externas
 Un requerimiento funcional puede ser una descripción de
lo que un sistema debe hacer. Este tipo de requerimiento
específica algo que el sistema entregado debe ser capaz
de realizar.

7.  Un requerimiento no funcional de rendimiento, de calidad,
etc.; especifica algo sobre el propio sistema, y cómo debe
realizar sus funciones. Algunos ejemplos de aspectos
solicitables son la disponibilidad, el testeo, el
mantenimiento, la facilidad de uso, etc.
 Otros tipos de limitaciones externas, que afectan en una
forma indirecta al producto. Estas pueden ir desde la
compatibilidad con cierto sistema operativo hasta la
adecuación a leyes o regulaciones aplicables al producto.

8.  Los requerimientos bien formulados deben satisfacer
varias características. Si no lo hacen, deben ser
reformulados hasta hacerlo.
› Necesario
› No Ambiguo
› Conciso
› Consistente
› Completo
› Alcanzable
› Verificable

9.  Necesario: Lo que pida un requerimiento debe ser
necesario para el producto.
 No ambiguo: El texto debe ser claro, preciso y tener una
única interpretación posible.
 Conciso: Debe redactarse en un lenguaje comprensible
por los inversores en lugar de uno de tipo técnico y
especializado, aunque aún así debe referenciar los
aspectos importantes
 Consistente: Ningún requerimiento debe entrar en
conflicto con otro requerimiento diferente, ni con parte de
otro. Asimismo, el lenguaje empleado entre los distintos
requerimientos debe ser consistente también.

10.  Completo: Los requerimientos deben contener en sí
mismos toda la información necesaria, y no remitir a otras
fuentes externas que los expliquen con más detalle.
 Alcanzable: Un requerimiento debe ser un objetivo
realista, posible de ser alcanzado con el dinero, el tiempo
y los recursos disponibles.
 Verificable: Se debe poder verificar con absoluta certeza,
si el requerimiento fue satisfecho o no. Esta verificación
puede lograrse mediante inspección, análisis,
demostración o testeo.

11.  Estas características suelen ser subjetivas, es decir, no
pueden ser calculadas de forma automática por ningún
sistema. Por ello, se tiende a medir otras métricas o
indicadores que sí que pueden ser calculados de forma
automática y que, de algún modo, pueden sustituir o
mapear con esta lista de características.

12.  Los prototipos son una visión preliminar del sistema futuro
que se implantara, la elaboración de prototipos de un
sistema de información es una técnica valiosa para la
recopilación de los requerimientos de información de los
usuarios.
 Los prototipos efectivos deben hacerse tempranamente en
el ciclo de vida del desarrollo de sistemas, durante la fase
de determinación de requerimientos

13.  El prototipo es una aplicación que funciona.
 La finalidad del prototipo es probar varias suposiciones
formuladas por analistas y usuarios.
 Los prototipos se crean con rapidez.
 Los prototipos evolucionan a traves de un proceso
iterativo.
 Los prototipos tienen un costo bajo desarrollo.

14.  El desarrollo de prototipos en una aplicaciones que se
llevan de forma ordenada, sin importar la herramienta
› Identificación de requerimientos
› Desarrollo de un modelo que funcione
› Utilizar el prototipo
› Revisión del prototipo
› Repetición del proceso las veces que sea necesario

15.  Prototipo de parchado
 Prototipo no operacional
 Prototipo primero de una serie
 Prototipo de características seleccionadas
 Prototipo de parchado: Es la construcción de un problema
operable, es decir que tenga las características
necesarias o básicas que permitan una iteración del
usuario.

16.  Este prototipo es un modelo a escala que solamente
contiene las características esenciales, en este debido al
tiempo y costo podrán ser realizado, de igual manera se
puede tomar algunas decisiones sobre la utilidad del
sistema en base a las entradas y a las salidas ya del
prototipo.

17.  Es la creación de un primer modelo a escala completo de
un sistema.
 Este tipo de prototipo es útil cuando se tienen planeadas
muchas instalaciones del mismo sistema de información

18.  Se refiere a la construcción de un modelo operacional que
incluyen algunas pero no todas de las características que
tendrá el sistema final, adicional a esto el sistema se va
construyendo por módulos, de modo que si las
características reciben una evaluación satisfactoria
puedan incorporarse al sistema final.

19.  A pesar de que tal vez surjan problemas, la construcción
de prototipos puede ser un paradigma efectivo para la
ingeniería del software. La clave es definir las reglas del
juego desde el principio; es decir, el cliente y el
desarrollador se deben poner de acuerdo en:
› Que el prototipo se construya y sirva como un mecanismo para la
definición de requisitos.
› Que el prototipo se descarte, al menos en parte.
› Que después se desarrolle el software real con un enfoque hacia
la calidad.