0:00:00.432,0:00:02.792 There's other forms of software [br]requirements. 0:00:02.792,0:00:07.382 There's also architectural requirements.[br]By component naming, you want to be 0:00:07.382,0:00:12.456 consistent. Compatibility with other [br]systems. Interfaceability, you want 0:00:12.456,0:00:16.319 loose coupling to allow you to meet[br]that one. 0:00:16.319,0:00:22.975 Upgradability, so this is important if you[br]want to -- if you think you'll be 0:00:22.975,0:00:26.961 putting out future versions at a[br]later time. 0:00:27.162,0:00:32.832 And even buildability, can you do[br]daily builds? Can you make that easy 0:00:32.832,0:00:36.744 to be able to deploy more software,[br]more quickly to more customers. 0:00:36.744,0:00:40.594 So there's a lot of things that go[br]into the architectural aspects 0:00:40.594,0:00:44.134 of how you build your software[br]that roll up into non-functional 0:00:44.134,0:00:47.564 requirements. There's constraints -- [br]requirements related to constraints like 0:00:47.564,0:00:49.964 system design, there may be [br]hardware restrictions, 0:00:49.964,0:00:53.124 standards conformance,[br]legal issues, 0:00:53.124,0:00:56.264 organizational issues,[br]we've talked about functional or 0:00:56.264,0:00:59.774 non-functional, and may even come from[br]users and organizations 0:00:59.774,0:01:03.504 and be conflicting, so those all need[br]to be resolved as well. 0:01:03.504,0:01:06.854 So these fall into the category of [br]contraints. 0:01:06.854,0:01:10.484 Good requirements have to be --[br]have to have a number of attributes. 0:01:10.484,0:01:14.574 They have to be possible,[br]feasible to actually do within budget. 0:01:14.587,0:01:17.607 You have to be necessary,[br]someone has to really want them, 0:01:17.607,0:01:20.937 you have to trace it back to a[br]use case or user story. 0:01:20.937,0:01:26.747 You have to be prioritized. Unfortunately,[br]our customers can't say that everything is 0:01:26.747,0:01:30.627 top-priority, so we have to find a way[br]of prioritizing them. 0:01:30.627,0:01:36.167 Unambiguous is only one interpretation.[br]It's easy to read, easy to understand. 0:01:36.167,0:01:40.277 You have to be concise. Only the [br]information needed, don't need to go 0:01:40.277,0:01:44.987 into noisy explanation, that's not[br]necessary. 0:01:44.987,0:01:48.527 And then Verifiable. If you can't test it[br]or measure it, then you don't know 0:01:48.527,0:01:51.817 whether you'll be done. So these are[br]just some imporant characteristics 0:01:51.817,0:01:54.907 of requirements that need to be[br]understood. 0:01:54.907,0:01:59.987 In this next section, let's talk about [br]the requirements development process. 0:02:01.059,0:02:06.309 Here, Weinberg shows these steps[br]to ellicit and analyze requirements. 0:02:06.309,0:02:09.709 Starts with problem recognition,[br]discovering and gathering, 0:02:09.709,0:02:14.539 then evaluation and synthesis.[br]Modeling, we'll talk about modeling, 0:02:14.539,0:02:19.789 and then specification --[br]packaging and format final review for -- 0:02:19.789,0:02:23.789 this is his process for eliciting[br]and analyzing requirements. 0:02:24.003,0:02:28.493 And the first circled section there[br]is what we'll concentrate on first, 0:02:28.493,0:02:33.223 the elicitation analysis, then we'll go[br]into the modeling, and then finally talk 0:02:33.223,0:02:36.643 a little bit about -- we'll talk about[br]specification then a little bit about 0:02:36.643,0:02:40.103 modeling and validation. 0:02:40.103,0:02:44.803 At a high level, Carl Weiger's [br]requirements development process 0:02:44.803,0:02:50.493 is somewhat similar. Elicitation into[br]analysis, there may be some clarification 0:02:50.493,0:02:54.243 that has to go back into the[br]elicitation phase. 0:02:54.243,0:03:00.933 Into the specicication, validation may[br]cause us to rewrite the specification. 0:03:00.933,0:03:05.044 Validation may also cause us to [br]reevaluate the requirements 0:03:05.044,0:03:10.464 and even to close and correct gaps[br]in the requirements which takes us 0:03:10.464,0:03:13.474 all the way back to[br]the elicitation phase. 0:03:13.474,0:03:17.474 So you can see even in the[br]requirements process, 0:03:17.474,0:03:23.324 it can't be waterfall-ish. It's got [br]to have feedback. Re-do clarification, 0:03:23.324,0:03:28.134 reevaluation, so even just the[br]requirements phase itself 0:03:28.134,0:03:35.239 is a multi-phase process or subprocess[br]and so rework and reevaluation often 0:03:35.239,0:03:42.039 is necessary. From a capability maturity[br]model integrated software framework 0:03:42.039,0:03:46.769 at level two maturity -- maturity [br]level two, you start to already see 0:03:46.769,0:03:51.289 requirements, management coming[br]into play, so this is important already 0:03:51.289,0:03:58.249 at level two. The staged model and[br]so what this is basically saying -- 0:03:58.249,0:04:03.029 saying that of the seven basic things[br]you need to be able to do 0:04:03.029,0:04:07.139 from project management perspective[br]and key knowledge areas, 0:04:07.139,0:04:12.421 requirements management along with[br]project planning, project monitoring 0:04:12.421,0:04:17.771 and control, supplier agreement,[br]management measurement analysis, 0:04:17.771,0:04:22.351 project planning and quality assurance,[br]and configuration management. 0:04:22.352,0:04:26.752 These are the top seven that form[br]the basis, one of which is requirements. 0:04:27.614,0:04:30.854 Some more details here. Each of the[br]maturity levels. 0:04:30.854,0:04:34.854 The name of that maturity level --[br]initial, managed, defined, 0:04:34.854,0:04:37.264 quantitatively managed[br]and optimizing -- 0:04:37.264,0:04:41.364 And you can see where requirements[br]management is at level two, 0:04:41.364,0:04:44.434 but requirements development is[br]at level three. 0:04:44.434,0:04:48.504 These things show early and are[br]very important to set the basis, 0:04:48.504,0:04:52.244 the foundations for all the maturity[br]levels to come, 0:04:52.244,0:04:56.174 so requirements are very important[br]to address early. 0:04:56.174,0:04:59.494 There's a five-step process to do [br]problem analysis during the 0:04:59.494,0:05:03.024 requirements phase. Step one is to[br]identify the problem. 0:05:03.024,0:05:07.791 The little template there can be used[br]to specify that problem. 0:05:07.791,0:05:11.361 You basically fill it out, so on the left,[br]the problem of, then you describe 0:05:11.361,0:05:16.091 your problem effects, and then you [br]identify the stakeholders affected by 0:05:16.091,0:05:21.561 the problem, the result of which is an[br]impact on some set of stakeholders 0:05:21.561,0:05:24.271 in business activities,[br]you need to describe that. 0:05:24.271,0:05:28.341 And then the benefits of your new system[br]are indicated. 0:05:28.341,0:05:31.595 The proposed solution -- you indicate[br]the proposed solution, 0:05:31.595,0:05:36.385 list of few key benefits that your[br]new system wiill provide. 0:05:36.385,0:05:39.592 Once you identify the problem.[br]we have the root cause of problems, 0:05:39.592,0:05:44.442 so you can use in step two,[br]fishbone or Ishikawa diagram 0:05:44.442,0:05:51.002 to help you identify the problem.[br]Step three, identify the actors. 0:05:51.002,0:05:54.369 Step four, draw the system boundaries[br]so you know what's inside 0:05:54.369,0:05:58.829 and what's outside. And step five,[br]you need to be able to identify 0:05:58.829,0:06:03.132 the constraints on your proposed[br]solution. 0:06:03.132,0:06:08.813 This is an actual example of an Ishikawa[br]diagram from industry 0:06:08.813,0:06:15.143 trying to address the issue or the [br]problem of a Linux distribution technology 0:06:15.143,0:06:20.943 that was difficult to use. You can see[br]the main focal areas are on technology, 0:06:20.943,0:06:25.313 people, process and quality[br]and customer support, and logistics, 0:06:25.313,0:06:30.173 and you can see some of the details --[br]we went down to about three levels here... 0:06:31.265,0:06:34.685 to allow us to get the data [br]we needed to make adecision 0:06:34.685,0:06:39.445 on the requirements, changes we needed[br]to get our new product out the door. 0:06:39.445,0:06:44.315 So I just wanted to show you what[br]it looks like when you do this 0:06:44.315,0:06:49.745 in real industry environments.[br]These techniques I'm talking to you about 0:06:49.745,0:06:54.716 are actually used in industry settings [br]and are very effective. 0:06:55.053,0:06:59.313 Constraints actually come in many forms.[br]You can see the different sources here, 0:06:59.313,0:07:05.023 system constraints, environmental[br]resource, and schedule, 0:07:05.023,0:07:10.393 economic, political, and technical.[br]There's some examples there. 0:07:10.590,0:07:15.920 Each of these sources of constraints[br]needs to be evaluated very closely. 0:07:16.915,0:07:23.345 In the past, I've been burned by not[br]properly understanding the constraints 0:07:23.345,0:07:28.894 that, for example, legal issues with[br]open source software 0:07:28.894,0:07:31.904 if you don't have that documented[br]very carefully. 0:07:31.904,0:07:36.474 People have been bitten on that one.[br]Security requirements, there's different 0:07:36.474,0:07:39.644 security requirements for here[br]versus Europe. 0:07:39.644,0:07:43.572 So you have to really go into the details,[br]you know, licensing issues. 0:07:43.572,0:07:47.652 There are multiple licensing types [br]for open-source software, 0:07:47.652,0:07:51.932 which one are you going to use?[br]So these all have to be considered 0:07:51.932,0:07:54.842 during a requirements phase as[br]constraints on the problem, 0:07:54.842,0:07:59.282 these limit the degrees of freedom[br]so you need to consider these early 0:07:59.282,0:08:00.874 during this phase. 0:08:00.874,0:08:03.994 The next thing you want to do is [br]separate the problem from the solution. 0:08:03.994,0:08:09.654 You have the problem situation,[br]you need to obviously create a 0:08:09.663,0:08:14.243 problem statement and implementation[br]statement and then that's going to be used 0:08:14.243,0:08:20.343 ultimately for verification, the[br]implementation, definition back to the[br] 0:08:20.343,0:08:24.473 problem statement to make sure you're[br]building what you were told to build 0:08:24.473,0:08:28.234 and then there's going to be a validation[br]step back to the problem situation 0:08:28.234,0:08:31.184 to make sure you're actually[br]solving problem. 0:08:31.184,0:08:34.484 There will be some correctness[br]and correspondence relationships 0:08:34.484,0:08:38.904 between the problem statement [br]and the problem situation 0:08:38.904,0:08:47.464 to the system and we will -- but it first[br]starts with, rather than proposing 0:08:47.464,0:08:54.114 the solution, first separate problem[br]situation and look at it from top-down. 0:08:54.114,0:08:58.174 The most obvious problem might not be[br]the one that you need to solve, 0:08:58.174,0:09:01.314 so that's why it's good to separate [br]the problem first, 0:09:01.314,0:09:05.314 look at it independently,[br]discuss the problem statement 0:09:05.314,0:09:10.724 with your stakeholders, and look at [br]the different design choices. 0:09:10.724,0:09:16.814 So, again, the most obvious problem may not[br]be the one you're actually trying to solve. 0:09:16.815,0:09:21.775 You want to check for the solution[br]correctly solves the stated problem. 0:09:21.775,0:09:24.085 But, also, check that[br]the problem statement 0:09:24.085,0:09:27.505 corresponds to the real needs[br]of the stakeholders. 0:09:29.700,0:09:32.340 Problems can be separated[br]in different ways. 0:09:32.340,0:09:35.560 For example, let's consider this one[br]requirement. 0:09:35.560,0:09:38.990 You want to prevent unauthorized access[br]to a University of Texas machine. 0:09:38.990,0:09:42.030 Well, we can separate this into different[br]domains. 0:09:42.030,0:09:44.990 On the left, you see the application[br]domain. 0:09:44.990,0:09:49.370 These are the things that the machine --[br]the computer, cannot observe directly. 0:09:49.370,0:09:54.500 Like, students, intruders, sysadmin,[br]signed forms, even stickies 0:09:54.500,0:09:56.580 with your password on them. 0:09:56.580,0:10:01.110 This is in, I'll call this the real world[br]domain, or the application domain. 0:10:01.110,0:10:03.250 On the right-hand side is[br]the machine domain. 0:10:03.250,0:10:05.710 This is where your software is going[br]to run things that are private 0:10:05.710,0:10:07.190 to the machine. 0:10:07.190,0:10:10.900 The encryption algorithms, the password[br]files, etc. 0:10:10.900,0:10:13.780 And then the that thing in the middle --[br]the shared things -- 0:10:13.780,0:10:17.780 Think of this almost as the interphase[br]requirements for the system. 0:10:17.780,0:10:22.880 Where you need to deal with things, like[br]T-cards, or passwords, or user names, 0:10:22.880,0:10:28.285 or things being typed at the keyboard.[br]Shared things between the real world, 0:10:28.285,0:10:30.265 and the machine. 0:10:30.265,0:10:33.155 Normally in the form of the user[br]interphase, 0:10:33.155,0:10:37.715 and this is where we also begin to think[br]about our user interphase requirements. 0:10:37.806,0:10:41.806 So, now we can think of these domain[br]properties, and requirements, on the left. 0:10:41.806,0:10:45.346 Again, that's the application domain.[br]That's where we have domain properties, 0:10:45.346,0:10:47.166 and requirements. 0:10:47.166,0:10:52.206 Domain properties, think of them as things[br]in the application domain that remain true 0:10:52.206,0:10:54.196 whether or not we ever build the system. 0:10:54.196,0:10:57.086 You know the sun's going to come up,[br]and the sun's going to set. 0:10:57.086,0:11:00.966 These things are true regardless of[br]whether we ever build a system or not. 0:11:00.966,0:11:04.546 The requirements are the things in[br]the application domain 0:11:04.546,0:11:09.806 that we want to be true by delivering[br]on the system we're proposing. 0:11:09.806,0:11:13.196 So, those are the things in the application[br]domain. On the right-hand side, 0:11:13.196,0:11:16.876 in the machine domain, we have[br]computers and we have programs. 0:11:16.876,0:11:21.196 The things that actually implement --[br]that control one way or the other 0:11:21.196,0:11:23.876 the application domain.[br]And then in the middle, 0:11:23.876,0:11:28.676 we have the specification. The specification[br]is a description of the behaviors 0:11:28.676,0:11:32.826 that our program has to have in order[br]to meet the requirements. 0:11:33.092,0:11:36.522 Normally written in terms of shared[br]phenomenon. 0:11:36.522,0:11:39.612 Again, things through the user interphase. 0:11:39.612,0:11:44.722 Data being passed back and forth between[br]the machine and the user. Things like this. 0:11:44.722,0:11:48.622 Some of that is described in[br]the specification. 0:11:48.622,0:11:51.562 Which is the shared phenomenon. 0:11:51.562,0:11:55.812 Now, in this application, and machine[br]domain, kind of Venn diagram here, 0:11:55.812,0:11:57.612 we can shift things around as well. 0:11:57.612,0:11:59.632 We can move the boundaries. 0:11:59.632,0:12:02.542 If we're building an elevator control[br]system, for example, 0:12:02.542,0:12:05.922 here's how that might look. The application[br]domain would be the real world. 0:12:05.922,0:12:08.742 You know, people waiting; people in[br]the elevator; people wanting 0:12:08.742,0:12:12.742 to go to a particular floor; the elevator[br]motors and safety rules 0:12:12.742,0:12:15.992 that are bolted to the elevator. 0:12:15.992,0:12:18.572 We have the scheduling algorithms,[br]and the control programs 0:12:18.572,0:12:21.562 actually running in the machine domain,[br]and then we have all this 0:12:21.562,0:12:24.562 overlap. All this intersection. 0:12:24.562,0:12:27.612 The elevator call buttons; the floor[br]request buttons; etc. 0:12:27.612,0:12:31.722 Now, we could move things from[br]the application domain 0:12:31.722,0:12:34.672 into the shared domain 0:12:34.672,0:12:37.842 by changing how the system's[br]going to behave. 0:12:37.842,0:12:41.782 We can add sensors, for example,[br]to detect when people are waiting. 0:12:41.782,0:12:45.382 And doing this type of thing changes[br]the nature of the problem being solved. 0:12:45.382,0:12:48.242 So, all this -- 0:12:48.242,0:12:51.512 The application domain, the shared[br]domain, the machine domain, 0:12:51.512,0:12:54.782 what goes where can change based on[br]how we define the problem.