[Php-avanzado] Requerimientos-Tesina

[Leonardo Tadei - Pegasus Tech Supply]

Hola Cesar,

	Está muy buena la SRS.
	Te marco apenas unos detalles y supongo que con esto, en la próxima
versión queda terminada:

El sáb, 10-11-2012 a las 22:23 -0300, cesar andrada escribió:
> -Sistema de Registro de Cursadas.
> 
> 
> *Requerimientos Funcionales
> 
> 
> 1. El Sistema debe Gestionar Carreras.
> 
> 2. El Sistema debe Gestionar Materias con su Carrera [1].

	Al diccionario de Materia, le falta el atributo "carrera".
	Me parece que te lo había dicho en la corrección anterior.

> 3. El Sistema debe Mostrar las Localidades.
> 
> 4. El Sistema debe Gestionar Alumnos con su Localidad [3].
> 
> 5. El Sistema debe Gestionar las Inscripciones con su Alumno [4] y
> Carrera [1].

	Me parece que las inscripciones no se gestionan, sino que se
registran... si no podés borrar una inscripción y cambiar "el pasado"
del sistema.

> 6. El Sistema debe Gestionar Profesores son su Localidad [3].
> 
> 7. El Sistema debe Gestionar las Cursadas con su Profesor [6] y
> Materia [2].
> 
>             //se registra que dias y horarios da tal materia. 
> 
> 8. El Sistema debe Gestionar las Cursadas con su Alumno [4], Materia
> [2] y Profesor [6].
> 
>             //una vez que se registro el profesor y organizo sus
> horarios el alumno se registra a la materia que quiere cursar.

	Tenés que cambiar de nombre una cosa, porque tanto el RF7 como el 8 son
de gestión de cursadas.
	El RF7 parece la gestión de la cursada, pero el RF8 parece la gestión
de la "inscripción a la cursada", que no es lo mismo, así como
diferenciaste el RF1 del 5.
	Esta división implicará que agregues una entrada al diccionario para la
Inscripción a Cursada, y modifiques el diccionario actual de Cursada
para sacarle lo que sobra.

> 9. El Sistema debe Registrar y Mostrar las Notas de la Cursada [8].
> 
> 
> *Requerimientos No Funcionales
> 
> 
> 1. El Sistema debe ser Web.
> 
> 2. El Sistema debe pedir un login.
> 
>             2.1. El Sistema debe tener permisos para dar de alta
> alumnos y profesores y realizar la gestión de cursos. 
> 
> 3. El Motor que se usa para almacenar los datos debe ser MySQL.
> 
>  
> 
> *Diccionario
> 
> 
> Carreras: nombre.
> 
> Materias: nombre.
> 
> Localidades: Nombre, Código Postal.
> 
> Alumnos: documento, nombre, apellido, fecha de nacimiento, dirección,
> teléfono, mail, Localidad.
> 
> Profesores: matricula, nombre, apellido, dirección, teléfono, mail,
> Localidad.
> 
> Inscripciones: Fecha de Inscripción, Alumno, Carreras.
> 
> Cursadas: días (“lunes, martes, miércoles, jueves, viernes”), horario
> de inicio, horario finalizado, Alumno, Profesor, Materia.
> 
> Registro de Notas: fecha, nota, descripción (“1º parcial, 2º parcial,
> 1º recupera torio, 2º recupera torio, Final”).
> 
> 
> 
> //Los datos Profesores, Alumnos, Carreras y Materias, le quiero hacer
> una baja lógica, que cuando se de la baja los datos permanecen y que
> se muestren a parte los datos que se dieron de baja, ¿eso lo tengo que
> agregar como una RF o como subitem de RF de la 1, 2, 4 y 6?

	No, lo que tenés que poner como funcionalidad es "algo" que implique
que te verás forzado a implementar una "baja lógica"  en vez de una
física.
	Todos los RF que pusiste ahora se pueden implementar perfectamente
borrando las cosa que no hacen falta más sobre un almacenamiento en 3FN.
	No es que no te quiera decir ese "algo", es que no se me ocurre ningún
motivo ni funcionalidad que implique una baja lógica par aun sistema
como este :-(

	Generalmente se plantea el hacer bajas lógicas cuando no se sabe
normalizar. Hay casos en que hace falta esto para implementar alguna
funcionalidad... que no está todavía en esta SRS. Sin una justificación
funcional, hacer bajas lógicas es simplemente diseñar y programar mal

	De dónde surge tu idea de hacer bajas lógicas? Hoy en clase lo
charlamos.

	Saludos!

-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
Web: http://leonardo.tadei.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key