Loading

Alison's New App is now available on iOS and Android! Download Now

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

    +

Oggi discuteremo dei requisiti originari e della documentazioneper lo sviluppo del sistema.(Fare Slide Time: 00.32)
Nella lezione precedente abbiamo discusso della classificazione dei requisiti, quindi della partizione dei requisitie poi della gestione dei requisiti; come abbiamo visto circa i requisiti dell'articolo di configurazione, requisiti del sistema dei requisiti dei componenti e quindirequisiti di missione e requisiti di missione, come effettivamente classifichiamo e comeli dividiamo in diverse categorie.E oggi quello che faremo è vedere come facciamo in realtà una documentazione di requisito eche è nota come documentazione dei requisiti originari. Quindi, noipasseremo attraverso questo processo i passi coinvolti in base ai requisiti.
(Riferimento Slide Time: 01.03)
Quindi, l'idea di base è che il requisito debba essere scritto in modo chiarissimomodo che siano i requisiti che ci saranno in tutto il processo di progettazionedurante tutto il ciclo di vita del progetto o del sistema e ci saranno molte persone che utilizzanoquesto requisiti in varie fasi e in varie circostanze. Tutti dovrebberocapire il requisito allo stesso modo previsto dalla persona che effettivamenteha scritto i requisiti.Quindi, dovrebbe essere molto chiaro che debba essere inequivocabile e non ci sia confusionesu ciò che è scritto o non può essere interpretato in modo diverso. L'importanza di questoin realtà possiamo vedere nella nostra giornata al giorno anche ogni volta che comunichiamo con il popolopotremmo dire qualcosa e l'altra persona potrebbe capirlo in modo diverso. Per l'esempiosi vedrà la finestra di dialogo tra la signora Chopra e Gita perché si è pop. Quindi,molto mais ha bisogno solo di 6 tazze Gita dice che ho saltato solo 6 tazze.Insomma 6 tazze di mais poppato non 6 le tazze poppate di 6 tazze ha detto Misses Chopra poiche avresti dovuto dire. Quindi, questo significa, se vuoi qualcosa dovresti raccontarlo correttamente sedà la possibilità a qualcuno di interpreterà in modo diverso allora le cose andranno in undiverso e poi entrambi avranno una cattiva comunicazione. E, questo è molto importante inquesto caso di esigenza di analisi dei requisiti anche scrivendo. Quindi, dovremmo provare a raccontare cosain realtà vogliamo e dovremmo scrivere in maniera univoca in modo inequivocabile qual è il requisitoche particolari requisiti sono un altro esempio qui.
(Riferimento Slide Time: 02.42)
"Si dovrebbe dire cosa vuol dire" la lepre di marzo è andata su “ I do, ” Alice hastilyha risposto; “ almeno intendo quello che dico è la stessa cosa, si sa. ” Così, diciamo quello che sisignifica e intendo quello che dico io che lo stesso che è l'argomento qui è, ma questi chevero sguardo qui “ Non la stessa cosa un po' ” ha detto il Mad Hatter. “ Perché potreste solo comeben dire che io mangio quello che vedo è la stessa cosa che mangio quello che vedo. Così, potete vedere la differenza dinon è uguale a quello che si dice io vedo quello che io mangio e mangio quello che vedo sonototalmente diversi.Quindi, dovremmo fare in modo che ogni volta che comunichiamo qualunque cosa record dovremmo esserecorrettamente registrati e correttamente scritti. Quindi, che tutti lo comprendano nello stesso modoquello che abbiamo inteso.
(Riferimento Slide Time: 03.29)
Le caratteristiche del requisito del suono così ogni qualvolta scriviamo il requisito che noidovremmo fare in modo che siano davvero il requisito corretto e lo stiamo scrivendo in modo corretto.Così, so di garantire che il requisito debba essere inequivocabile come vi ho accennatodovrebbe essere comprensibile a tutti. Quindi, non dovrebbe essere messo in un modo molto alto tecnicoo all'interno delle frasi molto complesse, dovrebbe renderla molto semplice ecomprensibile a tutti quelli che dovrebbe essere molto concise non essere molto lungimiranti con tantodi spiegazione, dovrebbe essere molto concise, dovrebbe essere tracciabile la tracciabilità èfondamentalmente si dovrebbe essere in grado di tornare a quel requisito e scoprire dove questo requisito, ma ne verrà richiesto un requisito e qual era l'origine di quel requisito. Quindi, che ci sia qualche problema in fase successiva possiamo tornare indietro e poi correggerequel requisito basato su quella origine di quel requisito. Quindi, ecco perché dovrebbe essererintracciabile e dovrebbe essere design indipendente.Quindi, non dovremmo specificatamente dire che questo requisito è per questo particolare design. Quindi,non dovresti mai dire che ci dovrebbe essere una trasmissione chiara tra particolare tra2 componenti, perché questo diventa un dipendere dal design. Quindi, quel requisito dovrebbenon essere scritto nel modo che dipende da un particolare design. Quindi, dovrebbe esseresempre menzionato in modo indipendente dal design e dovrebbe essere verificabile. Quindi, tudovresti essere in grado di verificare questo requisito in fase successiva qualunque cosa scriviamo come un
il requisito dovrebbe essere verificabile. Altrimenti non c'è motivo di scriverlo perchénon saremmo in grado di verificare se si sta realmente raggiungendo quel particolare requisitoo non similmente dovrebbe essere unico per quel particolare progetto. Quindi, dovrebbenon essere messo in modo molto comune o dovrebbe essere molto specifico per questo particolare sistema.Dovrebbe essere completo. Quindi, il che non è una dichiarazione parziale dovrebbe essere una frasecompleta o una dichiarazione completa di requisito, dovrebbe essere coerente con gli altri requisitianche lì potrebbero esserci molti requisiti nel sistema. Quindi, dovrebbe esserecoerente con altri requisiti non dovrebbe essere contraddittorio rispetto ad altri requisiti inil requisito generale del sistema dovrebbe essere modificabile. Quindi, in qualsiasi momento si dovrebbeessere in grado di modificare tale requisito a seconda della situazione, in quanto una situazione vi sorgepotrebbe scoprire che questo requisito non è quello che in realtà si desidera allora si deve esserein una posizione per modificare questo requisito analogamente dovrebbe essere raggiungibile.Quindi, è necessario essere in grado di raggiungere tale requisito o si dovrebbe essere in grado di soddisfare tale requisitoattraverso alcuni mezzi. Quindi, non bisogna scrivere qualcosa che èimpossibile da realizzare. Così, entra in scena la fattibilità del requisito. Quindi, ioviso garantirò che sia raggiungibile. Ecco, queste sono le buone caratteristiche di scrivere un requisito.Così, ogni esigenza dovrebbe davvero cercare di seguire tutte queste caratteristiche. Quindi, chetutti possano capirlo nessuno lo interpreterà in modo diverso e questi sonopossibile e fattibile requisito per il sistema.
(Riferimento Slide Time: 06.09)
Così, una volta che hai queste caratteristiche di base dovresti vedere come scriviamo il documento. Quindi, questo è il documento per lo sviluppo del sistema è noto come documento di requisitioriginario o in breve ORD. Quindi, questo è il documento in cui in realtà noiscriviamo o regiamo tutti questi requisiti e assiciamone che questi siano fattibili esiano comprensibili a tutti. Quindi, i requisiti e le opzioni di progettazione interagisconoattraverso le fasi del ciclo di vita. Quindi, questo è importante perché attraverso il ciclo di vita questirequisiti interagiscono.Quindi, ecco perché dobbiamo fare in modo che la nostra ORD prenda i diversi cicli di vita dii requisiti di sistema in una fase del ciclo di vita avranno spesso un grande impatto sula progettazione di un sistema in un'altra fase. Così, come ho accennato di noi nel sistema, noianalizzeremo il ciclo di vita del sistema. Quindi, ci sarà un'interazione di questo requisitosui cicli di vita del sistema e ci sarà molto impatto su un altro ciclo di vita.Quindi, i requisiti di fase di progettazione avranno un impatto maggiore sulla fase di fabbricazioneanalogamente il requisito della fase di fabbricazione potrebbe incidere sulla fase operativaquindi, dobbiamo fare in modo che questo requisito ciò che identifichiamo siano coerenti epoi in realtà il loro impatto su altri cicli di vita sia minimo il più possibile e la documentazionedei requisiti all'interno di ogni ciclo di vita è importante.Così, il requisiti devono essere registrati per ogni ciclo di vita separatamente. Così, siccome ioho menzionato i requisiti sono diversi per ogni ciclo di vita e quindi, dobbiamo
registra questi requisiti per ogni ciclo di vita separatamente la domanda è ora come facciamo aeffettivamente scrivere un buon requisito?(Fare Slide Time: 07.40)
Vediamo come facciamo. Quindi, un punto importante qui è che bisogna usare le parolecon la magistratura non usare le parole senza pensare senza capire l'importanzadi ogni parola che usiamo. Quindi, dovremmo usare per indicare la natura limitantedi un requisito. Quindi, se hai una natura limitante di un requisito in cui possiamo averequalche tipo di scambio o di compromesso e dovremmo usare la parola deve.Will rappresenta le dichiarazioni di fatto, quindi se hai alcune dichiarazioni di fatto che ègià esistente e non hai alcun controllo su allora lo dici come un sarà edovrebbe essere utilizzato in istruzioni di obiettivi. Quindi, se hai alcuni obiettivi particolari da raggiungereraggiunto. Quindi, dovresti sempre dire che dovresti usare la parola che dovrebbe essere in sostanza sehai alcuni particolari requisiti di sicurezza o la risposta che requisiti allora noidovremmo dire che il sistema dovrebbe rispondere ad un'emergenza in 5 seconds secondi o che il sistemadovrebbe accelerare entro 2 seconds minuti. Quindi, quel tipo di dichiarazione di obiettivo dovrebbe esserespecificato utilizzando. Poi di nuovo non utilizzare e / o quindi questa volta di nuovo una dichiarazioneconfusa, non usare l'e / o così usare e o in caso di intendo dire ovunque sianecessario non inserire questa opzione per un lettore per interpretare in modo diverso.E non iniziare mai con se così non si avvia alcun requisito all'interno se, perché se di nuovo noiconfondiamo to un lettore in fase successiva o una persona che sta attraversando il requisito.
Così, lo può interpretare in modo diverso quindi non usare mai un se. Allo stesso modo i verbi non specificicome massimizzare, minimizzare o aggettivi come facili, flessibili, robusti, adeguati, sufficientietcetera dovrebbero essere evitati.Perché questi sono tutti molto soggettivi maximize minimizza. Quindi, quando dici di massimizzare.Così, nessuno saprà cosa è effettivamente massimo che vogliamo e poi ancora di nuovo èsoggettivo e dipende dalla situazione, analogamente minimizzare o aggettivi come faciliflessibili robusto questi sono tutti non molto oggettivi. Quindi, dovremmo evitare questi tipi diverbi non specifici e fare in modo che qualunque cosa lo specifichiamo un obiettivo molto oggettivo ed èmolto chiaramente comprensibile a qualsiasi persona che sta attraversando questi requisiti.(Fare Slide Time: 09.57)
vedremo alcuni esempi così ogni volta che scriveremo questo requisito iniziamo con il sistema di interessesupponiamo se si tratta di un sistema di ascensore o si tratta di un telefono cellulare o si tratta di una rete mobileo di un sistema televisivo, dovremmo iniziare il requisito con il sistemadi interesse essere seguito da una frase verbo che inizia con la parola o dovrà o dovràa seconda della situazione ed essere seguito da un oggetto che descrive un'emissione di inpute termina con le condizioni in cui il precedente era vero. Quindi, questo è il modo in cui i requisiti di buondevono essere scritti.Così, iniziamo con il sistema di interesse seguito da una frase verba a partire dalla paroladovrà o sarà o dovrebbe dipendere dalla situazione e poi seguire da un oggetto che
descrive l'input o l'output qual è il nostro requisito e termina con le condizioni sottoche è vero.Così, questo è il modo in cui scrivi un requisito per esempio, potete vedere qui sto scrivendoche il sistema di sviluppo riceve input da stakeholder. Quindi, se si dispone di un sistemastiamo parlando di un sistema in cui la fase di sviluppo viene discussae dovremmo dire che questo sistema di sviluppo riceve input dagli stakeholder. Quindi,che è una dichiarazione dei requisiti. Quindi, il sistema dovrebbe essere in grado di ricevere l'input dastakeholder.Quindi, qualunque sia gli input presenti il sistema dovrebbe essere in grado di accettare questi inpute questo è l'unico requisito. Analogamente il sistema di fabbricazione deve avere un tasso di rottamazionedi x percentuale o qualunque sia la percentuale 1. Quindi, non dire che un tasso di rottamazione minimo del tasso di rottamazione. Quindi, non è accettabile scrivere quello cheè l'importo che è accettabile o qual è la quantità che è accettabile il sistema manifatturieroha un tasso di rottamazione di x percentuale.Quindi, hai chiaramente detto che quella è la gamma accettabile e se è oltre quella chenon è accettabile, il sistema pensionabile deve provocare meno di particolare valore x dollaro o xruba qualunque esso sia. Quindi, il sistema pensionabile il sistema il costo del pensionamento o del costodi smaltimento del sistema dovrebbe essere inferiore a un valore particolare. Quindi, è molto chiaroche qui non c'è confusione che bisogna dire chiaramente che il costo della pensionedovrebbe essere inferiore a un valore particolare.Allo stesso modo il sistema interrompa il flusso di idrogeno liquido in 0,5 secondi o meno ancora siamodicendo che 0,5 secondi sono i limiti o può andare meno di quello, ma non più di quellomolto chiaramente detto che il sistema, dovrebbe fermare il flusso di idrogeno liquido inalcuni casi hai un sistema per il controllo dell'idrogeno liquido poi stiamo dicendo chequesto sistema di controllo dovrebbe fermare il flusso di idrogeno liquido nel 0,5 secondi o meno.Quindi, potete chiaramente vedere qui e non usare parole come massimizzare o minimizzare o altri spotin realtà stiamo facendo alcune dichiarazioni in realtà non è davvero l'obiettivo. Quindi, non diamo alcuna valutazione soggettiva o valori soggettivi qui sopra.Sarà chiaramente menzionato qual è il requisito effettivo o qual è l'effettivaaspettativa dal sistema. Ecco, questo è il modo in cui scriviamo il requisito per il sistema.
(Riferimento Slide Time: 12.54)
E di nuovo questi requisiti originari possiamo scrivere la classificazione come ioaccennato che ci sono requisiti di output in ingresso e requisiti di sistema di tecnologia. Quindi, questi sono tutti effettivamente scritti nello stesso modo di moda o come noicitato nella slide precedente. Quindi, i requisiti di output in ingresso sostanzialmente sono costituiti dadi input e output che è quello che è l'input in arrivo nel sistema e cosa è l'outputche va dal sistema. Quindi, per il caso di ascensore si può dire che il sistema devedare un'indicazione sullo stato dell'ascensore.Quindi, il sistema dovrebbe avere una struttura per dare un'indicazione di output dello stato se èin condizioni di lavoro o di lavoro in cui per l'ascensore è presente il sistema dovrebbe esserein grado di dare quell' output. Quindi, cioè il requisito di output in ingresso uno dei requisiti di outputidentificati il sistema accetta le richieste da tutti i pavimenti. Quindi, ancora questoè un requisito di ingresso che il sistema dell'ascensore accetterà le richieste da tutti i pavimenti.Quindi, tutto il pavimento dovrebbe essere che ci debba essere una struttura per l'ascensore per accettarerichieste da tutti i pavimenti che di nuovo un requisito di ingresso poi il sistema deve dare un feedbackall'utente circa la richiesta.Quindi, ogni qualvolta l'utente dà un input al sistema e il sistema dovrebbe essere in grado di dare un outputin realtà sarà lo stato; qual è lo stato di tale particolare richiesta. Quindi, il sistemadà un feedback all'utente circa la richiesta che il sistema richieda all'utente diselezionare l'opzione, di nuovo il sistema deve utilizzare il prompt dell'utente per selezionare l'opzione
supportano che ci siano molte opzioni e poi il sistema dovrebbe dare un'opzione o richiedere all'utentedi selezionare l'opzione particolare per quella particolare situazione il sistema deve verificare l'identità. Quindi, se c'è un requisito allora il sistema deve essere in grado di identificareil, verificare l'identità, l'identità della persona o l'identità di quel determinato requisito o laopzione particolare data dall'utente.Quindi, questi sono il tipico requisito di output in ingresso per un sistema. Quindi, cercheremo di identificarenelle lezioni precedenti abbiamo discusso dello scenario di traccia dello scenario della traccia di inputdescrizione e tutti. Quindi, questi scenari ci daranno i requisiti o identifichiamo il requisitoda questo scenario e basato su questi scenari cercheremo di scrivere in bassoquesti requisiti come mostrato qui. Ecco, questi sono alcuni esempi di come scriviamo unrequisiti validi.(Fare Slide Time: 15.17)
Allo stesso modo, per i requisiti di sistema o di tecnologia in questo caso scriveremo il sistema dell'ascensoredevono rispettare i disabili agiscono. Quindi, cioè una tecnologia o un requisito di sistemaampio non viene dalla traccia di output in ingresso. Questo viene in arrivodalla tecnologia o dall'ampio requisito di sistema o dal contesto in cui viene utilizzato il sistema. Quindi, il sistema deve rispettare le persone disabili che agiscono, ma il software di sistemadeve essere scritto in C++ o in alcune altre lingue qualunque siano le linguequalunque sia il software o il sistema operativo che vogliano utilizzare.
Quindi, questo può essere specificato nel requisito questo potrebbe avere qualche impatto sull'altro ciclo di vita. Ecco allora che è scritto il dato specificatamente dato che il requisito o il software di sistemadovrebbero essere scritti in una lingua particolare. Allo stesso modo la comunicazione del sistemadeve essere tramite wireless o cablata o soddisfare particolari norm. Quindi, seci sono le comunicazioni tra il sistema ed è sistema esterno.Così, possiamo scrivere il requisito della comunicazione quale tipo di protocollo essereusato o quale tipo di metodo da utilizzare per la comunicazione se si tratta di una comunicazione estesao di una comunicazione wireless e quali sono gli standard quali sono gli standardutilizzati per la comunicazione, queste cose possono essere menzionate come requisito. Allo stesso modo il costo di esercizio del sistema è un trattino rupie per annatae qualunque sia l'importo. Così, scrivi che anche il costo operativo dovrebbe essere resomeno di un valore particolare.Quindi, questo è un requisito ovviamente, il a seconda dell'ulteriore design e ulterioresviluppo questo può cambiare per questo motivo c'è una non è una dichiarazione avvincente, maè obiettivo quello che in realtà i progettisti sperano di ottenere. Quindi, il costo operativo del sistemadeve essere una rupie x all'anno. Quindi, questi sono i requisiti di tecnologia del sistemaper questo caso particolare.(Fare Slide Time: 17.03)
Ed è così che scriviamo in ORD la struttura standard di un ORD viene mostrata qui come voipotete vedere ogni documento di esigenza originario in realtà a cui ho accennato questo è un ciclo di vita.(Fare Slide Time: 07.15)
Così, ogni ciclo di vita vi farà possedere dei requisiti. Quindi, il documento di requisitooriginario registrerà effettivamente tutti questi requisiti per tutto il ciclo di vitadel sistema. Quindi, l'ORD inizia con una panoramica introduzione o di sistema. Quindi, quello che il sistemaè quello che in realtà è significato per quali sono i concetti di base o il concetto operativoi progettisti stanno progettando di utilizzare e che in realtà vi racconteremo il dare la panoramica di sistemadel sistema. Quindi, chi sta attraversando questo richiede questo documento.Capirete cosa è il sistema per e quali sono i concetti di base operativiconcept designers stanno progettando di implementare che è la panoramica del sistema e poi iodarò i documenti applicabili quali sono i diversi documenti applicabili a questo particolare requisitopotrebbero esserci molti standard ci possono essere questo atto di disabilità ogli standard edilizi o le norme di sicurezza ci sono gli standard internazionali e gli standard nazionali. Quindi, quei documenti che sono applicabili a questo particolare design sarannomenzionati nella sezione documenti applicabile e poi inizieremo a scrivere i requisiti.Così, come ho accennato i requisiti sono scritti per diverse fasi. Quindi, iniziamo con i requisiti di fase di sviluppo. Quindi, che un requisito di fase di sviluppo stesso possa essere
classificati in requisito di output in ingresso, requisito di tecnologia wide - wide, requisiti di commercio - offe requisiti di specializzazione, queste sono le 4 categorie di requisitiper la fase di sviluppo.(Fare Slide Time: 18.47)
Così, sotto i requisiti di sezione iniziamo con i requisiti di fase di sviluppoe poi andiamo per il requisito della fase di produzione e la distribuzione
fase di formazione di fasefase e tutto l'altro ciclo di vita identificato per questo particolare sistema scrivi il requisito, di nuovo per la fase di fabbricazione si cerca anche di scoprire qual è il requisito di outputin ingresso, qual è il requisito di sistema ampio e tecnologico, il trade offrequisiti e requisiti di qualificazione.Così, questi 4 saranno quindi tutti gli altri cicli di vita anche. Così, inizieremo con il requisito di fase di sviluppoe poi ancora la fase di lavorazione scriveremo3.2.1 come requisito di output in ingresso 3.2.2 ad un requisito di sistema ampio e tecnologico,quindi 3.2.3 come requisiti di scambio e poi a seconda di quei requisiti ci possono esseresottoclassi o suddivisioni di nuovo daremo la numerazione come per i requisitiindividuati qui sopra. Ecco, questa è la struttura generale di una ORD.
(Riferimento Slide Time: 19.36)
Così, come si può vedere che ci sono diverse fasi la fase operativa di fase di allenamento, la fase di miglioramento del sistema, la fase di pensionamento, e poi un commercio complessivo dei requisitianche allora il requisito del trade-off complessivo sarà quello individuato dai progettisti.(Fare Slide Time: 19.46)
Così, a seconda del corso a seconda delle prestazioni o si identificano nel complessoil fabbisogno di commercio che può essere applicabile a tutti i cicli di vita. Quindi, questa è la strutturae ancora una volta avremo altre appendice di un concetto operativo per fase.Così, diversi concetti operativi per fase si sviluppa durante la fase di sviluppo
e poi il diagramma di sistema esterno per fase o se diverse fasi ci saràdiverso diagramma di sistema esterno perché l'interazione potrebbe essere diversa. Quindi, quindi,identificherà anche il diagramma di sistema esterno e mettetelo i tutti questi sono sotto le appendici.Così, questa è la struttura generale di un documento dei requisiti originari. Quindi, la primaparte del design che è in sostanza la fase di sviluppo o che identifica il problemae il problema di progettazione del livello di sistema e ha fatto questo l'output finale è un documento di requisiti. Come ho accennato nelle lezioni precedenti iniziamo con gli input degli stakeholder, poi passiamo attraverso diverse fasi; come il concetto di sviluppo, l'inputoutput trace operation scenari, i requisiti di trade-off e passa attraverso l'analisi del requisitopoi la gestione dei requisiti e la documentazione dei requisiti. E alla finedi questa fase verrà ricavato il documento dei requisiti originari come output di questaparticolare fase di sviluppo. Così, il problema di progettazione del livello di sistema sarà ottenere ORD comel'output di questa fase particolare.(Fare Slide Time: 21.18)
Quindi, per riassumere qualunque cosa abbiamo discusso nelle ultime due lezioni praticamente abbiamo discussodel problema di progettazione del livello di sistema come prima funzione iniziale del processo di progettazioneabbiamo discusso che ci sono 6 funzioni.E il primo è il problema di progettazione del livello di sistema e poi sotto questo abbiamo discussodei concetti operativi come si sviluppa una operatività molto preliminare
concetti e poi come si identificano i sistemi esterni, come guardiamo ai requisiti originari, come guardiamo alla gerarchia degli obiettivi e poi come facciamodocumentiamo e gestiamo i requisiti.Così, questi sono gli argomenti che abbiamo coperto sotto il problema di progettazione del livello di sistema, ma ora èper fare pochi esempi e spiegare come realmente attraversiamo queste fasi e sviluppiamol'ORD per il caso particolare. Quindi, per fare questo mi permetti di passare al particolare esempiodi cui abbiamo già discusso in che cosa di questo andrò sullo stesso design dell'ascensore epoi passare attraverso i diversi scenari di funzionamento e il requisito operativo e poivediamo come facciamo in modo che scriviamo il requisito per questo particolare sistema.(Fare Slide Time: 22.27)
Come si conoscono gli scenari di fase operativa in modo che sia il primo passo per identificare i requisiti. Quindi, abbiamo scenari diversi. Così, uno degli scenari che giàabbiamo discusso di questo come i passeggeri usano il sistema. Quindi, scriviamo chiaramente ipassi coinvolti nell'utilizzo del sistema da parte di un utente il passeggero.Così, diciamo che i passeggeri compresi la mobilità visiva e l'udito contestano la richiesta di assistenzaricevono feedback che la richiesta è stata accettata, ricevono input che l'auto dell'ascensoresi avvicina e poi che un'opportunità di ingresso è disponibile, ingresso in ascensore, richiestafloor, ricezione feedback che la richiesta è stata accettata, ricevere feedback che la porta èchiusura, ricevere feedback su quale pavimento in quale ascensore si ferma, e ricevere
feedback che un'opportunità di uscita è disponibile, e uscita dall'ascensore senza impedimenti fisici.Così, abbiamo chiaramente spiegato tutti i passaggi coinvolti nell'utilizzo di un ascensore da parte di un passeggeroe che effettivamente include la mobilità o l'udito o l'udito contestati anche persone.Ora una volta che avremo questo scenario faremo una traccia di output in ingresso per scoprire quale tipodi interazioni sta accadendo tra questi 2 il sistema ed èun sistema esterno.(Fare Slide Time: 23.43)
Così, qui siamo identificati ascensore come sistema e passeggero come sistema esterno. Quindi, seil passeggero chiederà una richiesta di servizio up e poi ci sono molti feedback dala richiesta di feedback dell'ascensore è stata ricevuta, feedback che l'auto è in arrivo, feedback cheporta si apre e poi viene fornita un'opportunità di ingresso. Quindi, questo in realtà dimostra checi sono 4 tipi di feedback che vanno dall'ascensore e questo effettivamente identificano i requisitianche il requisito di uscita dall'ascensore.Quindi, questo era un requisito di ingresso per l'ascensore che una richiesta di servizio su cui hai bisognoper essere accettato e questi 4 in realtà racconta i requisiti di uscita dall'ascensore, cioèo l'ascensore dovrebbe dare questo tipo di output al passeggero. E poi ci saràun altro input dal passeggero o dal sistema esterno che lì la richiesta di farina orichiesta di pavimento è dato all'ascensore.
Quindi, questa richiesta utilizza un altro requisito sostanzialmente il passeggero dovrebbe essere presente chedebba essere un'opzione per un o il passeggero per dare gli input e ci dovrebbe essere una struttura aaccettare quell' input e quindi elaborare quell' input in una fase successiva dall'ascensore. E poiuna volta che si ha l'input viene ricevuto che dall'ascensore poi il feedback da dareci sono 2 feedback qui dispiaciuta più di 2 C'è un feedback che la richiesta è stataricevuta, c'è un feedback che porta la chiusura, c'è un feedback su dove si è fermato ilche per l'ascensore si è fermato, e feedback che la porta si apre dopo aver raggiunto quel determinato livelloe c'è un'opportunità di uscita fornita.Quindi, tutte queste sono l'uscita dall'ascensore. Quindi, il sistema dell'ascensore e abbiamo progettatoquesto ascensore dovremmo identificare questi sono i requisiti di uscita dall'ascensore. Quindi,è possibile vedere che utilizzando questo diagramma la traccia di output in ingresso è possibile vedere realmente; cosa sonoil requisito di input e quali sono i requisiti di output per questo scenario particolare.Come questo possiamo identificare molti altri scenari e cercare di identificare tutti i requisiti.(Fare Slide Time: 25:38)
Per esempio c'è un altro scenario il passeggero entra in un'auto dell'ascensore come descritto inuno che nello stesso scenario precedente, ma trova una situazione di emergenza prima che venga presentata un'opportunità di uscita.Quindi, c'è una situazione di emergenza può essere una cosa che può essere un malfunzionamento di un sistemao all'interno dell'ascensore o ci sono del fumo dentro o ce ne sono altre
elevatore qualche pericolo per la vita della persona o qualche furto all'interno o qualunque cosa