In thelast few classes, we discussed about the first phase of a system development; that is,defining the system level design problem. And in this stage, we basically look at therequirements of the system from the customer point of view as well as from the system adesign point of view, and identify all these requirements and prepare a originatingrequirements document; which is the output of the first level of the identifying thesystem level design problem.We discussed about how do we do these how do we get the requirements, and then howdo we document the requirements; what are the procedures to be followed in documentthis requirements. And we saw one case study example of system level design problemwe took the example of an elevator, and then explained about the how do we actuallydevelop the system level design problem and then get the originating requirementsdocument. In order to emphasize the importance of requirements I will go through onemore simple example I am not be going through the complete details. But I will justexplain how do we approach the problem and then develop the requirements document.
(Refer Slide Time: 01:30)
So, here we mentioned about the failure of a air bag system, one of the classes wementioned about this was mainly because of the a failure in identifying the actualrequirements of the system. So, we look at this case study and see what are the basicrequirements wrongly identified or why the system failed in identifying the or why thesystem developers, failed in identifying the requirements of this particular air bag systemand how it failed.(Refer Slide Time: 02:03)
If you look at this case, you will see that that safety devices which came somewhere inearly 90s it became the cause of death for a notable number of individuals, and therewere severe flows in the design testing and deployment of a deployment requirementsenvisaged during the design.So, not only the design requirements, but the testing requirements as well as thedeployment requirements were wrongly identified, and that was the reason why thisfailed in the initial stages of the development of air bag system. So, whatever the basicrequirements which actually failed in this case are listed here.(Refer Slide Time: 02:36)
As you can see the requirements defined only a single safety scenario on which to basethe design. So, the multiple scenarios as we discusses earlier there were multiplescenarios of operation and a use of the product, but in this case of design only a singlescenario was used. Basically it was designed for a male driver driving at a speed of 30miles per hour, and diving a crash head on crash and that scenario only was consideredwhile developing the system requirements. So, that was one of the faults in identificationof the design requirement where the only singled safety scenario was considered. Andthen the second one no requirement that the airbag remain undeployed during accidentsat sufficiently slow speeds that no lives are in danger.So, this also was not envisaged. So, it was assumed that any case where there is anaccident the airbag should deploy. But in most of the cases when the speed was
sufficiently low, there was no need for the air bag deploy, but the since that was notenvisaged and then it actually led to failure of the airbag system. Third one the testcondition requirements were wrongly identified. Again the under which the conditionsunder which the air bag to be tested for safety was again wrongly identified again. Here adummy driver with a weight of around 70 to 80 kg, and sitting in an upright position,with the hands on a 9-o clock and 3 o clock positions, running at a speed of 30 miles perhour, having a head on collision were the forces are always straight on the front of thecar.So, only this scenario was considered for testing. And most of the cases this was not thecondition, because the head on it is not always head on collision there may be forces actnon-parallel to the vehicle as well as the driver may not be in his upright position, andthe scenario of head on collision when this a driver is in upright position was actuallyvery rear. So, all those conditions were not considered. And only a one single testcondition was a tested, and system, system pass the test and it was allowed to use invehicles. So, that was again a failure because the requirements of test were not a properlyidentified. Then again pre-impact braking was not taken into account.So, normally before the accident always brakes will be applied by the a driver, and thatactually reduces the speed of the vehicle. And because of this speed reduction the driverwill be always moving forward and hitting the steering assembly, and that was notactually envisaged in the a test condition. It was always assume that the airbag shoulddeploy only after there is a collision. So, this pre-braking condition actually required theairbags to deploy, well before the accident or the time delay in deploying the airbagneeded to be decider based on this pre-impact braking. That was not considered whendesigning the airbag.Similarly, injured is due to collision with the airbag was not considered. So, when the airbag is deployed and the driver is moving forward because of the impact, there was apossibility for the a driver to get injured because of the airbag. The sufficient elasticity ofthe the airbag over the pressure to be maintained, all those things were not consideredwhen air bag was developed. And another one was the requirements of disposal ofunused or partially used bags were not identified. Though this was not a reason for afailure of airbag, this was also not taken into account and actually the deployment or the
disposal of the system was not taken into account and the requirement for disposal wasalso not considered.So, all these actually shows that when we design a system it is important to look at all theaspects of the system, and then identify the requirements. So, here you can see that thetest conditions, a pre-braking a impact, and then the disposal, all those things were notgiven primary importance and that all those actually led to the failure of airbag system.This shows that the importance of requirement analysis. We will go through one moreexample how do we actually do the requirement analysis and prepare the case.(Refer Slide Time: 07:08)
But in this case, I will leave this case to the as a self-study for you.So, you can actually look at the causes of apollo 13 disaster as an engineering systemdesign failure, and find out the faults in the requirements identification that led to thefailure. Again, you can actually see lot of case studies in the of engineering disasters. Youcan look at this particular case study and then see what actually went wrong in apollo 13,what are the especially from the requirement analysis point of view, there may be eitherfaults also, but look at the requirements analysis identification of requirements, and whatactually went wrong in the failure of apollo 13.So, this is actually you can take it as a self-study, and identify there a faults inrequirement analysis.
(Refer Slide Time: 07:54)
I would like to give you another tutorial, basically you can take this as a tutorial for youreven this course, and try to attempt this problem, and identify all those what are the list atthe here basically, I am looking at a product. Basically, an ATM machine, a leadingfinancial company as decided to develop a multipurpose ATM to deliver cash, acceptcash, pay a bills and print pass book, for the operational phase of this machine. So, it isonly for the operational phase what you need to address in this tutorial. Identify at leastfew operational scenarios and explain them in detail.So, as I told you about how do you identify the operation scenarios in the case studiesand examples, we actually show how to do this. So, for this ATM machine try to identifya few operational scenarios and explain them in detail. So, we know how to describe anoperational scenario. So, explain them in detail. And develop an input output trace for 2scenarios. So, at least for 2 scenarios you can a develop an input output trace. Anddevelop an external system diagram for this or identify all the external systems whichactually interact with the main ATM system, and then prepare an external systemdiagram. And develop a set of originating requirements, and prepare the originatingrequirement document for the operational phase.So, you can identify the originating requirements, and as per the format explained earlieryou can prepare the originating requirement document. So, this is the work you need todo as part of the tutorial. I will be giving you some hints on how to do it, but I suggest
you that you do not go through the next few slides, try to solve this yourself, then youcan check with the slides coming after this, to see whether you are in the you are doing itthe in the right way.(Refer Slide Time: 09:52)
So, to give you some hints the operational concept scenarios. So, you need to identify theoperational concept scenarios. So, here you can identify many scenarios. For example,one is the customer making a deposit. So, a customer is coming to the ATM machine, hewants to deposit some cash.So, what all the different activities, or different procedures you will be following in orderto make the deposits. So, similarly you can identify other scenarios also, can havescenario 2 3 4 5. Or any number of scenarios. So, some examples are 4 scenarios are likeand there is an emergency situation. So, it could be a fire in the ATM room, or therecould be a theft or it can be an electrical short circuit, or whatever it is. So, what willhappen in their emergency situation?So, what are the requirements to be provided in the ATM machine or the external systemwhich actually interact with the ATM machine in order to face this emergency situation?Or there is a fire in the system? Or there is an unauthorized attempt by someone to takecash or to loot the ATM. So, what should be the scenario? What actually the ATMmachine should do or what actually the software or the external systems? Or how do theyreact to a such a situation? So, that also can be another scenario, or the machine as bog
down. So, what should be the how that scenario to be handled to the machines bog downhow to inform the a central server or the service agents or the customer.So, what will happened to the customer if it is in between and it breaks down? Or whatwill happen if there is a breakdown over the system when the cash transaction is goingon? So, all those scenarios can be identified here. Similarly, there is a theft in the or anattempt to a theft and then maintenance scenario. So, the machine is under maintenance.So, what are the system is to shut down? And what are the system it should allow forservice people to access? So, all those scenarios can be a explained in detail and you canactually identify all the requirements for these operation scenarios.And to get the input output requirements you can actually go for an input output trace.(Refer Slide Time: 11:56)
As you can see here, this is a customer scenario one. So, when where you actually thecustomer wants to make some deposits, you can see here there is a customer thiscustomer you can see over here.
(Refer Slide Time: 12:10)
So, this is the customer, this is the ATM, and this is the bank computer or the centralserver. So, what kind of interactions takes place between these entities? You can see thatcustomer is an external system over here. And then ATM is the main system of interestand bank server is again a external system which actually interacts with the ATM.So, we can see here the customer will provide a general identification to the ATM, andthen these in the form of a card an ATM card or it can be a thumb impression or whateverform the ATM you would like to have. And then the ATM will ask for a unique id interms of a password or form of identification and the customer will provide the id, andthen which is satisfied. If there is a database it will verify it with respect to it is database,otherwise there will be another line coming from here to the server, which will actuallyverify the id and then give a feedback. So, in this case it is assume that the ATM itselfhas got the ids or the passwords stored for a particular general id.So, in that case it will ask for the activity what kind of a transaction you would like tohave, and then the customer selects the deposit activity, and then the request for type aaccount type is given by the ATM. Then the account type is provided by the customer,and the amount is asked how much amount you want to deposit, the transaction amountis given by the customer. And then deposit type, and the deposit type is given. As interms of cash or check or a DD whatever the type of deposit and then there is a physicalmeans for insert. So, we can see here that the ATM machine provides a physical means
for insert. So, this kind of a transaction or the input output trace tends you therequirements.When you say there is a physical means of insert; that means, the machine should havethe facility or there is a requirement for a physical opening in the machine to accept thecash or check, and then the customer deposit the funds. And then there should betransaction information to the central server. And that will count the amount or verify thecash. And that will be transaction will be given to the central server. And then the receiptwill be provided by the ATM, and the ATM will go back to it is main menu. And thecustomer can choose to have another transaction, or he can leave the place. So, these arethe activities taking place in one of the scenarios.So, like this we can have all for the input output trace we can have for all most all thescenarios and provide find out the input output requirements.(Refer Slide Time: 14:51)
So, this is another input output requirement for another scenario. They basically here is awithdrawal activity; the customer wants to withdrawal some amount. So, the initialactivities will be the same. So, once you tell the request for a activity the customerchooses the withdrawal activity, and then request for account type then account type isgiven then request for amount transaction amount, and then once you give the amount.
(Refer Slide Time: 15:19)
Then there will be a verification what is the maximum amount the person can withdraw,and that amount will be given back to ATM and then ATM will decide whether to givethe cash or not. And once it is accepted that will be providing the cash.So, the customer is given a cash a given the cash from the ATM. Again, it tells you thatthere will be a provision for the ATM to count the currency and then dispose or give thecurrency to the customer. And the receipt you provided the transaction details are sentback to the central server, and the receipt is provided and then it will go backs to mainmenu. So, these are the different activities taking place in during this particulartransaction. Similarly, all the scenarios we can identify the input and outputrequirements, and this requirements can be placed as the in the pass part of theoriginating requirements.
(Refer Slide Time: 16:13)
So, you originating requirements some of the originating requirements what we canidentify the system shall give an indication of the status. I mean the status of themachine. So, what is where it is in operating condition, where it is in maintenancecondition or it is in a breakdown condition. So, this indication of the status to beprovided to the customer; the system shall prompt for an identification and provideopportunity to provide the identity. So, since the machine has check the identity. So,there should be a prompt for an identification, and provide an opportunity to prove theidentity. So, these are some of the requirements you can identify.So, similarly you can have many requirements. These are just examples of some of therequirements which you can identify using the input output trace.
(Refer Slide Time: 16:55)
So, these actually shows a very top level external system diagram, can you see these areall the external system which will be interacting with the ATM system you can haveATM admin which will be interacting with the ATM system for the maintenance. As wellas a service and other requirements, and the customers from other banks will be comingand there will be different banks customer like then will be a credit card customers. Andthen there will be different networks. Like, there are different international networks likemaster visa and that kind of a networks.So, there will be interacting with the ATM, then there will be a unfriendly customerbasically who are trying to either attempt to take money unauthorized of without anyauthority. Or there will be a some theft and other situations. And there will be bankmanagement interacting with the system for basically to find out the transactions and tosee whether there is enough cash or other things.So, there will be hardware maintenance also which actually will be maintaining a system,and whenever there is a problem there will be attending as along with the serviceproviders. So, these are the different systems interacting with the ATM. So, there are thebasically the external systems. And you can actually go further down to this level, andidentify what kind of interaction takes place. So, we discussed about the external systemdiagram. So, we can prepare the more detailed external system diagram identifying thetype of interaction taking place between these entities.
(Refer Slide Time: 18:25)
So, that was just to tell you how to attempt the problem of the tutorial problem. And thiswill be an assignment for you. You can attempt this leading electronics gadgetmanufacturer has decided to develop a multipurpose gadget to store deliver music storeretrieve data like address phone number etcetera. And provide information on locationnavigation. And for the operational phase of this device identify at least 10 operationalscenarios and explain them in detail. Develop an input output trace for 3 scenarios andidentify input output requirements. Develop the external system diagram for thesedevelop a set of originating requirements, and prepare the ORD for the operational
phase. And prepare an objective hierarchy for the operational phase also.So, what are the basic objectives? And what is the hierarchy of these objectives, also canbe prepared. So, this is a group assignment for you can prepare this and you can send itto me if you want any feedback from this.
(Refer Slide Time: 19:23)
So, to summarize what were discussed in the last few lectures, we started with 6functions of system design process; where we started with the first problem of that is thedefining the system level design problems. So, that was the out of the 6 this is the firstone and we attempted the to go into the details of this phase.So, basically you will discussed about the operational concept, and how do we developthe operational concept, and then how do we identify the external systems. How do welook at the originating requirements, and then the objectives hierarchy, anddocumentation and requirements management? And at the end of this level what we aregetting as an output is the originating requirements document, and we saw how do weactually prepare the ORD, and what is the format for preparing the originatingrequirements document. So, with this we complete the first level of design problem thatis the defining the system level design problem. Before going to the next level that is thefunctional development of the system, I would like to briefly explain to you about someof the softwares available for a system design.So, I will briefly explain these softwares basically it would give you an idea of whatactually the software can do in helping you to design a an engineering system. So, thereare as I mentioned earlier there are multiple software tools for a system engineering, andsome of them are commercially available. Some of them are mean some of them arefully available some of them you need to get some license to use.
(Refer Slide Time: 21:03)
As I mentioned earlier there is one of the software is known as a SysML. It is a general-purpose modeling language for systems engineering application it is a dialect of UML. It
is a trademark the industry standard for modeling software intensive systems.So, this is the basically modeling language, a dialect for industry standard. Basically,used for software intensive a system. they are basically now used in a system engineeringbecause lot of system engineering applications include software and hardwareintegration. So, this is very well used in a system engineering applications. So, itsupports the specification analysis design, verification and validation of a broad range ofsystems and systems of systems. This systems may include hardware softwareinformation processes personnel and facilities. So, we can actually use this a SysMLlanguage for analysis and design or verification and validation of systems; whichactually include hardware software information process personnel and facilities.This is an open source which is publicly available for download, and includes an opensource license for distribution and use. So, if you are interested or if you want todownload it you can actually get it is a free and open source. You can use this one foryour system design applications. And most of the softwares are come with it is own usermanual and explanations on how to use different functions in the software. So, you candownloading the software most likely you will be getting the users manual andexplanation on how to use it.
(Refer Slide Time: 22:40)
Another one is known as core. It is again a software coming from vitech corporation. Iexplained you in one of the classes that IIT Madras has got a arrangement with vitechcorporation. So, we are actually part of their university education program. Andtherefore, we are actually eligible for downloading the software free of cost, especiallythe education version. Only thing you need to have some registration with this company.So, once you register with this company you will be given a password to download, anda most likely you will have to approach me to get the password because they send thepassword to me if you ask for registration. And then you can actually download it andused for your education application. So, in case you want to download the software youcan contact me and we will make a arrangement for you to get the password fordownloading the software. So, this software is known
as core basically looking at thedifferent aspects of system level design problem, and then how this problem can besimplified using the software.
(Refer Slide Time: 23:48)
I will give you a brief explanation about the software, what it can do and what are thecapabilities or what actually makes it interesting to use the software for a system leveldesign problem. As you can see system engineers desktop, there are lot of things in thedesktop of a system engineer. So, he has got the source document from where he willactually extract the requirements, and then based on this requirement it will be findingout the function list, and then the physical components. And for the physical componentsyou need to have a traceability, and the traceability will go back to function and thenfrom the function it will go to the requirements. And similarly, there are different dataitems and there are interface definition when you have physical component we will be lotof interfaces between components.So, you need to define this interfaces that again coming from the function and the dataitems. Similarly, there will be a lot of graphical output coming from the function list interms of different way of modeling the a behavior of the system, and this actually all thisneed to be recorded as printout reports or models or specifications. So, again the notebook engineering note book data what there will be whatever you stable on differentdesign activities or a concept development. So, all these things are need to be finally,printed as a reports. So, as you can see there are lot of interaction between all thesefunctions and any change will affects something else on the system.
So, how do we have a properly ordered and a systematic way of representing all thesething in a using the capabilities of computation and information technology? How do weactually develop this a particular over a an application? Or we can have all these thingsin a very order and systematic way, without much complexity you can make easychanges you can have proper traceability. So, how do we do this is the is a major task fora system engineer?(Refer Slide Time: 25:41)
So, if you look at the a common system engineering tool suite architecture. A normallythere will be a database for the requirements. This will be in terms of it will be a writtenit has a word processors or using spreadsheets.So, all the requirements database will be developed. And there will be a behaviordatabase in terms of the functions and functional interactions and the interfaces. Andthen you will be having physical architecture database, the components subassembliesand how they actually satisfy the functions. And then there will be a verification andvalidation database. So, there will be multiple databases, and using this database therequirements will be managed using the requirement database. And the behavior analysiswill be carried out using the behavior database, and architecture synthesis will be doneusing the physical architecture, and verification done will be using verification database.So, as we can see here different source for these databases will