Module 7 - A202

A202: Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content

HTML of the Course Transcript

(Note: This document has been converted from the transcript to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included.)

Shelley Row
ITS Standards can make your life easier. Your procurements will go more smoothly and you’ll encourage competition, but only if you know how to write them into your specifications and test for them.

This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems. I’m Shelley Row the director of the ITS Joint Program Office for USDOT and I want to welcome you to our newly redesigned ITS standards training program of which this module is a part. We are pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines Web based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself. This combined approach allows interested professionals to schedule training at your convenience, without the need to travel.

After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the webinars. ITS Standards training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB program we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter and greener which improves livability for us all.

You can find information on additional modules and training programs on our web site ITS PCB Home. Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you again for participating and we hope you find this module to be helpful.

Nicola Tavares
Today’s webinar is Module A202: Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content. The target audience for this module is engineering staff and project managers.

Your instructor is Dr. Raman Patel, who has been actively involved in the ITS Standards development and standards training program for 15 years. He has served as chair of the ITE Standards Committee for the past 15 years. And is a member of the NTCIP and the TMDD committees. He is the president of RK Patel Associates and currently teaches ITS and transportation engineering at NYU Poly in Brooklyn, New York.

Raman Patel
Hi, everyone. I’m Raman Patel. Thank you for attending today’s seminar on A202

I would like to start with suggesting to you that there are two curriculum paths that PCB program has developed for us for the ITS community. This one here shown has been designated as curriculum path with SEP standards. What that means is that certain standards were developed using systems engineering process, or SEP, and these modules are coded on this path. The first four modules that you see here are common to both SEP and non-SEP path and they create a foundation for the rest of the modules to follow.

Today's module is on the non-SEP path. As you can see, it's highlighted here, A202, which is the subject of our discussion today. And it is focusing on identifying and writing user needs when they don't exist. And there are certain standards which don't have user needs as well as requirements. And we are learning here today to identify and then write user needs for those standards which do not have documented user needs.

So A103 introduces the subject of requirements and then it's followed up by A203 in detail, which is the next module after today's module that you will be required to take to complete the course on how to handle standards without SEP content. The last two boxes that you see here are placeholders for the device standards that are likely to be included. In fact, they are going to be included in the next part of the PCB program. So we will learn details about how to write user needs and then also requirements for those standards, device standards which do not have this kind of documentation.

In today's module, these four, the first four modules you've seen before, are the requirements that they are required prerequisites that you must take them so that this course can follow on what we have covering those course. Also, basic knowledge of these four areas is very helpful in understanding all of the subject matter of ITS Standards and deployment and what is required and all other things. And also, the systems engineering process that's behind all of this different development processes that we are following.

Our learning objective for today, these six learning objectives, will guide us in our discussion today. And at the end of this course, the participants, or folks like you in the audience, as well as those who later on access this module, will be able to understand what the role is played by user needs. And, in fact, how do we interpret the structure of standards where these user needs are located. So the first two learning objectives will prepare us in terms of what we have to do and where we can find that information on user needs. The third one, learning objective three, specifically focuses on concept of operations. It is the main source of our work today and we will figure out how to actually interpret what is in the concept of operations. And then extract the user needs the way we need to. All right, the number four here is the method with which we can write a user need. There is a definite structure that we have to follow so that we end up writing a very clear and unambiguous user need that other people can read in the specification. Number five here is the heart of the subject matter we are discussing today. We know there are certain standards don't have user needs. And we also know that there is no additional help other than we end up writing ourselves. And then we need to learn how to extract user needs from different standards and actually put them, the user needs, in the specification. The last one here, the validation of user needs, is that at the end of the process, we also understand what role the user needs will play in terms of getting their system accepted. And then understand that user needs drives this whole process of development. So we have to figure out how we can use the user needs to check this system validation against each one of the user needs that we have. So collectively, the six learning objectives will guide us today in our discussion on A202.

The learning objective one will begin with this role map that simplifies our understanding. There are three categories of standards that we are facing in the ITS community. In fact, we use them in a mix of application areas. So they are data or information standards. Then you have communication standards, such as NTCIP, that we are all talking about here in these modules. And then, also, you have the treatment standards, such as the cabinet standards or NEMA TS2 - traffic controller standard, for example. So there are three types of standards but they come in two different types.

One is developed with the SEP process and therefore they have SEP content. Those are shown on the left here. And they do have documented user needs. So that's the main point of our chart here that says where do we find user needs which are all ready documented. So we at the agencies are preparing—people who prepare specifications—will have no trouble getting user needs from the documentation that comes with the standard. That's done and this was explained also in the other modules, A102, as well as A201. So on the left side, user needs are already lined up for us and agencies simply go out there, look at the standards and select according to what the project requires or needs.

On the right side here, we have a different situation, somewhat different, because these standards were developed without SEP process and hence, they do not have user needs documented. Also, requirements are not documented. So, therefore, we have to develop them in preparation of specification. However, I also want to add that both non-SEP and SEP standards have design content income so that part is pretty good. However, we have to extract user needs and requirements on those standards that don't have those things available. So that's basically the story behind our module. And we have to deal with that.

And one might ask this question – how do standards support operational needs? We all know that we begin with our discussion in every project that we come up with in ITS arena we start with saying I'm doing something to help my operations, you know. That's the basic context. We all want to support our ongoing operations and future needs. And therefore, we answer this question, saying that in the NTCIP family of standards, device standards particularly, we provide an interface so that we can actually remotely access field devices. And the reason why we want to access remotely is that we want to configure the device. We have to make sure the device is being talked about, it's properly set up. And then we monitor the device by remote access matters. And then we control the device, meaning that we actually ask the device what to do. So that kind of control mechanism is also very important in the way we conduct our operations. Finally, we also retrieve information. The device has some good information stored there locally. And we want to have that device information so we can retrieve that. So there are four ideas or four things, actually that people go in with in terms of acquisition process – saying I want my device to do the following four things for me. So that part is good for device.

Something similar is also good for systems. Systems communicate to each other and exchange information. In the center-to-center context this is very important. So the interface that we are looking for in terms of information exchange also comes from the fact that the operation demands that. So you have two ways to look at that and say how standards support my operational needs.

This is a very detailed view of what devices we are talking about in the NTCIP family of standards. Those on the left side, shown here in the green, are the standards with SEP content. So, for example, if you are requiring DMS or TSS, you should have no problem with the documentation. You have user needs already described in the standards. You also have requirements already lined up for you. So you are basically selecting whatever you need for your project. So that happens for the SEP type of content.

On the right side, again, this familiar standard, this is actually a signal controller, for example, does not have user needs listed in the standard documentation. So if you are going to buy traffic controllers, you will have to do that yourself and then read the standards and come up with what needs to be done. The same thing with the other list of standards here. So there are a bunch of standards that you can see that are there without SEP content. And therefore, today we are exploring how to go about in handling the standards in terms of writing user needs.

The next module, A203, will deal with the requirement part of the subject matter for all of these standards that you have here. So that's how we understand that the device standards come in two different varieties – one with the SEP content and the other without the SEP content. And we have to deal with both types because when we acquire ITS-based systems, we end up using mixed standards.

So where do they fit? That's a good question to ask. Where do all of these different standards fit? Well, they come up with the discussion at the high level design stage in the SEP lifecycle process. On this “V” model you see this is where the standards are involved. And they are mixed—they may be SEP-based and therefore, you have user needs and they may be not SEP-based and therefore you don't have user needs. So we have to make sure that when we at the high level design and retail design stage we deal with these standards properly.

So what should go in the specification is the next question we had to ask logically. Well, there are three things that are going in the specification. We describe the user needs and we describe it in the literal sense that what the user wants. So these descriptions are user speak. In other words, they actually say clearly that this is what I need. And then it lists the features and functions that the device should do. This is very important to understand that we have to give some idea as to what we are trying to do. So the what and why issues are handled in the user needs very correctly because that's the beginning of our process. So user needs describe what the user wants from this interface and what features it should have.

Then you follow that with the requirements in the middle. The requirements actually deals with detailed description and they provide us with a little more clarity and also they are measurable. In other words, every requirement can be measured with some kind of criteria and say, well, does it meet or doesn't it meet? So requirements are very specific and they are always written in the “shall” language. And I think I'm sure that all of you have seen that in your specifications.

Finally, the design element. The design element is the design concepts, what will make those requirements fulfilled. So that is the part that as I said earlier, all types of idea standards have included design in them. However, the allocation or what design elements we will need will come from our project-related requirements. So in the specification we prepared for our acquisition process, we have all of these three elements in them.

I have a little activity here and what I'd like you to do is to state in the chat box what should we do when user needs don't already exist. Just go ahead and write something in the chat box. All right, anything?

Okay. Well, how about—very good. Keep in mind the requirements. And also discover what the user needs are. So somehow we have to engage. These are good answers. We have to engage ourselves in some sort of discovery process. It could be a simple reading, for example, of the documents. It could be a reading of the stakeholders' interviews for that matter. Or it could be a concept of operations. But whatever documentation you have in front of you, and also including in this discussion is the idea behind the project, for example, why this project is created. And substantially you will justify. So a lot of these things are in front of us and we can actually look for it and say well what are the user needs? What are we going to do with these things? So we have to go ahead and look at those sources where user needs are.

So simply put, we are actually developing. We are developing user needs when they don't exist. So a lot of this discussion is covered under A102 because that subject was dealt with in great detail. Also, certain standards don't have user needs. We have to recognize that. And therefore, we must discover as you just answered. And I said a couple of things that we need to look at it. So there are sources we have to explore and we also have to go to standards themselves and see what's in them. And finally, when we are done with this too, we have to actually sit down and write the user names. So basically, that's the kind of thing that we have to go through.

Now, this question is why do we have to do it? Can I not just simply write a few lines and say let the developer figure it out? Well, no. The answer is no. We cannot do that. We have to actually develop the user needs and write them simply because there are three reasons. One of them is the tracking. Development takes a long time. It may be a longer process in somewhat but it follows the lifecycle process that big diagram you saw earlier and at all stages we need to see what happened to user need, so what is going on? How do we track ongoing work if we don't have written down user needs? So no one seems to know in the team, the development team what's going on? That we need to eliminate. We cannot do that. So we have to develop user needs for tracking purpose so that's one major purpose.

Second, if we don't write, the developer on the other end is going to guess. They might say, well, the user probably wants this and make some assumptions based on guessing and then you will end up with a system which is incomplete or complex or not even workable, and certainly not interoperable and I'll explain to you that in the next reason.

So systems are designed for a specific purpose. Here is another reason why we need to be concerned about user needs. Well, our need for interoperability, a system talks to another system. So what does interoperability mean? If you haven't seen this definition or heard I'll give you a very simple definition here. What it means is that according to IEEE definition, it means that one system exchanging information with the other and then use the information so exchanged. So in practical terms, what we are saying is that my system should be able to talk to your system. In other words, there is a need for information exchange between two systems. So that method has to go across the development team. If they don't hear that your intention is to gain or seek interoperability that message could be very, very detrimental. There could be a lot of damage in terms of system development and which may be difficult to handle later on.

So interoperability is a desired service or desired outcome that we are all looking for and user needs is the first step towards that process. So very clearly, again, I will repeat. User needs are the first step towards interoperability.

Similarly, we start with our installed base. We have a few things already out there in the field. For example, in this diagram, we are showing that we have a legacy system or existing equipment and now we are expanding, but we are adding few devices in the field. It could be a CCTV or it could be a traffic controller and so on. So now what we are looking for is multiple vendor participation. We don't want to get stuck with one vendor or we don't want to have a problem not being able to add different devices on the communication pad channel. So such issues we want to handle in the sense that our system developer should know that you, as a user or the owner, is looking for vendor independence. We want to have not stuck with one type of equipment with one vendor and then we have to deal with another vendor for the same equipment. So that situation is out there, you know, and we are trying to get out of these things. And most of all, our emphasis in ITS system development these days, it means that we have multiple vendors participating in our process. So that many of the reasons that you have probably heard before but vendor independence is also another consideration for user needs. We must let the developers know what our intentions towards vendor independence is. So there are two reasons interoperability and vendor independence go together with the others that I mentioned.

So now you will say – well, where are user needs located on “V” model? This is the lifecycle model that we all follow in ITS development and we have to follow and we should follow. And when we look at this system lifecycle model, we say, okay, first time, I understand the user needs are present or discussed as original architecture. Original architecture is the location where we have multiple stakeholders get together and then hash out their needs, they talk to each other, they finally agree, and there is a common consensus and we walk away with a list of user needs. And say okay for our region or for our local area, we have this amount of user needs that we need to have in our planning and our ITS project development. So this is one place where you will face multiple stakeholder user needs.

Then we move on to stepping out of the general architecture and we go to concept of operations which is a big picture, which is also a document that lists everything in terms of what problem that we are trying to solve. The ITS development proceeds with a problem definition. We develop the system because we have certain needs, certain problems that we are facing, in our situation we may be facing. And we're trying to alleviate the situation or resolve that problem that we are facing. Okay, we may have a congestion as the issue or a problem in the region. So some of these things are written down very clearly in the concept of operations. And in that sense, you have a general agreement amongst stakeholders and say well, this problem is out there and we are working on it and therefore, we have this user needs. And that is what we are reading in this concept of operation document.

When we go to the third source here in the reassessment. But as you know, the operation and maintenance level we have built systems. We are using systems for a long time. Some of the systems were built in the seventies and eighties, and even earlier than that somewhat. But in any case, we have learned things from these deployments out there. We know what works, what doesn't work. We also have maintenance headaches as many people will put it and we try to get out of some problem, lingering issues. So a lot of user needs are also piled up at the operation maintenance level that we need to explore.

Also, ITS has evolved. Over the years, at least in the last two decades, ITS has taken shape now at a deployment level and now our needs have somewhat changed as well. Maybe at TMC that was a small place before, now it's a large place and now it's a joint traffic management center and all of these things create additional needs that we may have not looked at it before at the concept of operation level. So it also gives us an opportunity to talk to people in different phase, at different stages, and bring them together and extract the user needs.

So to summarize this slide here, I would say that you look at the regional architecture, concept of operations, and then you also look at that your M&O as you say it sometimes management and operations of the task. And then look at and see what user needs are played by in this whole thing.

So this is an opportunity for us to summarize the perspective of the user. From the user's perspective we are looking at the system development and in the sense that we must put a handle on what the system must do. And the system must always support operational needs. So we begin with that and we communicate our intention to the developers and say, well, I want this, this, and that as a feature of my systems. And features are the behavior of a device. They are generally expected that my device will do this, this, and that. So you can create a list of functions that the device will actually end up performing in the field. So we do very good work in terms of developing this part of the operational needs. So that becomes the basis for development for the system, development team. And they will clearly understand yeah, oh, I know now why the user wants this particular system and why these features and why these functions and what they mean to the users in the operational context.

The other side of the basis on this discussion here is that systems are used. Once they are developed, they are used. So we anticipate certain ways systems are going to be used. So the utilization, so the design process, the development process also should be mindful of how the system is likely to be used. So we go out at three different levels. First, we go at the operation levels. And say, okay, at the TMC, we know they have certain opinions, the TMC operators are very fixed in their opinions, they certainly like certain menus the way they are used to or the way they want to use them. So we need to understand what operational level staffing is going to require the system to do and how they're going to actually use it.

This is a very important point because we want to design something that is going to be used. We want to a build system that's going to be used in the environment that system is going to function. So we are not designing a fancy system and put it away in the corner. We are designing a good system that's going to be used by, hopefully, everybody in the room. So with that in mind, systems are designed to do a good job for the people who actually use them. Also, you have strategies, you have management strategies behind this concept of system operations. Traffic engineers and system engineers—they developed strategies. They developed morning strategy for traffic control, for example. They have a use during emergencies, for example. So all of these things—operational support that different group of people will need traffic engineer, system engineers. So their needs are also paramount in the way systems are going to be used. So we get that input squared away.

Finally, we're down to the system maintenance, how the system is maintained, how the infrastructure in the field is maintained, how those devices, thousands and thousands of devices out there so that a group of people who actually are engaged 24/7. They keep the infrastructure running operationally and therefore, they have certain needs. They know a thing or two. They're also aware of what works and what doesn't work. And we haven't heard from them at the design level or a specification preparation level. So we need to draw that input because their support is also very important because they keep the system running.

So when you put these three things together in the support side of the system development, you say, okay, this is how the system is going to be used or utilized in the real environment and therefore, the development people will keep notice of it. So what we are seeing here is user perspective is what drives the system. So this is a very good summary in saying that it's the user's perspective that will drive the development process further. And then we leave this idea of user needs saying that user needs are the mechanism.

User needs are the conduit between the user who wants the system and the developer who is developing the system. So this bridge is closed very clearly so that we end up getting what the operation needs and what the support is going to create for the real environment. So that summarizes our learning objective one. Let's now move on to learning objective two. So where is this information out there? So we look at the structure of the standards, the structure of the standards for the SEP-based standards has all of these three things: user needs, requirements, and design concepts. So we simply go to the design document and extract whatever our needs are.

Here's an example. This is the SEP-based standard. And this is an environment of essential station standard or ESS. So you look at it here and you have a very clear definition of user need. You don't have to write it. Somebody has written it for us. And that's the standard. Standard has clearly wrote this user need. For example, it reads “A transportation system operator may need to monitor the depth of water.” Now, we all know these recent experiences we are having with flooding. So we need to know what kind of user needs are there to measure depth, how many inches of water or centimeters of water result there on the surface, right. Well, that's the user need. That user need is now followed up by the standard in a very clear way. And it says, well, this is how that thing is going to be done. So remember I said that every requirement is measurable when we said those three things earlier? Well, that's what it is. We're going to measure the water level in terms of inches. So that kind of information will go in the requirements. And that will be implemented by the design. So the design level activity here is going to be fulfilled by this level of detail provided in the design that connects to this requirement. So this is the requirement.

This requirement here is now handled with this three type of basic design concepts. And that's what we are seeing here. So now with the non-SEP standards the first two things disappears. They don't have it. We don't have them. So what I mean is that the only thing we have in the non-SEP standard is the design concept. So our job is to extract those two things, user needs and requirements. So we have to distinguish. We have to explore design concept and say, well, how does it make sense, how do I get the user needs, and how do I get the requirements right. Well, today's module is going to help you to understand that process.

If you look at this structure and then you look at this table of contents for each SEP one here, for example, so that there are five sections. Most of the SEP-based standards have five sections in them and they have concept of operations. Of course, I need to know what's going on, right? So that's very well written. Functional requirements are those detailed requirements. Not only are they required details, but they are also measurable. You're going to look at them in terms of quantifiable way. And say, well, can I meet these requirements later on? Okay. And the last three sections generally deal with the design portion of it. Here's the dialogue. Dialogue is a conversation, right, process? So, in each of these SEP standards, we have sections that we have created dialogues for that particular device. So you are reading through. If you are dealing with, for example, DMS, you will see all of the DMS-related activities are put in a conversation process. The last two are the key parts in terms of objects, for example, data elements. So these are building blocks from which a message is created.

So protocol requirement list, for example, connects all of these different things. It connects the MIB and the dialogues and function requirements. So we end up with a good level of understanding of what the standards have to offer.

And this is a real example. Here's a DMS example and everything that I said earlier is reflecting in the real content. This is not the case with the standards without SEP content. Unfortunately, we are directly going to numbers three and four which are the data objects. And we are dealing with the design, so we don't have concept of operation and you can see we don't look at it because they are not there. So, without the SEP content, for example, in the system area, the one you saw before was a device. Now you look at systems such as traffic management data dictionary is a system standard but that's the only one we have developed with SEP. So we have everything in it. But in, for example, the 1512 emergency management standard there are no concept of operations written down. So we have to struggle and put things together in the same way that we have to look for user needs and the requirements and isolate them from the design content.

So to recap this learning objective two, we have said in a number of ways that we discussed this in one or two developer user needs. And then I also mentioned today that there is a strong way of looking at the user's perspective before we build the system, right? So that creates the basis for the system development both operationally and also how utilization is going to be made out of that system, how the system is going to be used. So then we also said that interoperability and vendor independence user needs are a path to that. User needs create a path to that consideration. Now, what we are saying in addition to that, we are saying that we have just found out by looking at the structure of the standards both SEP and non-SEP, we also know that to prepare the user needs and explore them we have to actually go to the standards and we've got to actually prepare our specification and look at the standards we have to explore these standards to get to the specification level. So that's the summary or the learning objective two.

Now, I'd like you to have a little poll here and answer this in your poll. Has your region developed regional architecture? So let me launch the poll. All right, so yes or no? All right. Close the poll. All right. No answer here. Okay. So chances are very good that you have developed a regional architecture. In fact, they almost exist in every region. They certainly exist in most metro areas and state level regional architecture processes. So the answer is yes. And then we will follow up with that thinking that if the general architecture does exist, then there is also the concept of operation that we must look at it and say what does concept of operation reveal? Well, concept of operations reveals a big picture. It has everything in it that you may possibly want to look for and interpret and sell out, why this project is created, where this project fits, what is the current problem, what is the situation that we are facing? And how do we actually—so who are the users? And who are the effected bodies in this concept of operations, also? So we have to look at all of these things in a general sense and say, well, is this project going to have other users impacted? And have we looked at their needs?

Then we've got to do operational scenarios. And in operational scenarios we are looking at what works, what doesn't work. And we have a situation that we face in every day life in our metro areas or cities or region that we are in. And then we face each individual operation in some areas differently and then we have to deal with them. So there are needs associated with the operational scenarios and they play a part in our considerations when we prepare the user needs. So are there additional either general aspects? Each region is different? You know, some regions may have a transit as a heavy presence. Other regions may not have transit as a presence. So a lot of these different things will come from a general context as well. So now when we write the user needs, we look at the concept of operation.

We also look at the project concept. Every project has a meaning behind it. And we investigate why this project is taking shape and who created it and why it was created. Operational scenarios I just mentioned and operational scenarios I like to present them as saying actually they are the gold mines. Sometimes we get a lot of good information, and we'll deal with them in a minute. So regional architecture is another one.

Additionally, we also go to the stakeholders and we ask them questions. We take their interviews and say, well, what do you think about this? What do you think about that? We assess everyone's needs. So interviews processes are also very good and they are done in real time so we actually see people and places and names and we can converse with them and learn a lot about the user needs. Also, the assessments workshops. These are specialized ways of doing things. They focus on one particular area of a project or gather people together and say well, let's discus what our user needs are. So sometimes they are for user needs assessment workshops. Okay. And that's multiple stakeholders. And a lot of times we hear good things but also hear bad things and that's good because they will also tell you what works and what doesn't work. And their opinions will be also very helpful in shaping the user needs.

Finally, the case studies. The case studies are the summaries of lessons learned. That's the way I look at them. They have very good information. Again, what works, what doesn't work. They also have bad things about vendor relationships, good things about them. So they can also judge what works and what doesn't work in terms of where we are getting our hardware and software and all of those other issues. And sometimes there are constraints under what circumstances the treatments cease to work or communication failure occur. A lot of these good things that we have looked at in terms of where the user needs are located.

Concept operational is a fundamental source for operational requirements. What you want to do operationally is answered in concept operation very clearly. So when we look at them we have to say, okay, let me look at it. What operationally needs to be done? So that will come from concept of operations. There are also specific systems and specific users that may have been listed. We've got to look at for those good level of information there are second or third level of detail information maybe out there in the concept operation that we need to reach out and extract. Also, what are the expected regional interactions? If this project is created, suddenly other people are going to be affected. Until now, they were not affected, but now they will be. So what is expected and what is unexpected also needs to be looked at in terms of regional context.

The operational center use there are several parts to it. The question that most important that begins with this discussion on operational scenario is what is to be done? There is a situation developing. There is an emergency in progress. There is a calamity. There are major things that are happening in the region and what needs to be done? So there is a task-oriented. And as soon as you say what needs to be done you're also talking about simultaneously who's going to do it. So what is to be done and who's going to do it? Roles and responsibilities and tasks are also lined up in operational scenarios. And they tell us that who and what expert is that particular person or group of people will require.

And who needs to be communicator? Information is produced during these processes. Even in emergencies there is very good information out there that needs to go in the right places or to the right people. So we need to figure out how the scenarios are managed in terms of who uses the information. So that creates also user needs. And we'll see some examples later on.

Also, scenarios are managed using standard operating procedures. Every location, every place, every TMC has an SOP. So SOPs are outlined of what the operational scenarios are, how they will be managed, who will be responsible. And sometimes you also learn from the past events. And all of the scenarios are always written up, that I guess, it is done in a routine way. So we learned from what happened during the last time and how was it handled, or how was it not handled. And that will also generate some user needs requirements. And then SOPs are carried out by TMC operators. So if you go and ask them questions and learn from them you will actually walk away with user needs.

So summarize this process of concept of operations. We know going in that there are at least three sources that we can lay hands on. Regional architecture is a document and I guess all of you answered in a very correct way that regional architectures do exist and I'm sorry I was not able to read chat before. So that portion is there. So we are confirming that regional architectures do exist. And then stakeholders' involvement is omnipresent. They're always there. So if you look at the regional architecture, we also know who the users will be and who will be affected by this. Then concept of operations and operational scenarios, as we just discussed, also reveal the real things in the sense that how the system is going to be used or likely to be used. And then, of course, the relevant standards that's in front of us. Those charts that you saw earlier, with and without standards, come in handy for us to go and look for it.

So now we are going into learning objective that requires us to write the user need. So here we are saying there are four steps: A, B, C, and D that we will follow in terms of sorting out how they're going to write the user needs. So the first two, A and B, are preparing us. So we go in there with operational needs as A. And then we look for—as soon as you know operational needs—you are also talking about which standard you are talking about. So if you are talking about surveillance or congestion management you know you're talking about DMS or CCTV, right. So A and B most likely are going to go together. So then we say, well, now I know which standard that I'm dealing with and now how I am going to extract information regarding user needs from those standards. And then finally we write them, right? So we're going to follow this in the sense that we need to extract the process, we need an extraction process to get the user needs. Let me just go to do D first because by going to D we will also learn more about it. So this is an A and B. And in D, we are actually learning to write user need. So this criteria I'm sure you have seen that in previous modules. So this is SEP-based a process system engineering has taught us to write user needs following this criteria.

So this is a four-step process. And it begins to be giving structure to the user need. They need to provide a user need of structure saying, okay, this is a user need and I'm going to like it in a certain way but I also want to give it an ID, a unique ID and then it has a title on it. So that is a structure that begins from the user needs standpoint. Then, in a major desired capability, what is the reason this user need is for? What function is going to bring to the table? What is the major design capabilities going to produce? So that's MDC as we said and that brings the clarity in terms of it's the system's need to exist. All right. Then we have rationale. Why do we need this user need? We need to answer that question so this developer also understands that there is a reason behind this user need. It doesn't just show up for good to have it on the basis. But we have to actually justify or capture the rationale. And then it could be put in a proper context so everyone who is involved in it understands that there is a reason why this user need exists. Finally, you are not the designer. We don't design a user need with the solution in mind. We don't develop or we don't write anything and say this is the way this user need should be matched. We don't provide a solution. So what we're saying here is that user needs do not have solutions in their reach.

Don't get into the idea of designing. Don't get tempted. A lot of times you say well, this is how I want my system, you know. We're not normally supposed to do that, all right?

So using an example...This is a structure. You see here is the user need, and it has a specific ID number and the title. This is a unique number. It does not get repeated in the specs. Only this user needs has that. It's a nice concise title. It's not a long one, but it does capture the main point of what you're talking about. In this case, it says control CCTV camera from more than one location. This is good. You could write this sentence in many different ways. What it says is this device is going to be used from multiple locations. That's what we are actually implying. All right, but it's capturing that. Also, this user need is going to be identified throughout the process of SEP's lifecycle. So we can track this user need with this number, okay? So that also is a very good thing to have. And when we track the system we're going to be making sure that our user needs is discussed, is handled and in fact, it goes to the requirement stage.

So let's give meaning to a user need. We cannot just write in any way we think. We should follow the method and say okay we're going to make the user need so meaningful that anyone who reads it will understand what we are trying to say. So in this example, we are saying, until remotely. All right, so that's the main MDC. We are talking about providing this capability that doesn't exist now but we want in our future system or the acquisition process. So we want to control this device remotely. So that's MDC. Now, we have a rationale why do we want it? Well, we are managing congestion. So if we are going to manage congestion that's the general context in the region. And it captures the rationale in a very well understandable manner because you all know what congestion means, right? It doesn't say anything different. Then it doesn't have solution. It doesn't say anywhere how it's going to be done, how it's going to be met. We don't share that. That's part of requirements analysis to come back and tackle, all right.

So let's have a little activity here and answer in your checkbox answer. Is there a standard that you know without SEP content? Can you tell me what standard we have that does not have SEP content in it? Twelve zero two. Twelve zero two is actuated signal controller. That's NTCIP 1202, where it says actuated signal controller is correct. Any other one? Anyone else? Okay. So the other one is all right. The other one is also CCTV. If you don't remember the number, that's okay, you know. We will go by the names of the devices. So actuator signal controller ASC 1202, 1205, also the CCTV. Then you have other traffic detectors, video switch, network camera, and also the ramp metering. These other standards do not have SEP content and therefore, we need to work on them to develop them. So how should we do it? Any idea? Anyone wants to venture and say what are we going to do in the chat bar? Okay. Because what I will say is we're going to look at those things that you mentioned earlier, here's operational scenario excellent. This is the great way to go and say okay, I'm going to look at what relevant standards that I'm going to be needing and operational scenarios will help me. This is a very good answer. So you also explore any documentation that you might have and that will help you in getting where we need to go.

So let's look at these different aspects of the standards where you don't have SEP, okay? And, I think, I mentioned earlier, you probably recall, that the non-SEP standards have two parts in them, MIB and conformance groups. Let's just look at the first one, MIB. MIB stands for Management Information Base. And what it is is the collection of different objects. So collection of objects is necessary because they help us in terms of dividing, in terms of designing our system that we expect from it. So MIB is a collection of objects. And they go into a database information. And then, for example, every device has its down MIB. So, here in this case, I'm saying CCTV has MIB that contains 70 objects like that, okay? And they are located under 12 different nodes. So they are nicely and neatly placed following this lexicographical order. And that is something that we need to do in the system engineering. And we are doing that in all of our NTCIP standards. And then they follow this pattern. So when we look for them in the design process, we know where to find them. So that's good. So all objects are housed in the MIB. And each one of these objects represent some kind of information, some unique piece of information that we are interested in our device that's represented by this object. That's what we're learning. All right.

So now what is the purpose of these objects? Well, if you have any object in any device, we can use that object and manipulate it. And what the manipulation means is that we can actually configure the device remotely, right? We can also monitor a device – what it does in current time, remotely. Also, we can ask the device to do something different than it's doing now, also remotely. So this functionality that we want from a device is made possible by manipulating or managing the object. And to do this, there is a mechanism in NTCIP what we call system—what it stands for is—SNMB is a protocol that allows us to do this remote handling of the objects, all right? You will learn more in the future modules, but right now it's sufficient to understand that management station which is a central station telling the field device what to do using these objects.

So let's look at the structure of the objects. How does it look like? It has the six parts in it. Very nice and neat. All NTCIP devices follow this structure. Therefore, all different vendors, different device vendors, are also aware of it and they know how these objects are manipulated. And they also understand the value behind this process of manipulation. So when you define this thing what we are saying here is that there's a standardized language calling ASM. 1 is used to define this object.

So the design process itself is standardized, all right? So that's a good thing. So now we have multiple vendors don't do their own thing in designing these design concepts, all right? Everyone follows the same matter. And out of that we are getting good interoperability that we are looking for. So these six parts object has a name. This object has its name. This is a unique name. He has a value. The object has a value in it, 0 to 255. It allows me to make any number in here. I say one, two, five, whatever number I come up with and I assign a value to that number and I can manipulate this object to my advantage or whatever I want to do.

So this is a functionality that I'm looking for. This is a key part of an object definition. It allows us to vary these numbers and therefore, we will have different actions. So remotely we can tell the device what to do by merely changing these numbers in the MIB so that's what we are doing. Also, this is just for reading purpose only. You cannot write anything on it. This is a read object, for example. Also, to meet a standard, this must be necessary. This object is necessary. There are several objects out there that may not be necessary, too. So in that case, it will say optional. Also, this is the definition or description which is available. You can read it in a very simple way and understand what this object stands for, all right? This is an ID number. This is almost like—this is a unique ID number with which we can identify. So this one here is a numerical. Eventually it turns into a numerical value. And so is this. So we remember this and that in the whole process.

Let's look at the example here for signal controller example. This is the ASC that you mentioned earlier, 1202. And that was rightfully so, because it does not have user needs. So we have this design process now in front of us. So to manage an object, we are actually looking at this value here. So suppose if I want to tell a vendor I want an 8-phase traffic controller, this number will be 8 here, not 255. Nobody needs 255-phase traffic controller, right? I'm sure you all agree with that. Also, no one wants the traffic controller with the zero phase right? Because you want a minimum of two phase traffic controller, something like that. So that's an idea. Now, also you can see that the interoperability as well as the vendor's ability to deliver different products to different customers is also good because, for example, some customers may only need four-phase traffic controllers, all right? And vendors don't have to build eight-phase traffic controllers. So the vendor can supply you what your needs are. So that's a user need issue, all right.

On the other hand, somebody in the big cities may need 10-phase traffic controllers, so that need will change. So there is a mechanism in here with which we manage an object by telling the vendor what it is that we want. So now the second part to that is that it has a fixed location. So if we know the value of the object and if we know its location, I'm sure we can manipulate it anywhere in the system development process, okay? And that's what the managing object means. So to summarize this part of the management information base and managed object discussion is that data is contained in that pair, the object ID, the OID, and the value of the object. So both of them are unique to particular design content. And therefore, we pair them together. So wherever we do a system manipulation, this pair goes together. So that's what we are saying. They together, they fulfill the design requirement. This is a requirement-related issue that they meet because the design actually is supposed to complete the requirement, okay? And that's what it does.

Now, also, this thing becomes part of the message, the SNMP message that I mentioned that I want you to do this for me, so that message will be containing this value in it, this together. Okay. So in the future module I'm sure that you're going to deal with this subject in more details. But right now for the purpose of today's discussion, I would like to say that every object moves around in the system with these two values: OID and the value of the object that what we're trying to do. The second part of this non-SEP standards discussion is conformance groups. The MIB deals with the data content.

Conformance group is a listing of the related objects. So conformance groups is a logical way of looking at a bunch of objects that are together. So this is a good way to say that a conformance group is a logical grouping of related objects. Why logical? Because if you do want to have certain functionality we've got to bring related objects together. We need more than one object to bring everybody together, so that they can collectively deliver a function. That's the idea behind this listing. Now, this is just a list, okay. It doesn't do anymore than telling us that these are the objects you need. All right. It doesn't help us in the sense that we are putting a message across the wire. That is done by the MIB related activities. Here this points us in the right direction, a conformance group is logical grouping that points in the right direction so we can end up getting to objects that we need properly. All right. So conformance group helps in determining required objects. So if I know a conformance group is necessary then I also know that with it required objects will be also necessary. That it will be a listing that is good for us. All right. So for every function, there is one conformance group. That is the idea that we are walking away from this discussion. Every conformance group has one function.

Here's an example of conformance group for motion control, for CCTV, which is 1205, which does not have user needs and requirements in it, all right. So we are looking at the conformance group in this standard. And we asked this question. It says, well, what's in it? Well, here it is. These seven objects are in front of us are actually making up this conformance group and then delivers this motion control requirements. We want to control remotely camera and therefore this together. Not one of them, but seven of them are needed so that we get the functionality that we're looking for, all right? This is why the logical grouping is used here in the sense. All of them make sense to each other, all right? And they co-exist so that something happens in terms of delivery of a service.

Continuing with the discussion, do I need everything? No. The concept here, to meet a certain standard, you are required to understand these two concepts: mandatory conformance group must be selected. Every standard, SEP and non-SEP based standards, every standard has already outlined in the documentation what a mandatory conformance groups are because that's the minimum requirement. For example, in 1205 CCTV, we have made this conformance group mandatory. This is the only one that is required. The rest is optional, from which you build your system. So this is a standards requirement. This is your requirement. You are telling the developers that the standard is telling the developer that don't forget this conformance group you've got to do this. You, as the user specification writer, is telling the developer that I want the following conformance groups because I also want to extend the functions. I also have a need for controlling camera remotely: pan, tilt, and zoom, which is the key part of the camera functions. And I also want to see internal in the menu and I want to display certain things while I'm looking at the images in my TMC, all right? So this extraction process—now we've got to walk through. We are suggesting that if we follow this three step process, and looking at those discussions, that we are having conformance group and then MIB. We read them in the standards and then we recognize what information they represent, each one of them. Conformance group presents the functions and the real functionality. The design-related functionality requirements are presented in the MIB. So we are recognizing this.

And then this is the difficult part. This is hard, but it can be done. And we have to look, see, actually infer by reading this and recognizing this, we are inferring “What is the major capability?” What does it do? So we are inferring. We are asking that question and we're thinking “Ah, this is what conformance group is about.” Ah, this is what this object is going to do. All right. So we are learning to infer after we are finished recognizing that, all right? And then we arrive at these two things: major desired capability, which is the user needs. It's a significant user need that you cannot miss. We want to make sure that our needs are met and that's the only way we're going to do that by inferring. And then the design, which is the object, right? Here's an example. Let's read 1205 CCTV. As I said earlier, there are four conformance groups that are present in the 1205, and here we need this one mandatory and the others are optional. So we are reading this. And you will be reading, too, just like we are reading it here, when you sit down to write operational specification for the acquisition process you're going to read these things. Then you're going to recognize and say “Well, what do they stand for?” By reading it and recognizing it, saying “Okay, this conformance group does that and this is where they are located.” And then finally you're going to go into them on their pages and say, “Okay, this is what it does.” All right. So we're walking away out of 70 objects and 12 different ways to look at it in the CCTV standard, we are walking away with some understanding as to what your project requires.

So let me start, again, with the emphasis on the inferring portion of the user needs. So this is a source of user needs. So where do they come from? Well, they come from the operational context. For example, we want to have CCTV functions to support traffic management in the region. That is our basis. That is where we are looking for a device to do that for us, right? So that's a good context. So now we say “Well, how am I going to use this device?” And then back off and then I say, “This is how I'm going to use it and therefore I want the following features.” So that's the connection we are making in all of our standards without SEP.

So let's look at this potential list that we create here and this is partial because everyone's needs are a little different here and there. But these four user needs do make sense because they are reflected here based on the operational context out there in the real world. For example, number one as you learned earlier, is mandatory. It's required by the standards, right? So that's the reason why it shows up here. Second, the DMC operator may need to control the features within the CCTV. That's also optional because a lot of people don't like that kind of additional features, you know? However, number three here, that is something that every one of us have seen it used. It's pan and tilt and zoom. You know we like to play with the camera. Also you need to do that because the incident scenario is changing and you want to zoom in and you want to still get more details on the scene. So that kind of capability is the user need. Now, you are buying 100 cameras. Maybe not all of them should be plan, tilt, and zoom. Somebody might say, “I only need 80 of them,“ right? So this is why we have to tell the specification with outlined what requirements you have in terms of pan, tilt, and zoom. And, again, there are internal camera discussions that you can have while you are looking at the pictures. And there are menus within the camera themselves that will show up on the image. Not everyone wants that because they are a distraction and everything. So user needs are collected or inferred, based on these expectations how they're going to be used. And sometimes they are written down in details as well, little more details than you normally find in the main line activities.

Here's the example of ASC. This is a little more complicated because ASC has close to like 35 different operational needs, user needs in the sense that there are 35 or so different conformance groups out there in the ASC, while you only had seven in CCTV. So the complexity of standards interpretation was also raised in the change. And then as you can see here in the ASC, it's a little more elaborate. So this list will allow us to look at operationally, see what's in the operation that will demand certain user needs, all right.

So here there are like 15 or so conformance groups outlined already and only two of them are mandatory. So those are the two mandatory required by the standards. The 1202 says you've got to at least meet these two and if you see A3, number one on the list here, phase conformance group is mandatory because that's where you're going to figure out how many phase traffic controllers you're going to need and everything else, right? So there are 2 to 255 in the object, as we discussed earlier, will come alive. You're going to say “I want an eight-phase traffic controller,” so your user needs is going to be eight-phase.

Well, how does the developer know? How does the vendor know? They don't unless you tell them in the user need that you want certain things. So here's the list that's made based on those conformance groups. So conformance groups have now lead us into somehow into mapping our user needs to conformance groups. So, for example, this number one user need, again, if you see that all ID numbers—right?—they're all unique. We learned that in today's process that we need to make sure how to write the user needs. Also, we have a unique name to each one of these user needs. These are also unique. So together they become a good source for standardization in the procurement, all right? And we can track them. And then this one suggests that these are highlighted two of them because they are mandatory, but no procurement should be without it.

Then we collect other things. For example, someone out there may be looking for an application, has an application in the project for preemption. You want to give priority to an emergency vehicle or fire engine, for example, right? So in that case for you, it's not an optional. You will be selecting and that will become mandatory in your user needs. So this user need will come alive in your procurement while in other procurements it may not be necessary, all right? This is how we build the user needs based on the non-SEP standards which is what ASC is. Here's an example. How do we write that particular user need? Well, look at the diagram here. Just submit this diagram so that you can look at it and relate that and say “Well, there are eight phases in this particular diagram: two here, two there.” And then I make up the whole intersection and I say “Eight phases are good enough for me in my procurement.” So when you write their user needs, you are saying that thing. This is how the description will occur. And it's mandatory, also because of the number of phases is necessary. So we will be saying two to eight phase, the combination you will be selecting, actually, the number which your project needs. All right. It has a unique ID number and that will remain. And that has a title, has a rationale in it, why we want it and everything else. So that's a good way to look at that. For CCTV: same thing. Here we are also saying unique ID title has a rationale in it. There's no design. We're not telling anybody how we're going to do it. So there's no solution in that, all right? So this is the requirement. This is the rationale. This is more detail in it. So this is how CCTV, which is also a non-SEP-based standard.

Now, look at the operational scenario. I mentioned that operational scenario tell us a lot of good things. While, here in this particular operational scenario, you have an incident that has occurred, and there is a need for the TMC operator to tell everybody what's going on. So the different needs are arising. So looking at the operational scenarios, we can tell the system developer that when I deal with such an operational scenario, I need the following type of information. One of them is incident sharing information with the motorist. That means displaying information on DMS, right? Providing warnings to public. Also, information to authorize other centers out there in the region. So in today's world, in operational scenarios, we don't live on the island anymore in terms of ideas application. So we have to share our information with a lot of other people and that's something that we will in writing user need.

Here's an example in terms of emergency management. These are different type of people involved, first responders in touch with now traffic managers or traffic management people. So TMC, the emergency management center. So the needs are suddenly changed in a different level. And we also require—we are required to write based on that full criteria that we mentioned earlier.

Now, acknowledging the risk. In this process of extraction and this is just one suggested process in this module. We are not saying this is the only way to do it. You know, you can create your own process based on what you learn today, but it suggests that there is a risk. Two different users may end up with two different interpretations or inferences. So anytime you infer, there is a self-created risk in there which you have to be aware of it.

So we should consciously or knowingly try to eliminate differences between the two users and make it to work because if you don't, the interoperability will be hurt. Remember, inoperability requires that both users think the user need is the same way. In other words, interoperability is delivered based on the common user needs, all right?

Then also, as I said, not all data elements that we need are present in the standards without SEP. All right. So we have to fill in the gap. Where there is no data concept available, we have to devise one. For example, dialogues are missing. In CCTV, there are no dialogues that we have. But in the DMS, we have dialogues. So for CCTV, we'll have to develop the dialogues and bring them into picture. So conformance groups also does another thing for us. It actually tells us whether the user needs are met or not met. So they're in the front, in the forward direction we look at and say “Let me check to see if this user need is dealt with.” So that we can do with the help of conformance groups. That's the only thing we have in non-SEP standards. For the SEP-based standards there are other mechanism of a level so we can use that. But here we are stuck with only conformance groups and we need to make the best use of that and that's what we are doing.

So in the forward direction, we check and see if the user need is met. And then I said, “Forward.” But I meant actually backward, in the backward direction. We meet user needs in that sense. Check it out. In the forward direction, we look at the design object because the design is after the user the needs and requirements. So this requirement column is done and then we look at the objects and see if these objects are properly lined up. We find these objects in the conformance groups. This is why this is a good tool. Even though non-SEP standards are not as helpful in reading. At least the conformance group helps us in that way. That we can actually read these objects and see if they are actually in the specification. So this is the traceability aspects using conformance groups.

How do we know the system we are getting is actually what we had expected? Now, validation is the process where user needs are used, again. So when we write the concept of operations, we write something in it which says that user needs will be used later on to check the system to see if it missed the user needs. Okay? So when we go to this validation state in this lifecycle process, we're going to go back and look at those user needs and say “Is the system that I'm getting is what I had asked for?” Or ask this question, both at the level of user, as well as the developer level, and say “Is the system built with user needs in mind?” And if the user need is met or not? So we are essentially saying, that having built the system with the right things in it, all right? And those right things in it are the user needs.

So this is a very organized way of declaring victory. We cannot go out saying our system looks good. It's doing two things. I can bring my menu up and I see other things: right and you are happy. But that's not how it's done in the real world. We need to go to each one of the user needs and check it out and see if that's done right. So that's the process of validation. That's another use of user needs in the system engineering process.

So let's see how we can summarize these things. What have we learned in going in today? We said that there are certain standards out there do not have SEP content. We know by saying that what we are saying is that there are no user needs in them and all of the other things are missing, right? So we have learned something today. What it is. So let's just summarize very quickly that when user needs do not already exist, we have to develop them. So the process is discovering and developing that we recognize, that's what we learned, right? We don't have to ask questions. Where can I find user needs? We know now that we'll have to develop them, right?

Second thing that user needs are a first step towards achieving interoperability. You know, if you don't have user needs in there, in the specification, interoperability is very hard to find. Also, the interchangeability. We mentioned that vendor independence is a very important aspect. And both are served well. With this first step, user needs creates them. So user needs are a first step towards interoperability and interchangeability. Also, user needs can be found in concept of operations plans. We know that they are there. We will make extra hard to look for them, all right? And I'm sure if we try very hard, we'll find them in the description of concept of operations documents.

Also, using this can be derived from operational scenarios. These are the real world things that are actually happening out there, you know. And they are telling us how things actually work out if we follow certain matter and process. So they are part of the concept of operations. So if we devise the project, we know that our operational scenarios will tend to it, how projects are going to unfold and how the system actually is going to be utilized. Then we are coming to a situation for non-SEP based standard structure. It's about—I learned today that they do have conformance groups in there. I heard conversation before, but now today's module is really telling me that conformance groups are actually a key part of standards without SEP content. So we recognize that. Then we learn also that the standards have management information base.

So summary five here is telling us that both conformance group and management information base together is the structure that I learn about today on non-SEP standards. And several examples of ASC, as well as CCTV, tells us that all they have in them is conformance groups and MIBs. Then we have learned that the course has told us that we can read the standard. We can recognize the information in it. And the extraction process allows us to infer and then write. So this fourth step is what we learned. So this is a suggestion extraction process. But you can make your own along the way. And I'm sure a lot of you will take that challenge and work around it, right?

So now, we have user needs must be written. But how should they be written? Well, we learned today that there is a specific criteria we need to follow, all right? First, each user need must be uniquely identifiable. We must have a title and an ID number, right? It has to have an MDC in it - major desired capability. It should reflect what the feature or function is going to be and that must be reflected in the user need. Also, it must capture a rationale. Everyone who reads the user need should know why that user need exists. That's the rationale. We need to provide that, all right? And that's for everyone's benefit, not just the user's benefit. But whoever reads it is going to make sure to say “Yeah, I know now, why this user need is present.”

Finally, it should be solution free - no design in it. Leave that to the requirement analysis and then the development process. That's why those processes are designed for. At the level of user needs, we are simply writing it and it has to be solution-free.

Finally, we are going to use it to verify, whether the user need is verified, whether the system is validated with the user needs. So every user need that we run in the specification we're going to make sure that it's validated against what we are getting system. So what we are saying here at the system outcome, is validated against the user needs, all right? We will check every user need to see if it's met. So the next module will deal with requirements portion of the discussion.

Today we dealt with user needs but the next module, A203, is going to discuss the requirement portion of these requirements in the deployment process. So what are the requirements? How are they going to be handled? And how are they going to be developed? And what should be in them and what should not be there? Also, the writing process. So all of these things you're going to learn in A203.

Then in the supplement, you have the learning objective-related information. Again, there's additional information. You can look at it in your leisure time. And that's also the list of references in there. At least four good references that I will mention here that you should make an attempt to consult. There's a handbook on system engineering published by FHWA. That actually guides us on how to develop an ideas project.

NTCIP Guide has a lot of information - both devices and system related. There is a traffic management data dictionary. Also, it is based on SEP, but it also tells you how that standard is handling user needs so that's a learning process. Also, 1512 Implementation Guide, which is without SEP. Therefore, it doesn't have user needs in them. But the guide actually tells us how to create user needs. So this document is also good for 1512. So that's a very useful document.

So if you have any questions now, let me have any questions that you might have and I'll be very happy to answer that. Any questions that you might have? All right. While you think about the questions, let me have my own three questions that I came up with and please think about your own if you are still thinking. In the meantime, let me just deal with these three.

What is the difference between compliance and conformance?
And I will answer that very quickly, saying that compliance is a requirement of you, the user, the people who are conducting acquisition process, right? There are a bunch of things that you need. But conformance pays attention to what the standards is saying. Conformance says that to conform to that particular standard you require this. So all of the mandatory things that a standard has outlined must be conformed to. So that's a difference. One deals with the users' needs and compliance and the other one reads the mandatory requirements that standard is imposing.

The second question, what is the difference between the validation and verification process?
Well, we just finished talking about validation using user needs. User needs tells us whether we have the system do the right things, that the user asked for. And the verification says if we build the system right, were all of the requirements that were asked in the specification, have they been met? And that will be done through verification, all right? So both of them together will make sure that every need and every requirement is completed at the proper stage.

Will there be a training course on CCTV and ASC?
And I talked today a lot about CCTV and ASC in the sense that they don't have user needs. And they don't have requirements. The only thing they have is design in them. So now the next module in the second year PCB program are going to be—those modules will be dealing with this subject and actually teach us how to go about doing these things for those particular devices and that is what is expected.

So in the absence of you having any further questions, I'll ask you one more time, see if you have any questions. Please go ahead and put it in the chat room and I'll just wait for a moment. Any questions? All right. Well, if there are no further questions, I would like to thank you for attending today's...