Today we will discuss about the originating requirements anddocumentation for system development.(Refer Slide Time: 00:32)
In the previous lecture we discussed about the requirements classification, thenrequirements partition, and then the requirements management; as we saw about theconfiguration item requirements, component requirements system requirements and thenoriginating requirements and mission requirements, how do we actually classify and howdo we partition them into different categories.And today what we are going to do is to see how do we actually do a requirement anddocumentation which is known as originating requirements documentation. So, we willgo through this process the steps involved in according the requirements.
(Refer Slide Time: 01:03)
So, the basic idea is that the requirement should be written in a very clear unambiguousmanner that is the requirements are going to be there throughout the process of designthroughout the lifecycle of the project or the system and there will be many people usingthis requirements at various stages and under various circumstances. Everyone shouldunderstand the requirement in the same way as intended by the person who actuallywrote the requirements.So, it should be very clear it should be unambiguous and there is not be any confusionabout what is written or it cannot be interpret in a different way. The importance of thisactually we can see in our day to day life also whenever we communicate with thepeople we may tell something and the other person may understand it in differently. Forexample, you will see the dialog between Mrs. Chopra and Gita why did you pop. So,much corn only need 6 cups Gita says I popped only 6 cups.I mean 6 cups of popped corn not 6 the cups popping of 6 cups said Misses Chopra thenyou should have said. So, that means, if you want something you should tell it properly ifyou give a chance for someone to interpret it in a different way then things will go in adifferent way and then both will have miscommunication. And, that is very important inthis case of requirement analysis requirement writing also. So, we should try to tell whatactually we want and we should write down in a very clear unambiguous way what is therequirement that particular requirements is another example here.
(Refer Slide Time: 02:42)
"You should say what do you mean" the March hare went on “I do,” Alice hastilyreplied; “at least I mean what I say that is the same thing, you know.” So, say what youmean and I mean what I say that the same that is what the argument here is, but these thattrue look at here “Not the same thing a bit” said the Mad Hatter. “Why you might just aswell say that I eat what I see is the same thing as I eat what I see. So, you can see thedifference it is not the same as what you say I see what I eat and I eat what I see aretotally different.So, we should make sure that whenever we communicate whatever we record should beproperly recorded and properly written. So, that everyone understand it in the same waywhat we intended.
(Refer Slide Time: 03:29)
The characteristics of sound requirement so whenever we write the requirement weshould make sure that they are really the proper requirement and we are writing it in aproper way.So, I know to ensure that the requirement should be unambiguous as I mentioned itshould be understandable to everyone. So, it should not be put in a very high technicalway or within the very complex sentences, should make it very simple andunderstandable to everyone it should be very concise not be very long sentence with a lotof explanation, should be very concise statement it, should be traceable traceability isbasically you should be able to go back to that requirement and find out where thisrequirement, but will a requirement came from and what was the origin of thatrequirement. So, that there is any issue at the later stage we can go back and then correctthat requirement based on that origin of that requirement. So, that is why it should betraceable and it should be design independent.So, we should not specifically say that this requirement is for this particular design. So,you should never say that there should be clear transmission between particular between2 components, because that is becomes a design dependent. So, that requirement shouldnot be written in the way which is depending on a particular design. So, it should bealways mentioned in a design independent way and it should be verifiable. So, youshould be able to verify this requirement in later stage whatever we write down as a
requirement should be a verifiable one. Otherwise there is no point in writing it becausewe would not be able to verify whether you are really achieving that particularrequirement or not similarly it should be unique to that particular project. So, it shouldnot be put in a very common way or should be very specific to this particular system.It should be complete. So, the that is not be a partial statement should be a completesentence or a complete statement of requirement, should be consistent with the otherrequirements also there may be many requirements in the system. So, it should beconsistent with other requirements should not be a contradictory to other requirements inthe overall requirement of the system it should be modifiable. So, at any time you shouldbe able to modify that requirement depending on the situation, as a situation arises youmay find that this requirement is not the one which actually you want then you should bein a position to modify this requirement similarly it should be attainable.So, you should be able to attain that requirement or you should be able to meet thatrequirement through some means. So, you should not write down something which isimpossible to achieve. So, the feasibility of the requirement comes into picture. So, I willface ensure that it is attainable. So, these are the good characteristics of writing arequirement.So, every requirement should actually try to follow all these characteristics. So, thateveryone can understand it nobody will interpret it in a different way and these arepossible and feasible requirement for the system.
(Refer Slide Time: 06:09)
So, once you have these basic characteristics you should see how do we write thedocument. So, this is the document for the system development is known as originatingrequirements document or in short ORD. So, this is the document where actually wewrite down or we record all these requirements and ensure that these are feasible andthey are understandable to everyone. So, the requirements and design options interactacross lifecycle phases. So, this is important because across the life cycle theserequirements interact.So, that is why we need to make sure that our ORD takes of the different life cycles ofthe system requirements in one phase of the lifecycle will often have a major impact onthe design of a system in another phase. So, as I mentioned we in the system we willlook at the life cycle of the system. So, there will be an interaction of this requirementover life cycles of the system and there will be lot of impact on another life cycle.So, the design phase requirements will be having a major impact on the manufacturingphase similarly the manufacturing phase requirement may impact the operational phasetherefore, we need to make sure that this requirement what we identify are consistent andthen actually their impact on other life cycles are minimal as much as possible and thedocumentation of requirements within each life cycle is important.So, the requirements need to be recorded for each life cycle separately. So, as Imentioned the requirements are different for each life cycle and therefore, we need to
record these requirements for each life cycle separately the question is now how do weactually write down a good requirement?(Refer Slide Time: 07:40)
Let us see how do we do that. So, one important point here is that you should use wordswith judiciously do not use the words without thinking without understanding theimportance of each word we use. So, we should use shall to indicate the limiting natureof a requirement. So, if you have a limiting nature of a requirement where we can havesome kind of a trade off or a compromise and we should use the word shall.Will represent the statements of fact so if you have some statements of fact which isalready existing and you do not have any control over then you say it as a is a will andshould will be used in statements of goals. So, if you have some particular goals to beachieved. So, you should always say you should use the word should this is basically ifyou have some particular safety requirements or the response that requirements then weshould say the system should response to an emergency in 5 seconds or that the systemshould accelerate within 2 seconds. So, that type of a statement of goal should bespecified using should. Then again do not use and / or so this again a confusingstatement, do not use the and / or so use and or in case of I mean wherever the it isneeded do not put this option for a reader to interpret in a different way.And never start with if so do not start any requirements within if, because if again weconfusing to a reader at the later stage or a person who is going through the requirement.
So, he can interpret it in a different way so never use a if. Similarly nonspecific verbslike maximize, minimize, or adjectives like easy, flexible, robust, adequate, sufficientetcetera should be avoided.Because these are all very subjective maximize minimize. So, when you say maximize.So, nobody will know what is actually maximum we want and then again the again it issubjective and depends on the situation, similarly minimize or adjectives like easyflexible robust these are all not very objective. So, we should avoid these kinds ofnonspecific verbs and make sure that whatever we specify it a very objective and it isvery clearly understandable to any person who is going through these requirements.(Refer Slide Time: 09:57)
We will see some examples so whenever we write this requirement we start with thesystem of interest suppose if it is an elevator system or it is a mobile phone or it is amobile network or a television system, we should start the requirement with the systemof interest be followed by a verb phrase starting with the word shall or will or shoulddepending on the situation and be followed by an object that describes an input outputand end with conditions under which the previous was true. So, this is the way goodrequirements need to be written.So, we start with the system of interest followed by a verb phrase starting it the wordshall or will or should depending on the situation and then follow by an object that
describes the input or output what our requirement is and end with conditions underwhich it is true.So, this is the way you write a requirement for example, you can see here I am writingthat the development system shall receive inputs from stakeholders. So, if you have asystem we are talking about a system where the development phase is being discussedand we should say this development system shall receive inputs from stakeholders. So,that is a requirement statement. So, the system should be able to receive the input fromstakeholders.So, whatever the inputs are there the system should be capable of accepting these inputsand that is the one requirement. Similarly the manufacturing system shall have ascrappage rate of x percentage or whatever the percentage 1. So, do not say that that ascrappage rate minimum scrappage rate. So, that is not acceptable you should write whatis the amount that is acceptable or what is the quantity that is acceptable themanufacturing system shall have a scrappage rate of x percentage.So, you have clearly telling that that is the acceptable range and if it is beyond that whichis not acceptable, the retirement system shall cause less than particular value x dollar or xrupees whatever it is. So, the retirement system the system the cost of retirement or costof disposing of the system should be is less than a particular value. So, it is very clearthat there is no confusion over here you have to clearly telling that the cost of retirementshould be less than particular value.Similarly the system stop the flow of liquid hydrogen in 0.5 seconds or less again we aretelling that 0.5 seconds is the limiting or it can go less than that, but not more than thatvery really clearly telling that the system, should stop the flow of liquid hydrogen insome cases you have a system for control of the liquid hydrogen then we are telling thatthis control system should stop the flow of liquid hydrogen in 0.5 seconds or less.So, you can clearly see here and not using any words like maximize or minimize or otheradverbs we are actually we are making some statements were actually it is not reallyobjective. So, we do not give any a subjective evaluations or subjective values over here.It will be clearly mentioned what is the actual requirement or what is the actualexpectation from the system. So, this is the way how we write the requirement for thesystem.
(Refer Slide Time: 12:54)
And again these originating requirements we can write down the classification as Imentioned that there are input output requirements and technology system widerequirements. So, these are all actually written in the same way of fashion or as we Imentioned in the previous slide. So, the input output requirements basically they consistsof the input and output that is what is the input coming into the system and what isoutput going from the system. So, for the case of elevator you can say the system shallgive an indication of the status of the elevator.So, the system should have a facility to give a output indication of the status whether it isin working condition or work in which for the elevator is at present the system should becapable of giving that output. So, that is the input output requirement one of the outputrequirements identified the system shall accept requests from all the floors. So, again thisis an input requirement the elevator system shall will accept requests from all the floors.So, all the floor should be I mean there should be a facility for the elevator to acceptrequests from all the floors that again a input requirement then the system shall give afeedback to the user about the request.So, whenever user gives an input to the system and the system should be able to give anoutput it is actually will state; what is the status of that particular request. So, the systemshall give a feedback to the user about the request the system shall prompt the user toselect the option, again the system shall use the shall prompt the user to select the option
suppose there are many options and then the system should give a option or prompt theuser to select the particular option for that particular situation the system shall verify theidentity. So, if there is a requirement then the system shall be should be able to identifythe, verify the, identity of the person or the identity of that particular requirement or theparticular option given by the user.So, these are the typical input output requirement for a system. So, we will try to identifyin the previous lectures we discussed about the input output trace scenario trace scenariodescription and all. So, these scenarios will give us the requirements or we identify therequirement from this scenario and based on these scenarios we will try to write downthese requirements as shown here. So, these are some examples of how do we write agood requirements.(Refer Slide Time: 15:17)
Similarly, for system wide or technology requirements in this case we will write theelevator system shall comply with the disabled people act. So, that is a technology or asystem wide requirement it is not coming from the input output trace. This is comingfrom the technology or the system wide requirement or the context in which the systemis being used. So, the system shall comply with the disabled people act, but the systemsoftware shall be written in C++ or some other languages whatever the languageswhatever the software or operating system want to use.
So, that can be specified in the requirement this may be having some impact on the otherlife cycle. So, that is why it is written the specifically given that the requirement or thesystem software should be written in a particular language. Similarly the systemcommunication shall be through wireless or wired or satisfying particular norm. So, ifyou have there are communications between the system and it is external system.So, we can write down the requirement of communication what kind of protocol to beused or what kind of method to be used for communication whether it is a widecommunication or a wireless communication and what is the standards what are thestandards being used for communication, these things can be mentioned as arequirement. Similarly the operating cost of the system shall be a rupees dash per annumand whatever the amount. So, you will write that also the operating cost should be madeless than a particular value.So, that is a requirement of course, the depending on the further design and furtherdevelopment this may change that is why there is a it is not a compelling statement, but itis target what actually the designers are hoping to achieve. So, the operating cost of thesystem shall be a rupees x per annum. So, these are the system technology requirementsfor this particular case.(Refer Slide Time: 17:03)
And this is how we write in ORD the standard structure of an ORD is shown here as youcan see every originating requirement document it actually a as I mentioned this is a lifecycle.(Refer Slide Time: 07:15)
So, every life cycle will be having it is own requirements. So, the originatingrequirement document will actually record all these requirement throughout the life cycleof the system. So, the ORD start with a introduction or system overview. So, what thesystem is what actually it is meant for what are the basic concepts or operational conceptthe designers are planning to use and that actually we will tell you the give the a systemoverview of the system. So, anyone who is going through this require this document.Will you understand what the system is for and what are the what is the basic operatingconcept designers are planning to implement that is the system overview and then I willgive the applicable documents what are the different documents applicable to thisparticular requirement there may be many standards there may be this disability act orthe building standards or safety norms there are international standards and the nationalstandards. So, those documents which are applicable to this particular design will bementioned in the applicable document section and then we will start writing down therequirements.So, as I mentioned the requirements are written for different phases. So, we start with thedevelopment phase requirements. So, that a development phase requirement itself can be
classified into Input Output requirement, System-wide technology requirement, Trade-offrequirements, and Qualification requirements, these are the 4 categories of requirementsfor development phase.(Refer Slide Time: 18:47)
So, under the section requirements we start with the development phase requirementsand then we go for the manufacturing phase requirement and deployment
phase trainingphase and all the other lifecycle identified for this particular system it write down therequirement, again for the manufacturing phase also you try to find out what is the inputoutput requirement, what is the system wide and technology requirement, trade offrequirements and qualification requirements.So, these 4 will be therefore all the other lifecycles also. So, we will start with thedevelopment phase requirement and then manufacturing phase again we will write down3.2.1 as input output requirement 3.2.2 to a system wide and technology requirement,then 3.2.3 as trade off requirements and then depending on those requirement there maybe subclasses or subdivisions again we will give the numbering as per the requirementsidentified over here. So, this is the general structure of a ORD.
(Refer Slide Time: 19:36)
So, as you can see that there are different phases the training phase operational phase,system improvement phase, retirement phase, and then an overall trade off requirementsalso then overall trade-off requirement will be the identified by the designers.(Refer Slide Time: 19:46)
So, depending on the course depending on the performance or they are identify overalltrade off requirement which may be applicable to all the life cycles. So, this is thestructure and again we will be having other appendix a operational concepts by phase.So, different operational concepts by phase it is develop during the development phase
and then the external system diagram by phase or if different phases there will bedifferent external system diagram because the interaction may be different. So, therefore,you will identify the external system diagram also and put it the all these are under theappendixes.So, this is the general structure of an originating requirements document. So, the firstpart of the design which is basically the development phase or identifying the problemand system level design problem and did this the final output is a operate originatingrequirements document. As I mentioned in the previous lectures we start with thestakeholders inputs, then we go through different stages; like concept development, inputoutput trace operation scenarios, trade-off requirements and go through the requirementanalysis then requirement management and requirement documentation. And at the endof this phase will be getting the originating requirements document as the output of thisparticular phase of development. So, system level design problem will be getting ORD asthe output of this particular phase.(Refer Slide Time: 21:18)
So, to summarize whatever we discussed in the last two lectures basically we discussedabout the system level design problem as the initial first function of the design processwe discussed that there are 6 functions.And the first one is the system level design problem and then under this we discussedabout the operational concepts how do you develop a very preliminary operational
concepts and then how do we identify the external systems, how do we look at theoriginating requirements, how do we look at the objectives hierarchy and then how dowe document and manage the requirements.So, these are the topics we covered under the system level design problem, but do now isto take few examples and explain how we actually go through these phases and developthe ORD for the particular case. So, to do that let me go to the a particular examplewhich we already discussed in what about this I will go to the same elevator design andthen go through the different operation scenarios and operational requirement and thenwe see how do we actually write down the requirement for this particular system.(Refer Slide Time: 22:27)
As you know the operational phase scenarios so that is the first step in identifying therequirements. So, we have different scenarios. So, one of the scenarios we alreadydiscussed about this how the passengers use the system. So, we clearly write down thesteps involved in using the system by a user the passenger.So, we say passengers including mobility visually and hearing challenge request upservice receive feedback that the request was accepted, receive input that the elevator caris approaching and then that an entry opportunity is available, enter elevator car, requestfloor, receive feedback that the request was accepted, receive feedback that the door isclosing, receive feedback about what floor at which elevator is stopping, and receive
feedback that an exit opportunity is available, and exit elevator with no physicalimpediment.So, we have clearly explaining all the steps involved in using an elevator by a passengerand that actually includes the mobility or visually or hearing challenged people also.Now once we have this scenario we will make an input output trace to find out what kindof interactions what kind of feedbacks are happening between these 2 the system and it isa external systems.(Refer Slide Time: 23:43)
So, here we are identified elevator as a system and passenger as a external system. So, ifthe passenger will ask for an up service request and then there are many feedback fromthe elevator feedback request was received, feedback that car is on the way, feedback thatdoor is opening, and then an entry opportunity is provided. So, this actually shows thatthere are 4 types of feedback going from the elevator and this actually identify therequirements also the output requirement from the elevator.So, this was an input requirement for the elevator that an up service request it you needto be accepted and these 4 actually tells the output requirements from the elevator, that isor the elevator should give these kind of output to the passenger. And then there will beanother input from the passenger or the external system that there flour request orrequired floor request is given to the elevator.
So, this request uses another requirements basically the passenger should be there shouldbe an option for a or the passenger to give the inputs and there should be a facility toaccept that input and then to process that input at a later stage by the elevator. And thenonce you have the input is received that by the elevator then the feedback to be giventhere are 2 feedbacks here sorry more than 2 there is a feedback that request wasreceived, there is a feedback that door is closing, there is a feedback about where thewhich for the elevator stopped, and feedback that the door is opening after reaching thatparticular floor and there is an exit opportunity provided.So, all these are the output from the elevator. So, the elevator system and we designedthis elevator we should identify these are the output requirement from the elevator. So,you can see that using this diagram the input output trace you can actually see; what arethe input requirement and what are the output requirements for this particular scenario.Like this we can identify many other scenarios and try to identify all the requirements.(Refer Slide Time: 25:38)
For example there is another scenario the passenger enters elevator car as described inone that in the previous same scenario, but finds an emergency situation before an exitopportunity is presented.So, there is an emergency situation it can be a anything it can be a malfunction of asystem or within the elevator or there are some smoke inside or there are some other
elevators some danger to the life of the person or some theft inside or whatever it