 So, we have discussed what function of specifications are. Function of specifications usually are given in a very raw form by the end user and they are expanded jointly. After you frame those function of specifications, then you will come out with data models and data dictionary. Now, we have extensively discussed both the ER model. We have loosely discussed rather the data flow model. But as far as the ER model is concerned, as far as the static model is concerned, you practically know everything that you need to know including the data-deficient language users of SQL in order to prescribe what you call the complete schema. You know the constraints, how they are prescribed. You also know how to write queries once you come to the schema. So, up to that portion, you don't write queries as a part of SRS. But you know exactly how the queries will be written. And therefore, you would have a rough idea when you frame queries in English that these queries have to be responded to by the information system that I am creating, then you would know roughly what kind of SQL queries will be ultimately written. Of course, there will be a lot more to the procedures where many of these queries will get embedded into other software components which are like components which will handle the front-end screen, components which will handle the communication between front-end screen and the back-end server, components which will handle multi-user responses, crash recovery features of the database, etc. which we have briefly looked at. What we have not looked at certainly is any details of the user interface requirements. And the user interface requirements actually form a key to the entire system and these, therefore, the requirements must be captured right up front during the SRS. Now, you have a rough idea of what user interface requirements are. I thought I will use this opportunity to elaborate a little more because that will probably be needed to be understood by you in order to frame a proper SRS because there is a full-fledged chapter on user interface requirements. So, let's look at some of these. User interface is a generic term which is used to describe how an end user of a system will interact with the back-end information system that you have. The user will get in touch with that system typically through conventional front-end technologies. The most conventional front-end technology is a PC with a mouse, keyboard. That's what most of you know. There are special devices for user interface. Mobile phone is one of those devices as I had mentioned once. There could also be some peculiar interfaces which could be switches kept unobtrusively somewhere. There could be a user interface comprises of your own smart card which you pull out of your water wallet like, for example, your identity card. Most of you should have an identity card of this type which has a chip somewhere there. We are currently not using it. But consider an information system which is supposed to automatically mark attendance of people or system which is automatically supposed to give you access to a laboratory. So, the locks are governed by your access code and the access information which is stored at the back-end. In such a situation, the user interface will not comprise of a full-fledged PC, screen, etc. But just a card reader on the door where you just show your card or insert your card and the appropriate algorithms are invoked at the back-end. The databases are searched. If you are authorized, the door opens. Otherwise, the door does not open. So, such user interfaces are also not uncommon in modern times. However, conventional business information systems will generally have interfaces which will comprise of interactive screens on a conventional PC. Modern systems typically deploy screens which are presented to you or rendered to you by browsers. The screen that you see here is not rendered by a browser. There is another piece of software which is rendering or showing you this screen. What is that software? It is Microsoft Powerpoint. There could be a variety of tools which will present such contents to you. For example, OpenOffice has a presentation tool which can present it like that. You could have Acrobat Reader. So, if you have PDF files, the PDF document format, then you will use an Acrobat Reader to display those things. So, you can scroll, you can move up, down, you can expand the font size. All these features are available to you. How do you model such screens is an important activity during system analysis. More particularly, apart from how the information is rendered on the screen, which is important, but that's not the most crucial thing in an information system. The most crucial thing in an information system is the ability to capture input that is provided by the end user. So, whether it's a registration form where you enter your roll number or subject course that you are registering for, or whether it's a railway reservation form where you enter a train number, or whether it is a bank clerk who is as an end user of a financial information system, he is trying to do debit credit to your account, or it could be a statistical survey who is collecting data about progress being made in a district by going to the district headquarters and inserting information about the number of sheep in that district, number of camels in that district, for example, in Rajasthan, or the number of water bodies that are there, whatever, whatever. So, for every such interaction which demands input to be captured from the end user, particularly in the form of conventional character strings, numeric values, character strings, et cetera, et cetera, you need to provide for a user interface. So, this single line message capture and validate input will mean a lot actually. What kind of input do you want to capture? How would you like to organize the screens? One might argue that the design of such screens in the final form should be a matter of the design part of the software development, not the analysis part. It's a chicken and egg. Unless you have thought something about what kind of user interface you are going to provide or what kind of user interface the end user wants, there is no way you can come up with a good design which will be acceptable to the end user because you are not constructing a system as per your imagination. You are constructing a system which will satisfy the end user of the system. The satisfaction of the end user can be judged to a large extent by interacting with the end user right of friend during this system requirement specification building phase. So, that is why the user interface definition becomes part of the SRS document itself. By and large, if you have done a good job here, then your final design would almost always be mere translation of those screens, the screen layouts which will be sort of draft pictures so to say will become ultimately when you count the line number, column number, which space, what will happen, etc., etc., exactly. So, you can do that. However, it is necessary to apply your mind to say how many screens will you design in your entire information system, not design, how many screens will be required in your entire information system. Just like we discussed the ER model where we said it is possible to have a single table containing all the data and then we said that will lead to a very stupid design. So, we came up with a design which was based on entity model, association model and as we shall see later when we study the normalization during the design phase, you will end up getting multiple tables which are logically organized as per certain design feature. In exactly the same way, a single screen is meaningless. You can see what would happen if a single screen was designed. For example, I think I gave that example earlier that a single screen was designed by a government application to collect the data from every block headquarter about the information pertaining to that block from the development point of. So, there are something like 300 or questions which had to be answered in terms of giving values. The point was that these 300 or questions related to pieces of information which were not uniformly applicable to all parts of the country. So, I gave the example of number of camels. Now, that makes sense in a district or a block in Rajasthan. It certainly does not make sense in a district or block in Tamil Nadu. Now, if you organize those questions in the order let us say from going north to south, then somebody in Tamil Nadu trying to fill in those numbers will have to keep pressing return, return, return say 150 times. Now, that's not a good user interface in that. So, that's the reason why you would like to organize your screens in a way so as to minimize the number of keystrokes that the end user will have to put in in order to fill up that form. So, that is a design issue, how best you optimize and so on. But during the system analysis, you must identify what data needs to be captured, what would be the validation rules? Where will you get the validation rules from? You will get the validation rules from your ER model analysis that you have done, where you have essentially understood what data is important for representing the business model, the ER model. You will be capturing only that data or some part of it or you will be deriving the internal data from whatever is given and therefore all the constraints that you have put in your ER model will have to be validated there. And you have to write whenever you give an input screen saying this data will be captured. For example, hostile number will be captured in certain field in a screen. Then you have to additionally write there that the hostile validation rules will have to be implemented when this data is being captured. Now, you might either make a reference to the hostile validation rules that have been stated in your ER model or you may rewrite them again. Please understand the implication of rewriting. If you rewrite those rules and tomorrow let's say we construct hostile number 14, then the validation rule will change both in the requirement specification and the validation place. If you have written it at two places, somebody who is maintaining the documentation must remember to modify this number at both the places. So, rather you make a reference to one place and say the same reference is valid. However, in case the number changes to 14, then the maintenance of application software which by then has been constructed and let's say people are using it without to involve that this rule has to be implemented at this validation, at that validation, at that place all the places the necessary software changes will have to be made. These are the responsibilities of information system designers and implementers. So, let's quickly look at the capture and validation of input kind of screens and the query retrieval kind of screens. There is an additional thing which I am implying in the query retrieval. We might in fact want to write it. That is the menu options screen. Typically an information system when it comes first, it will say it will ask you what you want to do. It is unlikely that it will directly take you to some data entry screen. It will say you want to let's take regular reservations. So, do you want to just see the timetable? Do you want to see which stands prior between two stations? Or do you want to actually reserve a ticket? Because when you want to reserve a ticket, by that time you know exactly which is the train that you have in mind on which date, which class. And you have verified earlier whether indeed that train runs with that class accommodation on that day or not for which there might be other option. The option to an end user within the railway department could be different. He might be wanting for example to prepare a chart which has to be pasted on each bogey of a train saying in this bogey following people will travel on this date from say Mumbai to Amritsar, whatever. So the requirements would be different. Accordingly the menu options will have to be designed differently for different people. And even there would not be a single menu typically for a large system. There could be multiple menu options. Usually the way information systems are engineered is the moment you log in, because there will be security to any information. The moment you log in, the options which are most relevant to you will appear automatically. So if a clerk logs in from the railway department, the options that clerk will see will be different. If an end user like you and I log in, the options that you will see will be different. At what point would these options get decided? They will get designed during the design phase. But primarily they get decided during the system requirement identity. And that is the importance of identifying the user interface. So let us look at, let us take a design of, with which you are already familiar, a design exists for the academic system. You are all familiar with that. You can log in using your LDAP login ID onto the institute system, right? The ASC system. What is the screen that you see generally on that system? Yes, nobody remembers? After logging. Yeah, after logging. Course registration adjustment. Course registration adjustment. Is that the only thing option that you get? Yes. You will find that that screen is not presented to you as option 1, 2, 3, 4, 5. These are just things which are listed there. And there is actually a, what you call a, HTML, a hyperlink. In that sentence, there's something a hyperlink which you can see in blue typically. You click on that link and you go to that choice. That's modern way of giving out menu. The earlier way of giving out menu was it will say some such and such system. They say hostile management system or something like that. So hostile management system. And here after you log in, you will typically get choice 1, 2, 3, whatever. And here you will have to choose one of these things and press enter. So this choice will say you want to know all the inmates of the hostel. So search for students in the hostel. Second one will say, give me the mess bills of last 5 months. The third one might say, get me the canteen bill, whatever, whatever. In fact, if there are multiple things that the information system does for you, the menu choices will say number 1 choice will be about inmates. Number 2 choice will be about accounts. Number 3 choice will be about whatever, political organization within the hostel, etc. Some such thing. So you categorize the multiple menu options based on the units of activities that you do and you give this as the first menu. If you press 2 for example and press return here, you will be taken to another menu. So this may be accounts menu. So it will say, hostel management system and within that it will say account subsystem. And within the account subsystem again you may have 1, 2, 3, 4 choices or whatever. One of the choices may be for the mess coordinator who is supposed to feed in the extra amount that is to be charged to every individual in men. So now when he presses that choice you might want to present him with a screen which will show all the 350 or hot students who are staying there and then against each one that fellow can say 2 breakfast additional or 1 lunch additional whatever. How you decide to design that is a matter of great application of mind so as to minimize the number of key strokes that the mess coordinator or mess secretary or the hall manager or somebody will have to enter. But that's a matter of design. Initially at the SRS stage you have to identify that I will require such a screen. So these are examples of menu screens. There would be an example suppose as I said you press 2 here and you will be guided to a data entry screen. Let's say this data entry screen permits you to enter for each individual student the additional mess charges that are to be paid by that student in which case what you will have will be something like a roll number here. You would expect that the moment you enter the roll number the name of the student the room number etc. should come automatically. How will this come automatically? That is requirement. The function requirement is that the moment in this screen I enter the roll number the database should be looked at the name should be picked up room number should be picked up and should be displayed here. Then I will say whatever I might have something like extra amount to be paid this month and this is where I will enter data. After I enter data I will expect that this data entry is captured, validated and is inserted into an appropriate table in my database. So subsequently when I try to generate a report factual mess bill from this table the extra amount will be taken from some basic bill calculation some basic amount will be taken and for each student in the hostel the total amount will be displayed. So you can see basically things are not very difficult but things have to be thought of very carefully. Would you really like to put extra amount directly or in the context of hostel would you like to put that in this month the fellow had two extra breakfast one extra dinner, three guests whatever you want. In whichever way the raw data is available at that point in time is the best way in which you should ask for capture. If you ask the end user to do any calculation and then enter the final results then the end user will definitely ask you this question why the hell do I have a computerized system if you want me to multiply the number of breakfasts by this bill or whatever one. So as far as possible you must capture raw data which is routinely available in the conventional system. Not a raw data which you think is important but which does not exist. Needless to add such a hostel management system application would be written only once in the institute but it may have to be parameterized if it has to be implemented in each of the hostels. For example if I am from hostel number 3 I would like hostel 3 to appear on my top screen itself but if I am hostel 4 and I am running the same application I would like hostel 4 to appear. Similarly I would like inmates of hostel 4 to appear in my detail work. Now I could either design a single system which is running from a single server for all hostels and at the login time depending upon which general security or mess security is logging in I will figure out this mess security in hostel A and I will automatically present the screen of hostel A. At what point do you make these decisions? Not necessarily at the design stage but at the very conceptualization stage and that is the reason why the SRS document will not be merely pictures of screens that you will paint saying this is the screen this is the screen you are required to give logical arguments as to why you want a screen to look in a particular way and not in any other way and the implications there are that if the screen has to look like this and if there is going to be a single system then at that point itself you will say that the moment somebody logs in the hostel number should be picked up from the database and shown here the name of the person should be shown here whatever one so you see analysis of design for the purposes of engineering approach we separate them out as two phases but when you are doing analysis you are actually doing part of the design thinking and when you are doing design you might refer back saying in this analysis I goofed up I did not think of everything and therefore I need to do something more is that clear? so this is about interactive screens what about query retrieval what kind of screen would you like to make one simple way of saying is you give a long string to be written and say please type the necessary sql query that will be stupid right only information scientists can write sql queries end users they may be able to but they cannot be expected they are the end users so nobody will write an sql query so what is it that you have to do during analysis during design and during coding can you imagine for a query retrieval system you said what kind of queries can you use so what kind of queries can you use consider the academic system now this is where you have to first classify the users in different groups for any application system such as academic office system with which you are familiar you can easily see three kinds of users one are the two end users for an academic system in IIT Bombay that end users comprise of students and teachers and TAs these are end users then there are academic office functionaries so academic office clerk who is supposed to update grades academic office clerk who is supposed to fire a program which will calculate CPI academic office clerk who will follow up whether the fees has been paid in time academic office clerk who will do something that a student was not able to change courses during the date prescribed but subsequently the student has gone to dean academic programs and got an approval saying because of these special circumstances I am now permitted to change my course registration such thing will not come to the faculty advisor such thing will normally not be permitted by the end user directly so you will have let's say the activators of academic activities within the academic office will comprise one group and finally there are managers who are the managers heads of the departments who would like to know the academic performance of students within the department dean of academic programs the director of the institute a board member these are typically called management users for whom you need to produce reports comprising of management information system reports a transactional system handles transactions any reporting that is generated out of that transactional system for the purposes of gross understanding of the happenings are called MIS reports the management information system reports the requirement for them must be captured during these phases so what kind of questions would a faculty would like to ask what kind of questions a head of the department would like to ask what kind of questions the dean of academic programs would like to ask what kind of questions the UGAP convener or PGAP convener would like to ask a PGAP convener while he has he or she has to approve all the results after every semester the PGAP convener also has to look out for exceptional cases somebody who has a very poor academic performance somebody who has an exceptional academic performance how is the average CPI moving in the course of years these are the kind of questions that the convener would like to ask similar questions the dean might like to ask there was a query which was a very unique query at that time we were trying to find out so we were worried about the what you call the quota system not QUOTA but KOTA large number of people from quota were getting admission through joint entrance exam and we were worried whether there is any gap there so what we decided of course to institutionalize a more rigorous sort of invigilation we are not in charge of invigilation at centers the center in charge is not there but to send more number of people and simultaneously we undertook a very interesting exercise to correlate the JEE rank of people who come from quota or Bhilai to the academic performance and academic rank within the institute after the joint because after the joint there is no coaching you have to survive like that so that was not planned for in the information system because I mean how do you plan for that so we had to get that data separately and we had to write queries separately we surprisingly found a good correlation that means the people who had better ranks coming from that it did not matter which place they came from actually that's what we could show independent of whichever place they came there was a good correlation in the JEE rank that they had and the performance there were of course outliers in any statistic now such questions cannot be anticipated so you will always have provision to write additional queries and that may be the reason why sometimes you may change the database design to include additional tables subsequently but these are exceptions in normal routine way you should be able to anticipate all these things in exactly a similar fashion you have to model reports reports could be of two types one is when you make a query online and as I said the query cannot be in terms of SQL just as you make a query screen how would you make a query screen even for a simple thing like you want to find out some details about a student let's say you want to find out what is the CPI of that student then the query screen that you will design will merely say enter the role number of a student now that role number should automatically disappear the name should have a radio button or something say confirm the query that indeed this is what you want to ask and then internally an SQL query should be formed which will say save X CPI from student where role number is whatever you are given so all that will be done by the software the database will be inquired into value will come out and again some pieces of software will bring that value to the front end these are the pieces of software which actually programmers will have to write in your case the system will be implemented by the secondary BTEC students who will actually write the code for doing everything that you prescribe ultimately is the system which will run but you have to design how should that information appear should just say CPI of this student is so and so that's a very simple screen to design so query answer is also a report sometimes the query will send larger number of values for example the query could be that given a prescribed CPI get me the list of all the students names of all the students in the hostel who have CPI more than that I might even want to ask questions related to which wing has superior academic performance more importantly from a hostel management information management system I want to casual together a basketball team and I would like to know all the students residing in my hostel who have given basketball as one of their hobbies in all such queries I will not get one name I will get maybe 20 names maybe I will get 50 names how exactly do you want that final output screen to look like has to be thought of during the requirement specification so would you like a 25 list to be packaged in a fashion in a two column one column here one column here where the font is so small that nobody can read it or would you like the names to come up like this such that there is a scroll bar where the end user presses the scroll bar and the list scrolls up or this scrolls down so you can easily look at it on our interactive screen including the screens which are displayed by browsers you have the scrolling facility but if you need a printed report that printed report has to come on a piece of paper what should be the size of paper what should be the size of font in which way that information should be organized now this is a requirement specification you can just say in your SIS document that a report comprising of all the passengers travelling by each state for each bogey will be produced that's not that's not specifically in the report how will that report look like so it will have a bogey number it will have a trade number it will have class of accommodation it will show it separately it will show from which station to which station which travelling etc etc ok you will notice that the age of the passenger is not written in such a print out do you know why simple the age is taken as a corroboration that the right passenger is travelling so the age is not displayed otherwise any person with that age we claim that my name is so and so that's why there is some information which is cross checked by the TC so if you buy a ticket on internet for example you are required to give the document type for your identification suppose I say driving license and I give driving license number that is not displayed in the report but that is something that is available with the train conductor so the train conductor has a similar list what is posted but it has some other information now who will think of these things these things cannot be thought of at the design stage they have to be thought of at the stage when you are collecting the requirement and that's the reason why it is extremely important to look at the system from individual users perspective so even in the hostel the perspective of an individual hostel internet is different the perspective of the hall manager could be different the perspective of warden could be different and you have to put yourself into everybody's shoe to say that from this hostel information system what is it that the end user will require but hostels in IIT Bombay you yourselves might be better players to raise some of these questions but in general can we say will you know for example what kind of system is required by securities and exchange board for surveillance of the trains that happen in the stock exchange no who will know these things the people who sit in savvy the people who do the stock market trading that is brokers people and so on the people who run stock exchanges so you have to go to them and ask questions to find out what exactly they are doing why they are doing what they are doing and what kind of information system interface will they require that's the reason why invariably in this important phase you have to interact with the end users you have to learn as much about the end user as you can as much about the end users domain as much about the end users application or the information system as you can this is a very serious task that is the information scientists are not people who just move with a bunch of technology and implicitly just use that technology for whatever they are required constantly to learn about a different domain every time they design or analyze a system every time they build a system one year or one and half years later you will be required to build another system if you are working for example for data consultancy services it is not uncommon that you will end up in a span of 10 years working on 5 to 6 completely different systems and when you do that imagine the amount of competence that you will develop in the knowledge of each functionality of the 5 or 6 system this knowledge is expected to be reflected in the software requirements, specification document that you make subsequently the design document that you make and subsequently the information system that you construct there are actually books world style system analysis books which in fact tell you how to conduct interviews so let's say you are working on a stock exchange system you don't know anything about stock exchange first you will be required to read about what are the normal operations of a stock exchange then after familiarizing that you will formulate a set of questions from a information system perspective that you would like to ask the executive director of stock exchange the individuals who manage the systems there what kind of information requirements are there and so on and for that what kind of interviews you should conduct for example suppose I am the end user of one of the applications that we at an appointed time and suddenly start asking questions your first question will be sir tell us what do you want I am not an information scientist I do not know from what angle you are asking me these questions what is the purpose of these questions I will generally describe in a philosophical manner what I want that is not adequate for you you will go back and you will be less wise than what you were before so you have to prepare a background paper before you conduct an interview then you have to send that paper to the end user saying I want to meet with you but I want answers to these questions so the end user is ready with the answers if the end user does not understand some questions that end user can send back an email or a document to you saying I do not understand what these are this means then you are required to elaborate please remember that the interview time is a very short time of 15 minutes half an hour whatever and during that half an hour you want to achieve a lot of useful information exchange the preparation for half an hour interview could easily take about one one and a half hour on your part and could easily take at least half an hour of pre preparation by the end user whom you are interviewed these are no trivial matters these are typically stated in large system analysis processes and procedures but for you to understand this you have to practice this thing how do you practice this in a class setting how do you practice this I am sure you would have asked some questions to Samir sir whenever you are designing completely new information systems which did not exist at all then there is a lot that evolves while you do not only analysis but design and even building so when you build a system people will come up with additional requirements and as I said earlier this is common for but when you have existing information system which are to be migrated with additional functionality then the end user is also able to answer you questions in a better fashion the important question to us is how do we simulate that environment here I have tried to do that in two ways one is to expose you to Samir sir, so good then one hand and Prasakriti Ramayana on the other so that you can have at least that first interaction but beyond that you will have to create group interviews within yourself and practice this so for example there is a group of four people right now you can within your own group you can say alright you will act as a user and I will act as a information system analyst and I will interview on these facets so you actually time it you say 10 minutes interview but before that whatever is the preparation questions then that person thinks about those questions and if that person can answer those questions I can answer all of them or I don't understand this question now this is an exercise in information system analysis this is not an exercise in SQL programming but this exercise is as important as SQL programming because if this exercise is not done some questions will remain unanswered some questions will not occur to anybody but they will have an uncanny propensity of surfacing later after you have built that system that is why this has to be done report modeling as I mentioned contents and format is an important aspect more importantly whether the reports are to be produced on screen or whether the reports are to be produced on printer you would see that each one of you gets a great report at the end of an examination I don't know how the great report is printed now it's a smaller is it a pre-printed stationery or it's an ordinary paper on which great report is printed so there is something which is already printed now you can see the possible problems the already printed things means that there are exact spaces wherein the variable information must come your old number your name course grade etc must come and sit there if it is printed 1.5 inch on this side the whole report will look like rubbish so which means that the person who writes programs to generate that report on the printer must know exactly which line number which column number what information has to come and the printer itself must be aligned properly with the printing stationery before you start printing nowadays things are much simpler with let's say A4 size papers getting printed through laser printers will actually have pre-printed stationery and still make sure that exactly at that place the printing occurs it is not necessary many times to have any pre-printed stationery because a laser printer is a page printer and it can print the entire page in the same time that it takes to print even smaller pieces of value but in large dot matrix printers or line printers such is not the case the amount of information to be printed decides the throughput of the printer imagine for example refund cheques that have to be printed and sent take the IPO that happened recently of Arayal unfortunately that stock is trading much below power but whatever some 50 lakh people are supposed to have applied nobody got the number of shares that he or she applied for that means there is a refund amount that is to be paid back as per maybe whose this refund amount has to be paid back in 10 or 15 days time imagine printing 50 lakh cheques correctly then putting them in some kind of an envelope folder putting a postage stamp and mailing them please remember each one of these is an activity of an information system have you ever wondered how long it will take to put 50 lakh cheques in envelopes close them test a poster stamp assume that the address is automatically written and put them in the post can you put 50 lakh things in any post box you can't how do you handle that so you take so many things almost all these paper have to be said under some kind of a proof so which means the poster authorities must sign saying so many envelopes these are physical envelopes that have to be carried to the post office they have to be received by a post office clerk and that post office clerk has to give you a receipt for each of the envelopes he can't give a receipt for each of the envelopes so he will generally expect you to carry a large list on which he will put a stamp saying received 500 or 100 but each of these 100 or 500 have to be physically countered by the post office clerk and all against the list that indeed that name is what you have been given how long it will take to do this with 50 lakh envelopes do that as an arithmetic exercise you will find out that these are non-trivial issues and it costs money you need to have people who will send we sent just 12000 envelopes containing CDs to our alumna you can find out what kind of miserable logistics arrangement it required in the alumna office you have to put a CD inside of each envelope then you have to find that we have a franking machine but we still have to go to the post office and a post office said we will not be able to accept more than 500 in a day so we found out 10 different post offices sent 10 different people with 500 each and they were doing that every day now this is very clearly this is a matter which requires money to be spent and your job as information scientist is to try and think of ways in which you minimize these things one of the reasons why email has become so popular across the world is because they cause time and effort involved is much less in taking the contents from one place and delivering them at the desired but in real world you still need paper and that is why when I say on printer what is the size of the page on which you want to print this how will this report be printed how will this report be handled after printing these are the questions that have to be raised during system analysis is that clear we will not go through these special interfaces but I did mention two things one is if you want to for example have an information system which will interact with the end user using SMS so as I gave example when I am travelling by Singapore Airlines I will automatically get an SMS reminding me that the flight leaves at this time from such and such terminal in this way if the flight is delayed I will get an SMS now this must be automatically generated you cannot expect a person sitting there every time the flight is delayed by 15 minutes typing in messages to 350 travelers of that flight but that is the part of the information system design and implementation but to perceive such a need is the job of an information scientist at the time of system requirements you can see that this part of user interface will occupy sufficient effort from your side during the SRS specification itself and the better you do this part here the less will be the problem during design implementation and usage screen and forms layout is what generally you will include in the SRS how will the screen look like how will the forms look like data entity forms but what you will also include in the SRS is which are the source and target stores they could be either entities or associations in your ER model or they could be stores which have been introduced in your data flow diagram model you remember the data flow diagram where you have this notion of a store now a store can be introduced which holds the information in a transient fashion input information comes like this it goes into a store after 2 or 3 processes that information is consumed and put in your regular database table so it is not necessary that all the tables that you have described in your ER model are sufficient to capture all the stores requirement there will be some stores which will be required during the SRS phase itself which you will identify ultimately they will also have to be translated into some kind of table definitions then operational considerations ease of use what we call user friendliness one of the aspects is keystroke minimization minimum number of keystrokes required if it is pure play keystroke and no mouse then the number of down arrows that you have to hit to go from the top of the screen to say seventh field six are useless that is also to be counted in general it is not an easy task and you have really really a good opportunity to apply innovative ideas in this design the people I have found who are very good at this are people for example our industrial design center people who who work for the master of design they understand the user interfaces much better we actually have a professor there Professor Anil D. Joshi who had given a talk in this course on user interfaces basically usability analysis I will try and put those slides on the moodle screen you might want to look at them as to how user interfaces are I mean they go to the extent of saying that if there is a product a product like for example scissors so if you are given a scissor you automatically know the scissor to cut paper or thing you don't need to read a user manual but suppose somebody designs are extremely complicated in a beautiful scissor which cuts in a very fine way except that it does not have two hands it has five buttons now can you use that scissor without reading the manual and even if you read the manual the danger is always that you press a wrong button and you cut your thumb instead of a paper so this usability is an extremely important facet of any information system whether it is an information system or a gadget consequently there are a series of manuals that have to be written user manual how many user manuals have you read about any information system if you take software as an information system or if you take any hardware as an information system then you would have come across manuals a TV user manual or a PC installation manual software installation manual notice that the quality of that user manual is decided by the end user depending upon the ease with which the ultimate objective is satisfied by following the steps given in that user manual at what point do you write the user manual in a classical approach to information system you write the user manual at the time of design however much of the user workflow will have to be captured during the analysis phase so you have to write a good design document so you can see the kind of things that you will have to write under operational considerations you will have to write some modes on how the workflow happens how information moves from one place to another place this identity of different groups of users has to be done the identification has to be done during the SRS facet I would conclude here by saying that the user interface part is an important part of the SRS document and therefore writing a good SRS document refining it and making sure that it captures everything that is of consequence