Importante

El éxito del desarrollo de software comienza con el buen entendimiento de las necesidades de los usuario, ésta es una de las labores principales del profesional en Sistemas, quién debe transformar el mundo abstracto a un mundo real. Por ello, éste blog te proporciona conocimientos básicos para iniciar èste tipo de proyectos.
Unidad IV. Análisis de Requerimientos del Software

Objetivos específicos

Realizar los flujos de trabajo de los requerimientos
Trazar el modelo de negocios inicial
Organizar el documentode requerimientos de software

20 comentarios:

Xavier Nievez dijo...

Buebas Ing. Rosemary Samniego, saludos de parte del grupo #6, bien empezando con el tema:

REQUISITOS NO FUNCIONALES DEL SISTEMA
Los requisitos no funcionales de un sistema son aquellas caracteristicas que no tiene nada que ver con el software, es decir, son aquellos requerimientos de hardware que el sistema debe soportar para que funcione correctamente.

Algunos ejemplos claro de un requerimiento no funcional son:
-Que un Sistema funcione en diversas plataformas, es decir, en diversos Sistemas Operativos.
-Que el tiempo de respuesta del Sistema sea eficaz.

Ademas el requisito no funcional es imprescindible, es decir, se encarga de hacer las funciones del sistema (programas, aplicaciones, herramientas, etc).

Unknown dijo...

Muy buenas tardes Ingeniera nosotros conformamos el grupo 4 del paralelo B con respecto a nuestro tema tenemos lo siguiente:

¿Cual es la razon por la que elejimos la tecnica del escenario de caso de uso?

Como primer punto decimos que un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software.

Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico.

Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final.

En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.

Jefferson Arévalo dijo...

Saludos Ingeniera, respecto al tema del que nos tocó comentar lo hemos tratado de hacer lo más entendible para que el resto de los compañeros de clase opinen también de nuestro comentario
Bueno en cuanto a las técnicas para encontrar los requerimientos quisimos destacar a las dos q consideramos principales..
Primeramente PUNTOS D VISTA en la q para encontrar requerimientos por medio de esta primera técnica, tomamos como fuente documentación,usuarios(stakeholders),sistemas similares,y saber si nuestro sistema trabajará en conjunto con otro sistema.
Entre estos tipos de Vista encontramos...
DIRECTOS: Personas q estan en contacto con el sistema y que nos proporcinarán informacion detallada
INIDRECTOS: Aquellos actores que no utilizan el sitema pero que directamente influyen e indican requerimientos organizacionales y restricciones para los usuarios(jerarquia)
DE DOMINIO: Entrevistando a personas de un cierto dominio, es decir que se entienden en lenguaje tecnico y saben la forma en la q opera la empresa.
y como segunda técnica tenemos los ESCENARIOS la cual consiste en imaginar la manera fisica en la que nuestro sistema trabajará y asi encontrar los posibles requerimientos.
Esto tambien se representa através de los diagramas de casos de uso...
NOTA: Es recomendable realizar diagrama de casos de uso del sistema anterior para un mejor trabajo..

Tanyiita Cedeño Mediina dijo...

Buenas tardes Ingeniera
Reciba un cordial saludo del grupo *1*

Respecto al tema:


*** REQUISITOS FUNCIONALES DEL SISTEMA ***

Un requisito funcional define el comportamiento interno del software: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que muestran cómo los casos de uso serán llevados a la práctica.

Son complementados por los requisitos no funcionales, como ya lo explicaron en el comentario anterior son los que se enfocan en cambio en el diseño o la implementación.

En conclusion, como se define en la ingeniería de requisitos, los requisitos funcionales establecen los comportamientos del sistema.

Juan Palacios dijo...

Buenas tardes Ing. Rosemary Samniego, saludos de parte del grupo #7:

De acuerdo a lo expuesto por nuestros compañeros del grupo #6, hemos llegado a la conclusión de que los requisitos no funcionales de un sistema que a pesar de ser importantes no son imprescindibles como lo expresan.

Nos podemos dar cuenta con el simple ejemplo que nos dio en clases de que no hay problema que un sistema sea creado para multiplataformas o para una sola plataforma, aunque seria importante que el sistema se ejecute en otras plataformas esto NO ES IMPRESCINDIBLE porque igual se lo puede ejecutar en la plataforma que ha sido elaborado y el sistema sigue funcionando con normalidad.

Diana Estefania Reyes Ramos dijo...

Buenas tarde Ing. Rosemary, somos el Grupo # 02 4to Quimestre “B”.
Retroalimentación del grupo # 01
Podremos añadir que cuando hablamos de una característica requerida de la cual se sabe que va a ser satisfecha por medio de la adición de un subsistema o bloque de código en el software, entonces se dice que estamos ante un requisito funcional, por cuanto es un requisito que denota una funcionalidad del sistema.
Un requisito funcional típico contiene un nombre y un número de serie único y un resumen. Esta información se utiliza para ayudar al lector a entender por qué el requisito es necesario, y para seguir al mismo durante el desarrollo del sistema.
Para un mejor entendimiento (Ejemplo):
El sistema debe verificar que la instalación del sistema ha sido correcta y que los dispositivos funcionan correctamente.
El sistema debe permitirle al presidente iniciar la elección lo cual permitirá que se puedan registrar los votos de los electores
El sistema deberá almacenar el voto una vez que éste fue confirmado.
El sistema permitirá que el presidente de una unidad de reporte (o mesa) realice un cierre de elección, la cual solo podrá realizarse si se produce en un horario posterior al establecido (en la configuración del sistema) y si la elección se encuentra iniciada.

Anónimo dijo...

Buenas noches Ing.Rosmery, de quienes conformamos el grupo # 5, del 4 to Quimestre "B", nosotros retroalimentaremos el comentario de los compañeros del grupo #4, con respecto a la pregunta:

¿Cual es la razon por la que elejimos la tecnica del escenario de caso de uso?
Los Casos de Usos son un conjunto de escenarios relacionados por un objetivo y un actor común. Es la descripción de la secuencia de acciones desarrollados por un actor y un sistema para producir un resultado para el actor.
Los Casos de Usos en si nos representan las interacciones y la interrelación que va a tener el Sistema con los usuarios.
Es muy importante que antes de crear el diseño o el modelado de Caso de Usos, el analista conozca a profundidad los requerimientos del Sistema y del Usuario.

Johnny Urdin González dijo...

Muy buenas noches Ingeniera......
Casos de uso
Con respecto a lo visto en clase acerca de los casos de uso, el Grupo #8 concluye con lo siguiente:
Los casos de uso, permiten el modelado de un sistema informático desde el punto de vista del usuario. Este modelado permite el entendimiento intuitivo del sistema en cuestión ya que en él se describe de manera gráfica la interacción que el usuario tendrá con el software, los casos de uso se pueden utilizar durante la captura de los requerimientos funcionales del sistema. En fin un caso de uso es un documento que narra secuencialmente acciones que ayudaran al usuario a completar un proceso específico utilizando un sistema de software.

En cuanto a la notación que se utiliza para representar a los casos de uso son los siguientes:
Para representar el caso  elipse

Para los actores ==> el correspondiente dibujo de usuario

Las características que encontramos en los casos de usos son:
Existen varias pero las más importantes que podemos destacar pues son:
Determina lo que el usuario hará con el sistema informático luego de su implementación, cada actor hace lo que le corresponde.
Es un documento que se lo realiza de manera gráfica a fin de que los actores puedan entender el proceso que le toca realizar a cada uno.





Pregunta:
Los casos de uso describen cada parte o proceso de manera gráfica, pero no se presenta una interfaz que ayude a difundir los procesos, ¿Qué tipo de procesos son los que se tienen que realizar de manera gráfica en el caso de uso? (si los procesos son obvios), ¿y cómo presentarlo al usuario?, ¿se debe incluir algún tipo de especificación para mejor al entendimiento al usuario o simplemente se lo realiza de manera abstracta?....

freddy dijo...

Buenas tardes con todos…………..
Mi inquietud es, que una vez trazado el conjunto inicial de requerimientos (extracción de requerimientos), el proceso de detallarlos y extenderlos se denomina análisis de requerimientos, pero que pasaría si solamente se extiénden los requerimientos, pero no se detalla profundamente.
¿Qué problemas tendría en este punto el análisis de requerimiento?
Gracias….
Att: Freddy Congo.

leonardo dijo...

Muy buenas tardes Ingeniera, de igual manera a los compañeros seguidores de este blog.
Respondiendo a la pregunta de mi compañero Freddy Congo...
<<<¿Qué problemas tendría en este punto el análisis de requerimiento si no se detalla profundamente?>>>...

RESPUESTA:
Bueno yo tengo entendidio que el Analisis de requerimientos. Es la etapa que nos permiten conocer los elementos necesarios para definir el desarrollo de un proyecto de software.

Por tanto para realizar bien el desarrollo de software es esencial realizar una especificación completa de los requerimientos de los mismos.
Independientemente de lo bien diseñado o codificado que esté, porque un programa pobremente especificado sin el respectivo Analisis, decepcionará al usuario y hará fracasar el desarrollo.

Leonardo Armijos...

Unknown dijo...

Hola, Buenas noches
En mi opinión esta etapa del Análisis Orientado a Objetos es muy importante. Mi pregunta es la siguiente a que se refiere que el Análisis de Requerimientos del Software establece ¿QUÉ debe hacer el sistema, pero NO como hacerlo?

Anónimo dijo...

Buenas noches a todos los seguidores de este blog pues respondiendo la pregunta de mi compañer piwi creo que a lo que se refiere en el analisis de requerimientos que debe hacer el sistema es que esta parte es netamente analizar y priorizar las verdaderas necesidades de usuario y que se quiere que haga el sistema y por que no nos dice como hacerlo pues ya que en esta parte no entra aun la programacion ya que esto se ve en el diseño orientado a objetos.

Unknown dijo...

Hola,Muy Buenas noches Ingeniera.
Soy Cristhian Mena, mi inquietud es para saber si alguien me puede aclarar de que se tratan los requerimientos de ya que el concepto no me deja del todo claro de que se trata, es que se habla muy poco sobre el tema y además cuán importante serian estos dentro del proyecto a ejecutar o realizar?
Gracias!!!

by...Dan..Tan..Bal dijo...

Hola muy buenas noches
Danny Tandazo, respondiendo a la pregunta que hiso mi compañero:
Los requerimientos del dominio se derivan más del dominio del sistema más que de las necesidades específicas de los usuarios , pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares son importantes debido a que a menudo reflejan los fundamentos del dominio de aplicación.
Espero haberte ayudado a entender más sobre el tema.

Unknown dijo...

buenas tardes ingeniera,
tengo ciertas dudas sobre el analisis de requerimiento. Me gustaria saber de que puntos debo de tomar en cuenta para redactar correctamente los requerimientos para una empresa

Bioleta Pesantez dijo...

Respondiendo a la pregunta de mi amiga
Primeramente tienes que hacer una extracción de análisis para poder detectar los problemas que tiene la empresa luego proceder hacer el análisis de requerimientos.
Debes identificar bien los requerimientos funcionales y no funcionales porque si hay una confusión puede crear graves problemas a la empresa.
Espero que te sirva de algo mi explicacion .

Angie Zambrano dijo...

Buenas noches ingeniera, en la fase de análisis de requerimientos de software me gustaría saber un poco más acerca de las formas para determinar los requerimientos del sistema.

Att: Angela Zambrano

Diana Estefania Reyes Ramos dijo...

Un requerimiento podremos definirlo como un atributo necesario de un sistema, que puede representar una capacidad, una característica o un factor de calidad del sistema de tal manera que le sea útil a los clientes o a los usuarios finales.
A nivel general los requerimientos pueden clasificarse como requerimientos indicados o reales. ¿Que podriamos indicar que es requerimientos indicados y reales?

Anónimo dijo...

buenas noches... respondiendo a la pregunta de mi compañera Diana Reyes.
REQUERIMIENTOS INDICADOS: Son los entregados por el usuario al comienzo del Proyecto.
REQUERIMIENTOS REALES: son aquellos que reflejan la satisfacción de las
necesidades del usuario en un sistema particular.
espero con esto haberte sacado de la duda.. =)

Unknown dijo...

Sandra Taco...

Los requerimientos son declaraciones que identifican atributos, capacidades, características y/o cualidades que necesita cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para el usuario. En otras palabras, los requerimientos muestran qué elementos y funciones son necesarias para un proyecto.

Perfil

Mi foto
Rosemary Samaniego
Ver todo mi perfil
Rosemary Samaniego. Con la tecnología de Blogger.

ESTUDIANTES 4to QUIMESTRE

ESTUDIANTES 4to QUIMESTRE
GRUPO OBJETIVO DEL PROYECTO

ESCUELA DE INFORMATICA

ESCUELA DE INFORMATICA
UTMACH

Seguidores

Contador de Visitas