Loading

Module 1: Requisito del sistema y desarrollo

Study Reminders
Support
Text Version

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

Hoy hablaremos sobre los requisitos de origen y la documentación depara el desarrollo del sistema.(Consulte la hora de la diapositiva: 00:32)
En la conferencia anterior comentamos sobre la clasificación de requisitos, la partición de requisitos dey la gestión de requisitos; como vimos sobre los requisitos del artículo de configuración de, los requisitos del sistema de requisitos de componentes y los requisitos de origen y los requisitos de misión de, cómo clasificamos y cómolos partimos en diferentes categorías.Y hoy lo que vamos a hacer es ver cómo hacemos realmente un requisito y la documentación deque se conoce como documentación de requisitos de origen. Por lo tanto, vamos apasar por este proceso los pasos implicados en los requisitos.
(Consulte el tiempo de la diapositiva: 01:03)
Por lo tanto, la idea básica es que el requisito se debe escribir de una manera clara y sin ambigüedadesque son los requisitos que van a estar en todo el proceso de diseñoa lo largo del ciclo de vida del proyecto o del sistema y habrá muchas personas usandoeste requisito en varias etapas y bajo diversas circunstancias. Todo el mundo deberíaentender el requisito de la misma manera que lo que pretende la persona que realmenteescribió los requisitos.Por lo tanto, debe ser muy claro que debe ser inequívoco y no hay ninguna confusiónsobre lo que está escrito o no puede ser interpretado de una manera diferente. La importancia de esteen realidad podemos ver en nuestro día a día también cada vez que nos comunicamos con la gente depodemos decir algo y la otra persona puede entenderlo de manera diferente. Para el ejemplo de, verá el diálogo entre la señora Chopra y Gita por qué ha pop. Por lo tanto,mucho maíz sólo necesita 6 tazas Gita dice que he aparecido sólo 6 tazas.Me refiero a 6 tazas de maíz popped no 6 las tazas de popping de 6 tazas dijo Misses Chopra entoncesque usted debería haber dicho. Por lo tanto, eso significa que si quieres algo debes decirle correctamente site da la oportunidad de que alguien lo interprete de una manera diferente, entonces las cosas irán de una manera diferenteluego ambas tendrán mala comunicación. Y esto es muy importante eneste caso de requisito de análisis de requisitos para escribir también. Por lo tanto, deberíamos tratar de contar lo querealmente queremos y debemos escribir de una manera clara y clara cuál es el requisito deque los requisitos particulares son otro ejemplo aquí.
(Consulte la hora de la diapositiva: 02:42)
"Usted debe decir lo que quiere decir" la liebre de marzo fue en “ I do, ” Alice apresuradamenterespondió; “ al menos me refiero a lo que digo que es lo mismo, usted sabe. ” Así que, diga lo que significay me refiero a lo que digo que es lo mismo que el argumento aquí es, pero estos quela verdadera mirada aquí “ No es lo mismo un poco ” dijo el Hatter Mad. “ Por qué tal vez comobien diga que yo como lo que veo es lo mismo que como lo que veo. Entonces, usted puede ver la diferenciano es lo mismo que lo que usted dice que veo lo que yo como y yo como lo que veo sontotalmente diferentes.Así que, debemos asegurarnos de que cada vez que comunicamos lo que grabamos debe serdebidamente grabado y debidamente escrito. Así que todo el mundo lo entiende de la misma maneralo que pretendíamos.
(Consulte el tiempo de la diapositiva: 03:29)
Las características de los requisitos de sonido por lo que siempre que escribimos el requisito quedeberíamos asegurarnos de que realmente son el requisito adecuado y lo estamos escribiendo de una manera correcta.Así que, sé para asegurar que el requisito debe ser inequívoco, como lo mencionédebería ser comprensible para todos. Por lo tanto, no debe ser puesto en una muy alta técnicao dentro de las muy complejas frases, debe hacerlo muy simple ycomprensible para todos debe ser muy conciso no ser muy larga sentencia con muchode explicación, debe ser muy concisa declaración, debe ser rastreable rastreabilidad esbásicamente usted debe ser capaz de volver a ese requisito y averiguar dónde este requisito, pero será un requisito vino de y cuál fue el origen de ese requisito. Por lo tanto, que hay cualquier problema en la etapa posterior podemos volver y luego corregirese requisito basado en ese origen de ese requisito. Por lo tanto, por eso debe serrastreable y debe ser independiente del diseño.Por lo tanto, no debemos decir específicamente que este requisito es para este diseño en particular. Por lo tanto,nunca debe decir que debe haber una transmisión clara entre particular entre los componentes de2, porque esto se convierte en un diseño dependiente. Por lo tanto, ese requisito no debe seren la forma que depende de un diseño en particular. Por lo tanto, debe sersiempre mencionado de manera independiente del diseño y debe ser verificable. Por lo tanto,debería poder verificar este requisito en la etapa posterior, independientemente de lo que escribimos como
el requisito debe ser verificable. De lo contrario, no tiene sentido escribirlo porqueno sería capaz de verificar si realmente está logrando ese requisitoen particular o no de forma similar debería ser único para ese proyecto en particular. Por lo tanto, no debería serde una manera muy común o debería ser muy específico para este sistema en particular.Debe ser completo. Por lo tanto, la que no sea una sentencia parcial debe ser una sentenciacompleta o una sentencia completa de requisito, debe ser coherente con los demás requisitos detambién puede haber muchos requisitos en el sistema. Por lo tanto, debe sercoherente con otros requisitos no debe ser contradictorio con otros requisitos enel requisito general del sistema debe ser modificable. Por lo tanto, en cualquier momento usted debe sermodificar ese requisito dependiendo de la situación, a medida que se presenta una situaciónpuede encontrar que este requisito no es el que realmente desea que entonces usted debe seren una posición para modificar este requisito de manera similar debe ser alcanzable.Por lo tanto, usted debe ser capaz de alcanzar ese requisito o debe ser capaz de cumplir con ese requisito dea través de algunos medios. Por lo tanto, usted no debe escribir algo que esimposible de lograr. Por lo tanto, la viabilidad del requisito entra en escena. Por lo tantome enfrentaré a que sea alcanzable. Por lo tanto, estas son las buenas características de escribir un requisito de.Por lo tanto, cada requisito en realidad debe tratar de seguir todas estas características. Por lo tanto,todo el mundo puede entenderlo nadie lo interpretará de una manera diferente y estos sonposibles y factibles requisitos para el sistema.
(Consulte la hora de la diapositiva: 06:09)
Por lo tanto, una vez que tenga estas características básicas debe ver cómo escribimos el documento. Por lo tanto, este es el documento para el desarrollo del sistema que se conoce como documento de requisitos dede origen o en ORD corto. Por lo tanto, este es el documento en el que realmenteanotamos o grabamos todos estos requisitos y nos aseguramos de que estos sean factibles ysean comprensibles para todos. Por lo tanto, los requisitos y las opciones de diseño interactúanentre fases del ciclo de vida. Por lo tanto, esto es importante porque en todo el ciclo de vida estos requisitos deinteractúan.Por lo tanto, es por eso que tenemos que asegurarnos de que nuestra ORD tome los diferentes ciclos de vida delos requisitos del sistema en una fase del ciclo de vida a menudo tendrán un impacto importante enel diseño de un sistema en otra fase. Así que, como mencioné en el sistema,ciclo de vida del sistema. Por lo tanto, habrá una interacción de este requisitosobre los ciclos de vida del sistema y habrá mucho impacto en otro ciclo de vida.Por lo tanto, los requisitos de la fase de diseño tendrán un impacto importante en la fase de fabricaciónde manera similar el requisito de la fase de fabricación puede afectar a la fase operativapor lo tanto, tenemos que asegurarnos de que este requisito lo que identificamos son consistentes yentonces realmente su impacto en otros ciclos de vida es mínimo lo más posible y la documentación dede los requisitos dentro de cada ciclo de vida es importante.Así, el requisitos que deben registrarse para cada ciclo de vida por separado. Por lo tanto, comomencioné los requisitos son diferentes para cada ciclo de vida y por lo tanto, necesitamos
registre estos requisitos para cada ciclo de vida por separado, la pregunta es ahora ¿cómo podemosrealmente escribir un buen requisito?(Consulte la hora de la diapositiva: 07:40)
Veamos cómo hacemos eso. Por lo tanto, un punto importante aquí es que usted debe usar las palabrascon juiciosamente no usar las palabras sin pensar sin entender la importanciade cada palabra que usamos. Por lo tanto, debemos utilizar para indicar la naturaleza limitantede un requisito. Por lo tanto, si usted tiene una naturaleza limitante de un requisito donde podemos teneralgún tipo de cambio o un compromiso y debemos usar la palabra deberá.Representará las declaraciones de hecho así que si usted tiene algunas declaraciones de hecho que esya existente y usted no tiene ningún control sobre entonces usted lo dice como una voluntad ydebería ser usada en declaraciones de objetivos. Por lo tanto, si usted tiene algunos objetivos particulares a serlogrado. Por lo tanto, siempre debe decir que debe usar la palabra si esto es básicamente sitiene algunos requisitos de seguridad particulares o la respuesta que los requisitos entoncesdeberíamos decir que el sistema debe responder a una emergencia en 5 segundos o que el sistemadebe acelerarse en 2 segundos. Por lo tanto, ese tipo de una sentencia de objetivo debe serespecificado utilizando debe. Entonces de nuevo no utilizan y/o por lo tanto esto de nuevo una confusa declaración de, no utilizan el y/o así el uso y o en caso de que me refiero a donde seanecesario no poner esta opción para que un lector interprete de una manera diferente.Y nunca empezar con si es así no iniciar ningún requisito dentro de si, porque si otra vezconfundiendo a un lector en la etapa posterior o una persona que está pasando por el requisito.
Por lo tanto, puede interpretarlo de una manera diferente, así que nunca utilice un si. De manera similar, los verbos no específicoscomo maximizar, minimizar o adjetivos como fáciles, flexibles, robustos, adecuados, suficientesetc., deben ser evitados.Debido a que todos estos son muy subjetivos maximizan al máximo. Así que, cuando usted dice maximizar.Así que, nadie sabrá lo que es realmente lo máximo que queremos y entonces de nuevo la otra vez essubjetivo y depende de la situación, de manera similar minimizar o adjetivos como fácilflexibles robustos estos son todos no muy objetivo. Por lo tanto, debemos evitar este tipo de verbos no específicos dey asegurarnos de que lo que lo especifique un objetivo muy objetivo y esmuy claramente comprensible para cualquier persona que esté pasando por estos requisitos.(Consulte el tiempo de la diapositiva: 09:57)
Veremos algunos ejemplos así que cada vez que escribimos este requisito empezamos con el sistemade interés supongamos que si es un sistema de ascensor o es un teléfono móvil o es una red móvilo un sistema de televisión, deberíamos iniciar el requisito con el sistemade interés ir seguido de una frase de verbo empezar con la palabra deberá o debeen función de la situación y ser seguido por un objeto que describe una salida de entraday terminar con las condiciones bajo las cuales la anterior era verdadera. Por lo tanto, esta es la forma en que los requisitos denecesitan ser escritos.Por lo tanto, empezamos con el sistema de interés seguido por una frase de verbo que lo inicia la palabrao debe o debe depender de la situación y luego seguir por un objeto que
describe la entrada o salida de lo que es nuestro requisito y termina con las condiciones bajoque es verdad.Así que, esta es la forma en que usted escribe un requisito, por ejemplo, puede ver aquí estoy escribiendoque el sistema de desarrollo recibirá entradas de los interesados. Por lo tanto, si tiene un sistemaestamos hablando de un sistema en el que se está discutiendo la fase de desarrolloy deberíamos decir que este sistema de desarrollo recibirá aportaciones de las partes interesadas. Por lo tanto,es una sentencia de requisito. Por lo tanto, el sistema debe ser capaz de recibir la entrada de los interesados de.Así que, sean cuales sean las entradas, el sistema debe ser capaz de aceptar estas entradasy ese es el único requisito. Del mismo modo, el sistema de fabricación tendrá una tasa de rasppage dede x por ciento o cualquiera que sea el porcentaje 1. Por lo tanto, no diga que una tasa de rasppage mínima detasa de rasppage. Por lo tanto, eso no es aceptable, usted debe escribir lo quees la cantidad que es aceptable o cuál es la cantidad que es aceptable el sistema de fabricación detendrá una tasa de rasppage de x porcentaje.Así que, usted tiene claramente diciendo que ese es el rango aceptable y si está más allá de lo queno es aceptable, el sistema de retiro causará menos que valor particular x dólar o xrupias lo que sea. Por lo tanto, el sistema de jubilación del sistema que el costo de la jubilación o el costode disponer del sistema debe ser menor que un valor particular. Por lo tanto, es muy claroque no hay confusión por aquí hay que decir claramente que el costo de la jubilacióndebe ser menor que el valor particular.Del mismo modo, el sistema detiene el flujo de hidrógeno líquido en 0,5 segundos o menos de nuevo estamosdiciendo que 0,5 segundos es la limitación o puede ir menos que eso, pero no más que esomuy claramente diciendo que el sistema, debe detener el flujo de hidrógeno líquido enalgunos casos que tiene un sistema para el control del hidrógeno líquido entonces estamos diciendo queeste sistema de control debe detener el flujo de hidrógeno líquido en 0.5 segundos o menos.Por lo tanto, puede ver claramente aquí y no utilizar palabras como maximizar o minimizar u otros anuncios deen realidad estamos haciendo algunas declaraciones en realidad no es realmente el objetivo de. Por lo tanto, no damos ninguna evaluación subjetiva o valores subjetivos aquí.Se mencionará claramente cuál es el requisito real o cuál es la expectativa real dedel sistema. Por lo tanto, este es el modo en que escribimos el requisito para el sistema.
(Consulte el tiempo de la diapositiva: 12:54)
Y de nuevo estos requisitos de origen podemos anotar la clasificación ya queha mencionado que hay requisitos de salida de entrada y requisitos deen todo el sistema de tecnología. Por lo tanto, todos ellos están realmente escritos en la misma forma de moda o como lo hemos mencionado endiapositiva anterior. Por lo tanto, los requisitos de salida de entrada básicamente consisten ende la entrada y la salida que es la entrada que entra en el sistema y qué es la salida deque va del sistema. Por lo tanto, para el caso del elevador se puede decir que el sistemadará una indicación del estado del elevador.Por lo tanto, el sistema debe tener una instalación para dar una indicación de salida del estado de si esen condición de trabajo o trabajo en el que para el elevador es en la actualidad el sistema debe sercapaz de dar esa salida. Por lo tanto, ese es el requisito de salida de entrada uno de los requisitos de salidaidentificados el sistema aceptará solicitudes de todos los pisos. Por lo tanto, de nuevo estees un requisito de entrada que el sistema de ascensores aceptará solicitudes de todos los pisos.Por lo tanto, todo el piso debería ser que debería haber una instalación para que el elevador acepte las solicitudes dede todos los pisos que de nuevo un requisito de entrada entonces el sistema dará una retroalimentación deal usuario sobre la solicitud.Así que, cada vez que el usuario da una entrada al sistema y el sistema debe ser capaz de dar una salida deen realidad es estado; cuál es el estado de esa solicitud en particular. Por lo tanto, el sistemadará una respuesta al usuario sobre la solicitud que el sistema solicitará al usuario para queseleccione la opción, de nuevo el sistema utilizará el indicador de que el usuario debe seleccionar la opción
suponga que hay muchas opciones y, a continuación, el sistema debe dar una opción o solicitar al usuario deque seleccione la opción concreta para esa situación en particular el sistema verificará la identidad de. Por lo tanto, si existe un requisito, el sistema debe ser capaz de identificarel, verificar la identidad de la persona o la identidad de ese requisito concreto o la opción particular dedada por el usuario.Por lo tanto, estos son los requisitos de salida de entrada típicos para un sistema. Por lo tanto, trataremos de identificaren las conferencias anteriores que hemos discutido sobre el escenario de rastreo del escenario de rastreo de salida de entradadescripción y todo. Por lo tanto, estos casos de ejemplo nos darán los requisitos o identificamos el requisito dede este escenario y en función de estos casos de ejemplo, intentaremos escribirestos requisitos, tal como se muestra aquí. Por lo tanto, estos son algunos ejemplos de cómo se escriben los requisitos de.(Consulte la hora de la diapositiva: 15:17)
De forma similar, para los requisitos de todo el sistema o de tecnología en este caso, escribiremos el sistema de ascensoresque se ajustará a la acción de personas con discapacidad. Por lo tanto, es una tecnología o un requisito dede todo el sistema que no proviene del rastreo de salida de entrada. Esto vienedesde la tecnología o el requisito de todo el sistema o el contexto en el que se está utilizando el sistema. Por lo tanto, el sistema cumplirá con la acción de las personas con discapacidad, pero el software del sistemase escribirá en C++ o en algunos otros idiomas, cualquiera que sea el idioma, cualquiera que sea el software o el sistema operativo que desee utilizar.
Por lo tanto, esto puede especificarse en el requisito de que esto pueda tener algún impacto en el otro ciclo de vida de. Por lo tanto, es por eso que se escribe específicamente dado que el requisito o el software del sistemase debe escribir en un idioma en particular. Del mismo modo, la comunicación del sistemaserá a través de una norma particular, inalámbrica o con cable o satisfacción. Por lo tanto, sitiene hay comunicaciones entre el sistema y es un sistema externo.Por lo tanto, podemos escribir el requisito de la comunicación qué tipo de protocolo se utilizao qué tipo de método se debe utilizar para la comunicación si es una comunicación amplia deo una comunicación inalámbrica y cuáles son los estándares que son los estándares deque se utilizan para la comunicación, estas cosas se pueden mencionar como un requisito de. Del mismo modo, el coste de funcionamiento del sistema será un guión de rupias al añoy cualquiera que sea el importe. Por lo tanto, usted escribirá que también el costo operativo debe ser hechomenos que un valor en particular.Así que, ese es un requisito, por supuesto, el dependiendo del diseño adicional y el desarrollo adicional deesto puede cambiar, es por eso que hay un no es una declaración convincente, peroes objetivo lo que realmente los diseñadores están esperando lograr. Por lo tanto, el coste de explotación del sistemaserá de una rupias x al año. Por lo tanto, estos son los requisitos de tecnología del sistemapara este caso en particular.(Consulte la hora de la diapositiva: 17:03)
Y así es como escribimos en ORD la estructura estándar de una ORD se muestra aquí ya quepuede ver todos los documentos de requisitos de origen en realidad a como he mencionado que es un ciclo de vida.(Consulte la hora de la diapositiva: 07:15)
Por lo tanto, cada ciclo de vida estará teniendo sus propios requisitos. Por lo tanto, el documento de requisito dede origen registrará realmente todos estos requisitos a lo largo del ciclo de vidadel sistema. Por lo tanto, el ORD comienza con una introducción o visión general del sistema. Por lo tanto, lo que el sistemaes lo que realmente está pensado para lo que son los conceptos básicos o el concepto operativoque los diseñadores están planeando usar y que en realidad le diremos la visión general de un sistemadel sistema. Por lo tanto, cualquiera que esté pasando por esto requiere este documento.Usted entiende lo que el sistema es para y cuáles son los que son los conceptos básicos de funcionamiento deque los diseñadores están planeando implementar que es la visión general del sistema y luego voy adar los documentos aplicables cuáles son los diferentes documentos aplicables a este requisitoen particular puede haber muchos estándares puede haber este acto de discapacidad olas normas de construcción o normas de seguridad hay estándares internacionales y los estándares nacionales. Por lo tanto, aquellos documentos que sean aplicables a este diseño en particular seránmencionados en la sección de documento aplicable y luego comenzaremos a escribir los requisitos de.Así que, como mencioné los requisitos están escritos para diferentes fases. Por lo tanto, empezamos con los requisitos de fase de desarrollo de. Por lo tanto, que un requisito de fase de desarrollo en sí mismo puede ser
clasificado en requisito de salida de entrada, requisito de tecnología de todo el sistema, requisitos dede comercio y requisitos de cualificación, estas son las 4 categorías de requisitospara la fase de desarrollo.(Consulte la hora de la diapositiva: 18:47)
Por lo tanto, bajo los requisitos de la sección comenzamos con los requisitos de fase de desarrolloy luego vamos para el requisito de la fase de fabricación y el despliegue
fase de entrenamiento de fasey todo el otro ciclo de vida identificado para este sistema en particular, anota el requisito de, de nuevo para la fase de fabricación también intenta averiguar cuál es el requisito de salida dede entrada, cuál es el requisito de toda la tecnología y de todo el sistema, el comercio de requisitos dey requisitos de cualificación.Por lo tanto, estos 4 serán por lo tanto todos los demás ciclos de vida también. Así, comenzaremos con el requisito de la fase de desarrollo dey, a continuación, la fase de fabricación volverá a escribir3.2.1 como requisito de salida de entrada 3.2.2 a un requisito de todo el sistema y la tecnología,entonces 3.2.3 como requisitos comerciales y luego dependiendo de los requisitos de quesean subclases o subdivisiones de nuevo vamos a dar la numeración según los requisitosidentificados aquí. Por lo tanto, esta es la estructura general de una ORD.
(Consulte la hora de la diapositiva: 19:36)
Por lo tanto, como puede ver que hay diferentes fases en la fase operativa de la fase de entrenamiento, la fase de mejora del sistema, la fase de retiro y, a continuación, un comercio general de requisitos,también el requisito de compensación global será el identificado por los diseñadores.(Consulte la hora de la diapositiva: 19:46)
Por lo tanto, dependiendo del curso dependiendo del rendimiento o se identifican el requisito general de comercio deque puede ser aplicable a todos los ciclos de vida. Por lo tanto, esta es la estructuray de nuevo estaremos teniendo otros conceptos operativos de apéndice por fase.Así que, diferentes conceptos operativos por fase se desarrollan durante la fase de desarrollo
y, a continuación, el diagrama de sistema externo por fase o si hay distintas fases, habrádistinto diagrama de sistema externo porque la interacción puede ser diferente. Por lo tanto,identificará también el diagrama del sistema externo y lo pondrá todo esto bajo los apéndices.Por lo tanto, esta es la estructura general de un documento de requisitos de origen. Por lo tanto, la primera partedel diseño que es básicamente la fase de desarrollo o que identifica el problemay el problema de diseño de nivel del sistema y lo hizo la salida final es un documento de requisitos dede origen operativo. Como he mencionado en las conferencias anteriores que empezamos con las entradas de los interesados de, pasamos por diferentes etapas; como el desarrollo de conceptos, los escenarios de operación de rastreo de salida de, los requisitos de compensación y pasar por el requisito de análisis dey la documentación de requisitos y gestión de requisitos. Y al finalde esta fase estará obteniendo el documento de requisitos de origen como la salida de esta fase de desarrollo en particular de. Por lo tanto, el problema de diseño de nivel del sistema recibirá ORD comola salida de esta fase en particular.(Consulte la hora de la diapositiva: 21:18)
Por lo tanto, para resumir todo lo que discutimos en las dos últimas conferencias básicamente discutimossobre el problema de diseño de nivel del sistema como la primera función inicial del proceso de diseñodiscutimos que hay 6 funciones.Y la primera es el problema de diseño de nivel del sistema y luego, bajo esto discutimossobre los conceptos operativos cómo se desarrolla una operación muy preliminar
conceptos y, a continuación, cómo identificar los sistemas externos, cómo se observan los requisitos de origen de, cómo nos fijamos en la jerarquía de objetivos y, a continuación, cómo documentar y gestionarrequisitos.Por lo tanto, estos son los temas que cubrimos bajo el problema de diseño de nivel del sistema, pero ahora espara tomar pocos ejemplos y explicar cómo pasamos realmente por estas fases y desarrollarla ORD para el caso en particular. Por lo tanto, para hacerlo, permítanme que vaya a un ejemplo particularque ya hemos discutido en lo que se refiere a esto iré al mismo diseño de ascensor yluego pasar por los diferentes escenarios de operación y el requisito operativo y luegovemos cómo realmente escribimos el requisito para este sistema en particular.(Consulte la hora de la diapositiva: 22:27)
A medida que conoce los escenarios de fase operativa, es el primer paso para identificar los requisitos de. Por lo tanto, tenemos diferentes escenarios. Por lo tanto, uno de los escenarios que yadiscutimos sobre esto cómo los pasajeros utilizan el sistema. Por lo tanto, escribimos claramente los pasos deinvolucrados en el uso del sistema por un usuario el pasajero.Por lo tanto, decimos que los pasajeros, incluyendo la movilidad visual y el desafío auditivo, solicitan el servicio derecibir comentarios de que la solicitud fue aceptada, recibir la entrada de que el coche de ascensorse acerca y luego que una oportunidad de entrada está disponible, entrar en el coche de ascensor, solicitar el piso, recibir comentarios de que la solicitud fue aceptada, recibir comentarios de que la puerta está cerrando, recibir comentarios sobre qué piso en el que el ascensor se detiene, y recibir
feedback que una oportunidad de salida está disponible, y el elevador de salida sin ningún impedimento físico.Por lo tanto, tenemos claramente explicando todos los pasos involucrados en el uso de un elevador por parte de un pasajeroy que en realidad incluye la movilidad o visualmente o escuchar a las personas también.Ahora una vez que tengamos este escenario haremos un rastreo de salida de entrada para averiguar quéde interacciones están sucediendo entre estos 2 el sistema y esun sistema externo.(Consulte el tiempo de la diapositiva: 23:43)
Por lo tanto, aquí se identifica el ascensor como un sistema y el pasajero como un sistema externo. Por lo tanto, siel pasajero pedirá una solicitud de servicio para arriba y luego hay muchos comentarios dela solicitud de retroalimentación del ascensor fue recibida, la retroalimentación de que el coche está en el camino, la retroalimentación que la puerta deestá abriendo, y luego se proporciona una oportunidad de entrada. Por lo tanto, esto realmente muestra quehay 4 tipos de comentarios que van desde el ascensor y esto realmente identifica los requisitos detambién el requisito de salida del ascensor.Por lo tanto, este era un requisito de entrada para el ascensor que una solicitud de servicio de subida que necesitapara ser aceptado y estos 4 realmente indica los requisitos de salida del ascensor, es decir,o el ascensor debe dar este tipo de salida al pasajero. Y entonces habráotra entrada del pasajero o del sistema externo que la solicitud de harina o la solicitud del piso requerido porse da al ascensor.
Por lo tanto, esta solicitud utiliza otros requisitos básicamente el pasajero debe estar allí debeser una opción para un o el pasajero para dar las entradas y debe haber una instalación paraaceptar esa entrada y luego para procesar esa entrada en una etapa posterior por el ascensor. Y luegouna vez que tenga la entrada se recibe que por el elevador entonces la retroalimentación que se le daráhay 2 comentarios aquí lo siento más de 2 hay una retroalimentación que la solicitud fuerecibida, hay una retroalimentación que la puerta está cerrando, hay una retroalimentación acerca de donde elque para el ascensor se detuvo, y la retroalimentación que la puerta se abre después de llegar a ese pisoen particular y hay una oportunidad de salida proporcionada.Así que, todos estos son la salida del ascensor. Por lo tanto, el sistema de ascensor y hemos diseñadoeste ascensor que debemos identificar son los requisitos de salida del ascensor. Por lo tanto,puede ver que utilizando este diagrama el rastreo de salida de entrada puede ver realmente; qué esel requisito de entrada y cuáles son los requisitos de salida para este caso de ejemplo en concreto.Al igual que esto, podemos identificar muchos otros escenarios e intentar identificar todos los requisitos.(Consulte la hora de la diapositiva: 25:38)
Por ejemplo, hay otro escenario en el que el pasajero entra en el coche de ascensor como se describe enuno que en el mismo escenario anterior, pero encuentra una situación de emergencia antes de que se presente una oportunidadde salida.Por lo tanto, hay una situación de emergencia que puede ser algo que puede ser un mal funcionamiento de un sistemao dentro del ascensor o hay algo de humo en el interior o hay algún otro
Ascensores algún peligro para la vida de la persona o algún robo en su interior o lo que sea