Module 3 - A102

A102: Introduction to User Needs Identification

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 them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems.

I am 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 (ITE), 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 you.

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 for participating and we hope you find this module helpful.

Moderator Nicola Tavares
Welcome to Module A102: Introduction to User Needs Identification. The target audience for this module are: project managers, decision makers, operators, transportation management center staff, and stakeholders. Your instructor is Tomas Guerra, President of Oz Engineering, and he has over 18 years of service in the Intelligence Transportation Systems Industry.

Tomas Guerra
Thank you Nicola. Welcome everyone. This is Module A102: Introduction to User Needs Identification. Recommended prerequisites for this module include I101: Using ITS Standards and Overview, which highlights the benefits and costs of adopting a system using the ITS standards, as well as Module A101, which is an introduction to acquiring ITS systems by means of the Systems Engineering Process (SEP). It would also be helpful if you are familiar with intelligent transportation systems, government procurement processes, and the Systems Engineering Process in general, which we will talk about in this webinar. ITS standards are basically organized into two general areas. One are those standards that contain SEP or Systems Engineering Process content. And the other one those standards that do not contain SEP, Systems Engineering Process, content. This diagram shows you the curriculum path that you would follow if you were interested in learning about those standards that have SEP content. As we'll discuss in a little while, SEP allows you to describe well-defined needs requirements, come up with a design to develop a system in a very methodical fashion. It focuses on defining customer needs and then making sure that those needs are met by the implemented system. If you are interested in those standards that have SEP content, this would be the curriculum path that you would follow. And as you can see, this module A102 is on that path.

This slide shows the curriculum path that you could follow if you were interested in learning about those standards that do not have SEP content. As you can tell, some modules exist in both of the curriculum paths. For example, A102 is also on this path as it provides basic information that is needed regardless of whether you want a standard with SEP or not SEP content. The learning objectives of our module are to identify user needs, know which standards contain SEP content, and give you some guidance in terms of how to select those user needs from these standards. So we'd like to start off this morning just to ask a quick question here by raising your hands on your computer by pressing on the raise your hands button. How many of you have acquired or implemented an ITS system? Go ahead. We'll pause for a few seconds just to see how the group is made up.

Very good. Some of you I would say, not many, but some of you, have acquired ITS systems. So this is a good class to have. For those of you who have not, because hopefully, we will be providing you with some information on how to do it and develop your user needs. For those of you who did acquire an ITS system, and actually for everybody online, I would like to go ahead and initiate an online poll here and the question of the poll is: did you follow the Systems Engineering Process when you implemented the ITS system? So what I'm going to do right now is I'm going to launch the poll and you will be able to select yes or no. Did you follow the Systems Engineering Process when you acquired or implemented an ITS system? If you would please answer that question we'll pause for a few more seconds to give other people an opportunity to respond.

Very good. I'm going to close the poll and I'm going to share the poll results. And 57 percent of the respondents said that they, yes, they did follow the Systems Engineering Process. 43 percent said no, they did not follow the systems engineering process. Okay, so what the intent of this webinar is, as I said before, to help you to identify user needs and in particular, how to identify user needs from ITS standards that have undergone the systems engineering process. Since many of you did not follow the SEP process, hopefully, by the course of this webinar, you will see the benefits of following this process when implementing an ITS system. Okay. What I'd like you to do now is, in your chat pod, I would like you to answer this question: Do you know what a user need is? If you have an idea, any guess would do. Please type it in and we can then discuss some of these thoughts and then learn the formal definition of what a user need is.

Okay. A user need basically and informally describes the major capability provided by a system. That is, a user need is what the user wants a system to do. So we had some answers on the chat pod. For example, a user need is something that will fill in the void of an existing system. A user need is receive real-time traffic information. Receive highway congestion information. So these were some of the responses provided on the chat pod and basically they fit this overall general description of a user need. It is a capability that we want, that the user wants a system to provide. Another thing to remember about user needs is that they help us to determine if the system does what it is supposed to. They help us to validate or assess or test whether the system does what the user wants it to do.

Now, as most things with the ITS standards, there is a formal definition of a user need. And the formal definition of a user need is provided by the Institute of Electrical and Electronics Engineers (IEEE) in the Standard 1362. When they indicate that a user requirement for a system that a user believes would solve a problem experienced by the user. So as we have just said, it's a requirement or a need of a system that would solve a problem that the user wants it to solve. Pretty open-ended in terms of a definition of a user need. The next statement clears it up a little bit by saying that it's a set of qualitative and quantitative user needs in a particular problem domain.

Now, on the screen, the quote itself uses the word requirement. It's a user requirement for a system but it is actually intended to mean it is a user need for a system. And as we go along in the webinar, we'll see the difference between a user need and a requirement. Alright, I'm gonna ask you to type into the chat pod an answer to the question of who establishes a user need. So we know that the user need basically describes major functionality or capability that we want a system to do. Who establishes these things? Who comes up with these user needs? Okay, we'll pause for a few seconds.

The user. Excellent. Stakeholders. Excellent. That is a key word that we are going to be using here in the webinar is a stakeholder and as we can see a stakeholder is anyone who has a stake in the implementation, operation, or maintenance of a system. On the slide, we have examples of some people who are stakeholders. Who may be considered stakeholders? All the way from the system purchaser or the project manager, up at the top of the list. People in planning or design, certainly operations maintenance and operational support are stakeholders. Because they are the ones who will be using the system so you would certainly want their input at the point of determining what the system needs to do when you're coming up with your user needs. Then, as you get farther down the list, you have examples of stakeholders that may not have a say in the feature set. For example, other regional partners, other sponsors, politicians, regulators, and the public. These people at the bottom of this list may not have a direct say in the features that your system does but certainly you may want to keep them informed of your system and what's happening there. Especially if you're going to be debuting a system that puts information on a dynamic message sign and you would certainly wanna prepare the public for that before it actually happens.

Just by a quick show of hands, how many of you have participated as stakeholders before in an implementation of a system? How many of you have been asked to provide input in terms of what a user need is? Yes. Good. It's a majority of you and that is to be expected. Okay, when you get a group of stakeholders and you get them together to come up with a list of user needs for a system, you have to ask yourself where do they derive these user needs. So, at this point on the chat pod, if you would type in examples of where you think a stakeholder group may be able to derive user needs from.

Okay. Some examples of places where you may derive user needs are a regional architecture. Now what I'm going to do here is just briefly describe what a regional architecture is required for ITS project funding. It's part of Rule 940 and any ITS project should demonstrate where it fits into the regional architecture as part of the systems engineering analysis process. So a place where we would derive a user need is in an existing regional architecture. Typically, most regions around the country have a regional architecture and there is a national architecture as well. Case studies is another place where we can derive user needs. These are lessons learned, formal reports that have been prepared and posted online from other agencies that have implemented ITS systems. They indicate the lessons that they learned and how their system eventually was implemented.

You can also learn by seeing what other systems have done. Typically, when an ITS system is deployed and it follows the systems engineering process, it will prepare a concept of operations: a document that describes how the system is to operate from the perspective of the user. So that's a good place to get information about user needs. Certainly, you wanna have workshops and perform interviews with the stakeholders and other people outside of the stakeholders group. And lastly, and what is the focus of this webinar is you can go to those standards that have SEP content and you can extract your own user needs from those standards and we're going to see how we do that in this webinar.

Now, one question you may ask is: I've been saying the word user need about 80 times so far; why are we focusing on this? Okay, why do we really care? Well, as I stated previously, if we don't know what the user wants or if the user doesn't know what they want, then how will we get the system that they need? Right. So it helps to establish what you want the system to do and it is critical in trying to implement or buy a successful system. The other feature of a user need is that it tends to remain stable over time. In other words, if it is a true user need, it is something that is long-lasting in terms of I need this. It's a long-lasting need and by selecting user needs or defining them properly, you avoid potential scope creep. That is adding features and functions as the implementation is being made that all of a sudden could make your system more expensive than you intended for it to be. So, because user needs are stable in terms of they don't change over time, and because they help you to determine whether you got what you wanted, that is why we're spending a lot of time on this. And that's why they are important to the successful implementation of systems in general, ITS systems in particular.

By a show of hands, how many of you have seen this famous V diagram, which documents the systems engineering process? And, as would be expected, most of you have seen this before. That's good. We're gonna spend a couple of minutes here talking about this diagram and how the systems engineering process works. As you can see on the left side, we start with the needs analysis or the user needs section. Regional architectures may exist. Typically, you have one for a region and nationally. It then could lead to a concept exploration or a feasibility study and if you decide that, yes, you want to implement a particular project, ITS project, you would wanna come up with a concept of operations if you're following the systems engineering process. As I mentioned previously, the concepts of operations describes a proposed system from the user's perspective.

It tells the engineers and the designers and the implementers down the line how, from the user's perspective, the system should work. After the concept of operations, you use the concept of operations to then define the system requirements, which is the next step along the V diagram here. Okay, so the user needs lead into the systems requirements. Once you have established those, you would then establish the high level design of the system. Go farther and farther down into the design of the system, continuing with a detailed design. And then at the bottom of the V, you go ahead and procure or develop your software, your hardware, and your implementation. Then as you work your way back up the V, you now validate how your system was implemented and how it met the needs of the users. And as you work your way up the V, first you start with testing the different units.

They have a correspondence here with a detailed design, so unit tests basically test whether you have performed what the detailed design asked you to do. You move up the V, subsystem verification confirms that the high level design has been met. System verification here matches with the system requirements. And then system validation at the top assesses or validates whether the concept of operations or the user needs have been met. Okay, we then enter the phase of operations and maintenance. Followed by any changes or upgrades to the system and then finally you may retire or replace a system, or as happens in the real world you evolve a system, add enhancements, make it a little better as time goes on. Now as I said before, user needs tend to be stable over the course of time. But there is a place where it makes sense to reassess your user needs and this is typically after you've been operating and maintaining a system for a long time. In a long-lived system you'll want to, on occasion, go back and say: “Hey, do we have any new needs? Do we wanna modify the needs that we originally designed?” And then you would go back to the concept of operations, potentially redefine those things, and then follow the entire systems engineering process again.

As we've likely learned from the other webinars, the benefits of the systems engineering process are that they allow you define very specifically what your system is going to do upfront, so that you learn right away what the details of what it is you're going to implement, which then will reduce the potential problems you would see down the line at implementation. Additionally, by following this process, you're sure to have captured the user needs that appear and those needs would have been reflected here into the requirements. An important thing to keep in mind is that user needs are all about the user. They are focused on what the user wants. Requirements, on the other hand, which are down over here, are intended more for the system implementers, the system developers.

For them to do what they need to do in their code to implement the system. So that's the critical distinction between a user need versus a system requirement. The user need is intended to reflect what the user wants. A requirement is intended to guide the implementers in the implementation of the system. Now that we've gone through the V diagram, I'd like to basically provide you with the criteria that we use to judge whether a user need is a well written user need or not. There are four criteria that have been established in terms of assessing a user need. The first one is that the user need must be uniquely identifiable. You need to give it a unique number and a unique title so that you can refer to it without ambiguity. At the bottom of the slide we have a table here and the first two columns are user need ID and title.

Next, a user need must describe a Major Desired Capability. It should express what it is you want your system to do and that should be irrespective of whether you have that capability now or you want it in the future or what have you okay. So it's uniquely identifiable. It describes a major need. It is Solution Free, and by this we mean that we're not telling the implementer how to implement their system but we are telling them what we want that system to do. So a user need must tell them what we want it to do, not how we want them to do it. It must be Solution Free. In other words, it must not provide the answer for them. Let the designers deal with how something is to be done. And then the fourth criteria is a user need that is well written captures the rational from the user's perspective. Why is this capability needed? Why do we want to include this into the system?

These are the four criteria we're gonna spend a little bit of time throughout this seminar talking about: these four criteria and assessing whether they have been implemented correctly. There are many examples online on various ITS websites where you can go and look for other implementations of ITS systems. In this slide, I've captured an implementation that was done by the city of Minneapolis. They are upgrading their traffic management center and they were performing ITS enhancements. It was done in 2008, and when they started that project, they created a concept of operations document and this is an excerpt from that document. Within that document, they had a table that captured the user needs and this is a portion of that table and as you can see, the four criteria that we just described are met. Let's look at this one here, user need number 13: stakeholders agreed that there's a gap in sharing cameras to monitor real-time traffic among agencies.

So this is the rational of why this need is request. That need being to improve the capability to share surveillance cameras between the city and related stakeholders. So the user need is number 13: it's here and in the next column you have operational scenarios. So in their concepts of operations document, they actually came up with different scenarios of how the system is to work in different environments. So if we look at this again, it's uniquely identifiable. One thing that I would say, though, is that this need doesn't have a title and that's one place where this might be improved upon. But it does capture the Major Desired Capability, it is Solution Free, and it captures the rational of why this need is important to us as users.

Conversely, we can try to understand what makes a poorly written user need. What criteria would a poorly user need be lacking? And so some examples: the first one is that you specify a capability that you really don't need. You're asking for something that you would want down the line but it's not really a need. So you have to ask yourself: if you remove this need, will my system still do what I need it to do? Another thing that people do when they're writing user needs that is poor is that it is not Solution Free. For example, you're saying: “Oh, I want vendor XYZ or technology ABC when I implement this particular need.” As I mentioned before, we want to let the designers have the flexibility to select how they will implement the solution. Your job when coming up with user needs is to tell them what you want the system to do. And another way you can go awry in terms of writing a user need is you can be vague. When you're vague, it makes it difficult to determine if you got what you were asking for and we're gonna go through some examples of these momentarily.

We're gonna take an online poll here and we're gonna look at this example that I have on the screen. I'm going to go ahead and launch this poll. The user need was 845: the system needs to manage lean control signals and note there are no lean control signals deployed in this region. That's the user need that was written by somebody. It has 845 the system needs to manage lean control signals. But the important thing to keep in mind is that there are no lean control signals in the region where that need was developed. So what I'd like you to do now is look at this poll that is online and I'd like you to select which of the following criteria was violated by that user need. Was it not uniquely identifiable? Did it not provide a Major Desired Capability? Was it not Solution Free? Or did it not capture the rational? I'm going to close the poll and I'm going to share it with you now.

And basically, we can see that most of you feel that this user need did not describe a Major Desired Capability. I think I would agree in that it is vague. So it's kind of, let me go ahead and close out the poll. From my perspective, the user need, oops, let me go back. Okay, the key that I was trying to convey in this description was that the user need asked you to implement a lean control signal but there are no lean control signals deployed in the region. In other words, the rational that you asked for is flawed. You're asking for something that you don't have a need for. That was what I was trying to do and it was a little, it can be basically wrapped up in the fact that it did not describe a Major Desired Capability that you really need.

It was Solution Free in that it didn't tell you how to implement the lean control signal. It didn't really capture the rational; it didn't say why you would want it. It was uniquely identifiable. 8.4.5 was intended to be the user need ID number that was assigned to this user need. Alright, let's go through another example. This is another example of a user need that I've made up and I believe this is a poorly written user need. It's 12.7. And it says that the dynamic message sign DMS needs to be NTIC compliant so that it may be procured from various vendors. So what I would like you to do when I launch the poll is I would like you to tell me which of the four criteria is violated by this user need. Uniquely identifiable, Major Desired Capability, Solution Free, or does it not capture the rational of what you need? Alright, let me go ahead and launch the poll.

And I'll give you a few seconds to answer what you think. Which criteria in this poll, in this user need, was not met? Very good. I'm going to close the poll in a few seconds here. Five more seconds. Very good. I'm going to share the results of the poll, and as you can see, a majority of you felt that the problem with this user need is that it is not Solution Free. It tells them what you want to do and this is kind of a trick question and let me go back to this. Because I'm trying to make a couple of points here. Firstly, yes I'm telling them to be NTIC compliant, but in a certain respect, that is something good, right? We want them to follow the ITS standards but the problem with this statement as I see it is that it is too vague. What does it mean to be NTIC compliant? I mean, there are literally hundreds of different needs within that standard. For example, I want to monitor the fuel level at the sign, or I want to get back the revolutions per minute from the engine that is the backup power to a sign. Now most people, when they procure a sign, are not looking for something that has a backup motor with gasoline in it. So by saying that you want something to be NTIC compliant, it's very vague and if you tried to implement everything that is in a particular standard you couldn't afford it. It would be cost-prohibitive.

So in my opinion, it was the rational was flawed. We expressed this thing incorrectly so it's not Solution Free and the rational is flawed. So let's go ahead now and let's look at the actual standards that we have in the ITS industry that have SEP content. So these standards basically have undergone the process in the V diagram and you can use these standards to help develop your own user needs and we're going to go through a couple examples of doing that momentarily. Here, let's just take a look at how they are organized. The first six of these standards are considered C2F, that means Center to Field, and they correspond to NTCIP, the National Transportation Communications for ITS Protocol. So basically there's definitions of different protocols for a center to communicate to different types of fuel devices. And as you look down the list, they include dynamic message sign, environmental sensors, transportation sensors, field master stations, signal control and prioritization, and electrical and management systems. We'll touch base on each of these as we go through the webinar.

The bottom two standards are in the C2C category, or Center to Center category: Traffic Management Data Dictionary, which allows centers to control each other's devices. When you look at a standard that has undergone the SEP process as we saw in the V diagram, it basically will follow a very structured approach and it will have some very well defined and established things. For example, it will have a concept of operations section in it, or a user needs section near the beginning of that standard. It will also have a requirements section that will list the requirements that are to be implemented within this standard followed by a design section. Another critical component that is very useful from a user needs perspective is this Needs to Requirements Traceability Matrix, NRTM. Every one of the standards that were in the previous slides has one of these tables or matrices in it. The C2F standards, which are the first six of them, they don't call it NRTM; they call it PRL: Protocol Requirements List. It's essentially the same thing as a Requirements Traceability Matrix and what that is, is it shows you how you get from one user need to a resulting one or more requirements. And we'll look at a couple examples of that momentarily.

Lastly, a standard that has gone through the SEP process will have a Requirements Traceability Matrix within it as well. It will show you how the requirements have been implemented, how they have been met. So let's start by looking at one of the standards and going through it and seeing how we would be able to extract user needs from it. The standard that we will be looking at is the TMDD standard. It has SEP content as I mentioned, and it defines information flows between centers so that you can control cameras and dynamic message signs. You can enter incidents and other types of information. We would expect that it would have an NRTM in it and a Requirements Traceability Matrix as well. This particular standard works well with modern XML communications protocols. And it also comes with a guide that has a very well defined user needs discussion section. So where would we find this standard? On the slide, it shows you the specific location of this standard and it is on the ITE website. In there, you'll see that it comes in two volumes and the little shopping cart on the right is how you would download that standard. It's a PDF file and you could look at it.

So let's go ahead and take a look at that standard and see what the table of contents contains. Section 2, as you can see on the slide, is the concept of operations portion of the standard. It has a definition of the users, who were the stakeholders that were in mind when this standard was developed. Section 2.3 is where the needs begin, and they go all the way to basically page 33, as you can tell from the table of contents there. Section 3 is the requirements, so it lists all the requirements from the implementer's perspective that need to be fulfilled for a system to be TMDD-compliant. Let's keep going down the table of contents. Section 4 in the table of contents of this standard has a traceability to the national architecture. Remember when I showed you the V diagram? I advised you that it is a requirement that all ITS project funding. Let me say this again, regional architectures are required for ITS project funding and your project needs to demonstrate where it fits within a regional architecture. So in the case of the TMDD, it shows us where it fits within the context of the national ITS architecture. That's section 4.

Section 5 is the NRTM, the Needs to Requirements Traceability Matrix. So it shows us the user needs and then how one or more requirements implement that user need. So by looking at the table of contents, you can tell right away whether a standard has undergone the SEP process because it is organized in a well-established manner. So now let's take a look at an example user need from the TMDD. In this case, the user need is 23644: need to display a message on a remote DMS. Centers need to request that a specific message be displayed on a DMS controlled by another center. So that's the description of the user need and following here is a description of the rationale behind that need. And what they want is one center to be able to send a request to a different center to put a message on their sign. Then the other center tells the original center whether that request was implemented, queued, or rejected. So this is the nature of the types of needs that are in the TMDD.

Does it meet the four criteria that establish a well written user need? Is it uniquely identifiable? Yes, you can see the number and the title at the top, 23644. Does it express a Major Desired Capability? Yes, a center needs to be able to request that another sign for another center be controlled. Is it Solution Free? Yes, it doesn't tell us how we do this; it just tells us what we want to do. And it provides plenty of rationale about why we want this to be the case: why this need is important to me as a user. One thing I will mention cause when I first saw this I thought—you know what we're telling them what to do here? By saying that we want the messages to be free from text or in multistring format, MULTI, M U L T I is a protocol where you can describe how the text is to be displayed on a sign. It contains whether the letters should be bold, etc., that MULTI is defined in another NTCIP standard and so TMDD is basically referring to another standard in its implementation. When I first looked at that I thought, “Oh are we telling them what to do?” But I think, in hindsight, no, we're not – yes, we are but for a good reason. We're telling them to be MULTI string compatible because that is the NTCIP standard. Table 4 within the TMDD requirements document is the Needs to Requirements Traceability Matrix and as you can see on the left side, we have the user need we just looked at: 23644. This is the title. Over here are the lists of those requirements that fulfill this user need and a brief description of those requirements. This conformance column tells us in order to be compliant with the standard this requirement is either mandatory, M, or optional, O. So a vendor may choose to implement only mandatory requirements or a combination of mandatory and optional.

The next column, which is a support column, basically is for you to say in my implementation of a center to center system, do I want this requirement to be implemented. So you would say yes or no and you have a place there for generating a column. So at this point, it kinda makes sense to ask the question well, I'm gonna come up with a system that I need to implement. So where do I learn? Where do I develop the user needs list? And as we talked about before, we can do interviews with the users, we have our stakeholders. We get them together. But we know that we wanna communicate from one center to another, so it makes sense for me to go to the TMDD standard and see what I can take from it.

Some people say well, we should start with the standard. Some people say well, we should start with our own user needs and then compare it with the standard. In the end, as long as you've had an opportunity to look at both, that really means you've covered your bases. One question was without seeing the whole publication of the TMDD, it has all kinds of needs in it. Yes, it does, and so how would we go about finding or choosing the need that best matches what we're looking for? And frankly, there is no easy answer for that. You need to look at the standard and go through it. It is in PDF so you can do word searches. So the way I look at it is first, I need to establish what kind of system I'm looking for and is there a relevant standard that deals with the system that I want. So for DMS, we know that there is a NTCIP standard for DMS's as well as for environmental sensors. Then you go through the standard. You go through the user needs section or the NRTM and just work your way down that list. You can potentially look for keywords but there's nothing easy about it and frankly, if you want to prepare a good set of user needs, it really is not an easy process. It's a thorough process requiring a lot of discussion, a lot of research, a lot of dialog with your stakeholders. But the benefits of spending that time up front to establish in writing what you want your system to do. The benefits of doing that are that you are likely to get the system that you want in the budget that you have. And as we saw in one of the early slides where I showed you the different curriculum paths, the SEP standard curriculum paths, there is another module that goes into more detail on this TMDD standard. It's Module A321A and it goes into more detail. How you would go ahead and extract your user needs and requirements from an NRTM. One thing to remember as we're doing this is, and as we said in one of the examples that I gave you, we don't wanna just say well, my system must be TMDD compliant. Right? 'Cause that's vague and it's untestable and no one has the money to implement such a thing.

So you really wanna go in there and say what is this need, something that I need in my system. Here, let's go through another example here. This example is gonna use NTCIP Standard 1203, which deals with dynamic message signs, DMS. At a high level, we can see the table of contents or how this standard is organized. It has a concept of operations, it has functional requirements. As I mentioned before in all the center-to-field standards, they don't call it an NRTM. They call it a PRL: a protocol requirements list. It's the requirements of the protocol because these are essentially communications-related standards. The next section, which is dialog specifications, these dialogs define the standardized procedure which devices and systems use to communicate with each other. The management information base define the data be exchanged during the communications, MULTI. I mentioned it earlier is the markup language for transportation information.

And it defines the tags that may be used within a message to be displayed and it also has a Requirements Traceability Matrix as an annex to the standard. Where do you find this standard? Well it's a NTCIP standard so it would be on the NTCIP website and you can see that on the screen. Now, at the top of that page you'll see 1203, which is the standard in question and you see a little shopping cart on the right which is what you would use to download the standard. One of the things that I want to mention at this point is that ITS standards in general, and this one in specific, has one or more versions of it. At this time, the official approved version, the jointly approved version, is Version 1, and that's the one that you would get by pressing on the little shopping cart. But the recommended version is Version 2. Version 2 is the version that has the SEP content. It is on the same website, but it is at the bottom of the webpage, and you would download it by clicking a link at the bottom of the page. Additionally, when you go looking for standards and the whole standards documentation websites, you'll notice there's a lot of other supporting documentation and resources. For example, 9002, which is a case study for the Virginia DOT implementing the NTCIP. There's another document available online for Washington State DOT, a case study on their implementation of dynamic message signs. So there's a lot of other resources that you can make use off and would be beneficial and helpful to you as you are trying to describe your system and what you want it to do. I've mentioned already here that there are two versions of the DMS standard: 1 and 2, and version 2 is the one that you would want to use. That's the one at the bottom.

Let's take a look at a specific example within this standard 1203 dynamic message sign standard, Version 2. And one of them would be 2531, perform diagnostics. This feature enables the operator to test the operational status of the system components, so that is a user need. Another user need within this standard would be monitor fuel level. That's 253113. This feature enables the operator to monitor the level of fuel within the tank of a generator if it is being operated. That helps to operate the DMS. It is typically for portable signs. Are these user needs well written? Well let's look at the four criteria that we established here.

Are they uniquely identifiable? Yes. Both of them are. They have a unique number and title. Do they describe a major desired capability? Yes. Are they solution free? Yes. We're not saying how to do it; we're just saying that we need to do this, what we need to do. And do they provide the rationale? In the little snippet that I have here, you don't get a flavor of the rationale why we're doing what we're doing. But within the standard itself, the rationale is very fully documented. So this is a well written user need. These are well written user needs. If we take a quick look at the protocol requirements list, or NRTM, we see that we have a list of user needs on the left. And then once again, followed by a list of the requirements, functional requirements, whether they're mandatory or optional. Perhaps a place for you to indicate in your project whether you chose to implement this or not and a place for you to provide additional comments here in the PRL.

I've had a question that asked: are there any conflicts between Version 1 and Version 2 of this standard? And the answer would be no. Basically, Version 2, as I understand it, was basically supplementing the original standard and making it SEP compliant. Organizing so that it will be in the expected manner with the concept of operations and everything else in there. So it's an enhancement of the original standard by putting it in a fashion that we can use and take advantage of. So there is no conflict between the two standards. But certainly if you're looking for a DMS system, make sure you use the proper version. So we can say that if we want to deploy our own system, we wanna describe the user needs so we can say what features, functions, capabilities our system needs to have from the perspective of the user. So one way you can do it, as we've seen, is to have a little table, where you have a user needs IDs, titles, a description, and some rationale.

And you can use your user need as a starting point and then go refer to the ITS standards to make sure you haven't missed something or you can start with the standard and then go to your own list of user needs. In reality, you'll probably do both. It's a cyclical process where you'll learn and you'll talk to people. You'll interview, you'll develop, you'll document, and in the end you'll come up with something, hopefully a system that does what the users want it to do and for the price that you have in your budget. There is a resource online. It's an early deployment project implemented by the Virginia DOT and the Virginia Technical Transportation Institute FHWA in trebalon. It was performed as an early deployment test in 2007 and basically, they followed the Systems Engineering Process to see how well you could get two different systems from two different vendors to communicate with each other using the ITS standards. And the demonstrated value of having gone through the Systems Engineering Process was that first word, traceability, you could quickly identify what you wanted the system to do and if there were any problems you could say well, that's the problem right there. That requirement, or that need is not met. But in the process of going through the Systems Engineering Process, SEP, you built a consensus everyone was able to see what the requirements, what the need and the design were.

It was in writing; there were no hidden requirements or needs. And so once you have this, you can decide okay, there's the problem. You can assign it to an individual or group or vendor that needs to correct it. They can resolve it. You can then accept the product, right? By performing your tests that will go from unit, to subsystem, to system tests and by having everything in a very methodical and organized fashion, you can avoid conflict and legal issues. And this is a good example of why going through the SEP process is beneficial. But in addition, and the real reason for this module, is to tell you that there are resources out there that you can refer to, ITS standards that have already gone through the SEP process, that you can use to your benefit when implementing your system.

Once again, as we saw from the curriculum path, there is an additional module, A311A, that goes into more detail on the NTCIP 1203 standard for dynamic message sign systems. It will go into each of the protocol requirements list in a lot more detail. How to select user needs and requirements from that point so if you're interested in dynamic message signs and that standard, this is the module for you. A question that was asked: should we always use the highest version number? That's a great question, and I think you need to assess what that version number means. In other words, is it a recommended version? Is it an approved version? Is it just a working draft version? I think that you need to understand what the status of that highest version is and then decide for yourself if you want to use it. For example, if it's a recommended standard as is the case with 1203, I would have no hesitations in going to Version 2. Because that's where the future is okay.

But if there's another standard that's a work in process, you know you might wanna learn a little bit more about. Is this where we're really going, or is it subject to significant change in a new release? The people who develop the standards, the standards development organizations, are very good in terms of sharing what they know about a standard and where it is headed, so certainly you want to communicate with them to assess for yourself the proper version number to be referring to. But from the perspective of our webinar, we're interested in those standards that have gone through the Systems Engineering Process and so certainly you wanna go to the version that has that process documented within it. It makes our job easier.

So as I mentioned, there were eight standards that had gone through the SEP process, and so we're gonna briefly touch upon the other standards that are there just so you have a sense of what kind of things are contained within those standards. So 1204 is the environmental sensor station interface standard, ESS. So a couple of needs here: 25211 monitor atmospheric pressure, 25212 monitor the winds. So this standard is basically about world weather information systems and the features and requirements of that type of system. NTCIP 1209 is about transportation sensor systems. They provide information about traffic flow. So, for example, a user need is 2.54, collect data from TSS, and you can have different sub-features within there. You can retrieve the data as it is in progress, or give me the data after it's completed something in the field, or give me historical data. So these are the kinds of things that are encapsulated within this standard, described within this standard about getting traffic flow information from field devices. That's the standard for you if you're interested in that. NTCIP 1210 has to do with field master stations and basically this is about how signal systems masters communicate with the local traffic signals and coordinate between the two of them. Setting up different thresholds, the user need that I captured here, 251, is configure traffic responsive mode. So basically, this is a need to operate a traffic response, operate a traffic signal in a traffic responsive mode, and how to establish different thresholds for doing that.

So if you're interested in signal masters and locals, this is the standard for you. NTCIP 1211 has to do with signal control and prioritization. It is about, for example, allowing emergency vehicles to go through the traffic signal systems at a higher, a preemption, or a higher priority than normal traffic. You may also want to allow transit vehicles or light rail to move more freely through your traffic signal system. This standard defines the different objects that are needed to do signal control and prioritization interaction with your traffic signal system. The example that I captured here is configuring re-service periods. So you would tell it how often it should try to allow a preemption or a priority request to be fulfilled. You don't wanna fulfill necessarily every request especially if there's one coming every 10 seconds. So anyway, this standard, 1211, is about signal control and prioritization.

The last of the NTCIP standards with SEP content is the ELMS standard, electrical and lighting management system. And this standard has to do with communications with highway lighting equipment and using this communications to basically monitor it, control it, put it on schedules, and integrate with these field devices, electric and lighting field devices. So the one user need that I captured here, 24129, provide periodic power meter measurement logging. So the need is to provide us with the feature to keep a local log of voltage, current power, and energy and then allow us to upload it. So if you're interested in controlling the lighting and management, if you're interested in controlling the electrical systems out on the highway, this standard would be for you. And finally, the last standard that we're gonna mention today that has SEP content is the NTCIP 2306, center-to-center XML standard, and basically, it allows transportation agencies and centers to specify communications interfaces using XML. So one need 2.1 is message encoding privacy, this profile needs a mechanism to allow messages to be privately transmitted over the internet and other shared networks. So that's the standard there.

So we've looked at the different standards that have SEP content. Well, there's a group of other standards that do not have SEP content and I've listed these standards here. Some of these are center-to-field standards, some of these are center-to-center standards, and they're equipment standards as well. So we're not going to go into these in the detail that we've gone into the other ones, but I wanted to mention them so that you can refer to these and know that they are available. Actuated signals, closed circuit televisions, data collection, rap meters, video switches, signal monitoring units, and center-to-center. We have a couple of standards from the Institute of Electrical and Electronics Engineers for incident management and short range communications. The 2354 standard has to do with advanced travel or information systems, how messages that you may use to communicate information to the public and other ATIS systems.

The LRMS standard, location referencing management system, is a standard that describes how you can encapsulate locations of systems. Do you use latitude and longitude? Do you use points or polygon or line segments? So it's a standard devoted about how you describe where things are located. And then the subsequent standards have to do with cabinets and traffic controllers and things of that nature. These are also available online. And as we talked about before, in terms of the two curriculum paths, there is a path for you to learn about those standards that do not have SEP content. And so if you're interested in that, we saw what the curriculum path was and the next module in that sequence would be 202: Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content.

Okay, well in conclusion, I wanna summarize what it is that we learned today. First thing we learned is that user needs describe the major capability provided by a system. So hopefully, we all know now what a user need is. We've also, hopefully, have a reasonable idea of the criteria by which we judge a user need. Is it a well written user need or not? Is it uniquely identifiable? Does it describe a major desired capability? Is it solution free? And does it capture our rationale for doing things?

We've looked at the eight ITS standards that have SEP or Systems Engineering Process content. We can hopefully see, we have seen, how useful these could be in helping us to come up with our own set of user needs and requirements for our own system. We've gone through the process of going through the concept of operations section or the user needs section or the PRL to get a list of user needs for our own purposes. These were the objectives that we were trying to accomplish today. In addition to those that I've mentioned, we've seen those standards that do not have SEP content and we've talked about the fact that there's a whole curriculum path that you can follow to learn a lot more about those standards and it begins with Module A 202.

The next module on both the SEP and non-SEP path is A201, acquiring standards based ITS systems. You may learn more by looking through the modules, the student supplement that's available to you for download, the NTCIP guide, and all the standards and websites that are available online. At this point, I'd like to open the chat floor for any questions. One question that has come up is: how are standards currently identified as having SEP content? Basically, by looking at the title, you will not know whether it has SEP content. You saw the list that I gave you. Those are the currently recognized standards that have SEP content, but you'd know right away if you go through the table of contents. If it has a concept of operations, if it has a user needs section, if it has a NRTM or a PRL, then you know it has gone through SEP content.

So basically, based on the list and going through there, you'll know whether it has gone through the SEP content or not. Any additional questions? Another question that I have received previously was: does each standard show where it has been used or implemented? And the answer is no, it's not readily available online. Although, as you saw from the DMS example I gave you, there is typically additional supplemental work, other case studies that you can refer to when you look at the standard. Another question is: how can you decide which curriculum path is needed for you?

The curriculum path, basically, is broken down by SEP path and non-SEP path. And so what you wanna do is you wanna look at the two different lists of standards that I summarized in the presentation and look at the content of those standards. Are you and your project more interested in those standards that have gone through the SEP process or not? And you would basically then go with one path or the other. Also, you saw that many of the modules are common to both paths. So at the beginning, in terms of the introductory modules, both of them are along the two paths. In the non-SEP path you're gonna spend more time looking on deriving user needs and requirements from those standards where it's not so easy. So take a look at the standards that we saw, look at the projects that you're going to be working on, and use that as a starting point in terms of which curriculum path you wish to follow.

Any other questions? Another question I had from a previous webinar is: how do you tackle the standards when doing an upgrade to an existing system? And the question to me basically indicates how maybe we can be confused in terms of you know there's an ITS standard for dynamic message sign implementation and communications. Let me start with that and then have it tell me what I need to do for my system and I did say in the webinar that you can go both ways. You can start with your user needs, compare it to the standards, or you can start with the standard and help it to build your user needs. But in the end, you have to want your user needs to reflect what you want your system to do. In the end, your concept of operations, your user needs, has to reflect your vision of your system.

So the standards are there as a supplement, as a guide, so in the case of upgrading, right? The Minnesota example that I showed is exactly that. They were upgrading their TMC and they used the ITS standard there. So what they did was they prepared their own concept of operations document that referenced and borrowed from the ITS standards so that's a good way to follow this. Is there a list of standards applicable to a specific type of project? I think it's hard to say. For example, the NTCIP standards have to do with communications with ITS field equipment. So, yes, in the perspective that my project is about putting new CCTVs out there or my project is about deploying environmental sensors then yes, certainly you would go to the NTCIP standard for environmental sensors. You would go to the NTCIP standard for dynamic message signs. If your project has to deal with I want my center to communicate with the regional center. You would probably wanna look at the TMDD standard because that deals with center-to-center communication so there is no defined list other than you have a list of what standards are, and you get a basic understanding of the contents of each of those standards and where it might be useful to you.

Okay, it looks like there are no more questions. I'd like to thank you very much for your participation in this webinar. This ends the training Module A102. Thank you.

[End of Audio]