1
00:00:00,432 --> 00:00:02,792
There's other forms of software 
requirements.

2
00:00:02,792 --> 00:00:07,382
There's also architectural requirements.
By component naming, you want to be

3
00:00:07,382 --> 00:00:12,456
consistent. Compatibility with other 
systems. Interfaceability, you want

4
00:00:12,456 --> 00:00:16,319
loose coupling to allow you to meet
that one.

5
00:00:16,319 --> 00:00:22,975
Upgradability, so this is important if you
want to -- if you think you'll be

6
00:00:22,975 --> 00:00:26,961
putting out future versions at a
later time.

7
00:00:27,162 --> 00:00:32,832
And even buildability, can you do
daily builds? Can you make that easy

8
00:00:32,832 --> 00:00:36,744
to be able to deploy more software,
more quickly to more customers.

9
00:00:36,744 --> 00:00:40,594
So there's a lot of things that go
into the architectural aspects

10
00:00:40,594 --> 00:00:44,134
of how you build your software
that roll up into non-functional

11
00:00:44,134 --> 00:00:47,564
requirements. There's constraints -- 
requirements related to constraints like

12
00:00:47,564 --> 00:00:49,964
system design, there may be 
hardware restrictions,

13
00:00:49,964 --> 00:00:53,124
standards conformance,
legal issues,

14
00:00:53,124 --> 00:00:56,264
organizational issues,
we've talked about functional or

15
00:00:56,264 --> 00:00:59,774
non-functional, and may even come from
users and organizations

16
00:00:59,774 --> 00:01:03,504
and be conflicting, so those all need
to be resolved as well.

17
00:01:03,504 --> 00:01:06,854
So these fall into the category of 
contraints.

18
00:01:06,854 --> 00:01:10,484
Good requirements have to be --
have to have a number of attributes.

19
00:01:10,484 --> 00:01:14,574
They have to be possible,
feasible to actually do within budget.

20
00:01:14,587 --> 00:01:17,607
You have to be necessary,
someone has to really want them,

21
00:01:17,607 --> 00:01:20,937
you have to trace it back to a
use case or user story.

22
00:01:20,937 --> 00:01:26,747
You have to be prioritized. Unfortunately,
our customers can't say that everything is

23
00:01:26,747 --> 00:01:30,627
top-priority, so we have to find a way
of prioritizing them.

24
00:01:30,627 --> 00:01:36,167
Unambiguous is only one interpretation.
It's easy to read, easy to understand.

25
00:01:36,167 --> 00:01:40,277
You have to be concise. Only the 
information needed, don't need to go

26
00:01:40,277 --> 00:01:44,987
into noisy explanation, that's not
necessary.

27
00:01:44,987 --> 00:01:48,527
And then Verifiable. If you can't test it
or measure it, then you don't know

28
00:01:48,527 --> 00:01:51,817
whether you'll be done. So these are
just some imporant characteristics

29
00:01:51,817 --> 00:01:54,907
of requirements that need to be
understood.

30
00:01:54,907 --> 00:01:59,987
In this next section, let's talk about 
the requirements development process.

31
00:02:01,059 --> 00:02:06,309
Here, Weinberg shows these steps
to ellicit and analyze requirements.

32
00:02:06,309 --> 00:02:09,709
Starts with problem recognition,
discovering and gathering,

33
00:02:09,709 --> 00:02:14,539
then evaluation and synthesis.
Modeling, we'll talk about modeling,

34
00:02:14,539 --> 00:02:19,789
and then specification --
packaging and format final review for --

35
00:02:19,789 --> 00:02:23,789
this is his process for eliciting
and analyzing requirements.

36
00:02:24,003 --> 00:02:28,493
And the first circled section there
is what we'll concentrate on first,

37
00:02:28,493 --> 00:02:33,223
the elicitation analysis, then we'll go
into the modeling, and then finally talk

38
00:02:33,223 --> 00:02:36,643
a little bit about -- we'll talk about
specification then a little bit about

39
00:02:36,643 --> 00:02:40,103
modeling and validation.

40
00:02:40,103 --> 00:02:44,803
At a high level, Carl Weiger's 
requirements development process

41
00:02:44,803 --> 00:02:50,493
is somewhat similar. Elicitation into
analysis, there may be some clarification

42
00:02:50,493 --> 00:02:54,243
that has to go back into the
elicitation phase.

43
00:02:54,243 --> 00:03:00,933
Into the specicication, validation may
cause us to rewrite the specification.

44
00:03:00,933 --> 00:03:05,044
Validation may also cause us to 
reevaluate the requirements

45
00:03:05,044 --> 00:03:10,464
and even to close and correct gaps
in the requirements which takes us

46
00:03:10,464 --> 00:03:13,474
all the way back to
the elicitation phase.

47
00:03:13,474 --> 00:03:17,474
So you can see even in the
requirements process,

48
00:03:17,474 --> 00:03:23,324
it can't be waterfall-ish. It's got 
to have feedback. Re-do clarification,

49
00:03:23,324 --> 00:03:28,134
reevaluation, so even just the
requirements phase itself

50
00:03:28,134 --> 00:03:35,239
is a multi-phase process or subprocess
and so rework and reevaluation often

51
00:03:35,239 --> 00:03:42,039
is necessary. From a capability maturity
model integrated software framework

52
00:03:42,039 --> 00:03:46,769
at level two maturity -- maturity 
level two, you start to already see

53
00:03:46,769 --> 00:03:51,289
requirements, management coming
into play, so this is important already

54
00:03:51,289 --> 00:03:58,249
at level two. The staged model and
so what this is basically saying --

55
00:03:58,249 --> 00:04:03,029
saying that of the seven basic things
you need to be able to do

56
00:04:03,029 --> 00:04:07,139
from project management perspective
and key knowledge areas,

57
00:04:07,139 --> 00:04:12,421
requirements management along with
project planning, project monitoring

58
00:04:12,421 --> 00:04:17,771
and control, supplier agreement,
management measurement analysis,

59
00:04:17,771 --> 00:04:22,351
project planning and quality assurance,
and configuration management.

60
00:04:22,352 --> 00:04:26,752
These are the top seven that form
the basis, one of which is requirements.

61
00:04:27,614 --> 00:04:30,854
Some more details here. Each of the
maturity levels.

62
00:04:30,854 --> 00:04:34,854
The name of that maturity level --
initial, managed, defined,

63
00:04:34,854 --> 00:04:37,264
quantitatively managed
and optimizing --

64
00:04:37,264 --> 00:04:41,364
And you can see where requirements
management is at level two,

65
00:04:41,364 --> 00:04:44,434
but requirements development is
at level three.

66
00:04:44,434 --> 00:04:48,504
These things show early and are
very important to set the basis,

67
00:04:48,504 --> 00:04:52,244
the foundations for all the maturity
levels to come,

68
00:04:52,244 --> 00:04:56,174
so requirements are very important
to address early.

69
00:04:56,174 --> 00:04:59,494
There's a five-step process to do 
problem analysis during the

70
00:04:59,494 --> 00:05:03,024
requirements phase. Step one is to
identify the problem.

71
00:05:03,024 --> 00:05:07,791
The little template there can be used
to specify that problem.

72
00:05:07,791 --> 00:05:11,361
You basically fill it out, so on the left,
the problem of, then you describe

73
00:05:11,361 --> 00:05:16,091
your problem effects, and then you 
identify the stakeholders affected by

74
00:05:16,091 --> 00:05:21,561
the problem, the result of which is an
impact on some set of stakeholders

75
00:05:21,561 --> 00:05:24,271
in business activities,
you need to describe that.

76
00:05:24,271 --> 00:05:28,341
And then the benefits of your new system
are indicated.

77
00:05:28,341 --> 00:05:31,595
The proposed solution -- you indicate
the proposed solution,

78
00:05:31,595 --> 00:05:36,385
list of few key benefits that your
new system wiill provide.

79
00:05:36,385 --> 00:05:39,592
Once you identify the problem.
we have the root cause of problems,

80
00:05:39,592 --> 00:05:44,442
so you can use in step two,
fishbone or Ishikawa diagram

81
00:05:44,442 --> 00:05:51,002
to help you identify the problem.
Step three, identify the actors.

82
00:05:51,002 --> 00:05:54,369
Step four, draw the system boundaries
so you know what's inside

83
00:05:54,369 --> 00:05:58,829
and what's outside. And step five,
you need to be able to identify

84
00:05:58,829 --> 00:06:03,132
the constraints on your proposed
solution.

85
00:06:03,132 --> 00:06:08,813
This is an actual example of an Ishikawa
diagram from industry

86
00:06:08,813 --> 00:06:15,143
trying to address the issue or the 
problem of a Linux distribution technology

87
00:06:15,143 --> 00:06:20,943
that was difficult to use. You can see
the main focal areas are on technology,

88
00:06:20,943 --> 00:06:25,313
people, process and quality
and customer support, and logistics,

89
00:06:25,313 --> 00:06:30,173
and you can see some of the details --
we went down to about three levels here...

90
00:06:31,265 --> 00:06:34,685
to allow us to get the data 
we needed to make adecision

91
00:06:34,685 --> 00:06:39,445
on the requirements, changes we needed
to get our new product out the door.

92
00:06:39,445 --> 00:06:44,315
So I just wanted to show you what
it looks like when you do this

93
00:06:44,315 --> 00:06:49,745
in real industry environments.
These techniques I'm talking to you about

94
00:06:49,745 --> 00:06:54,716
are actually used in industry settings 
and are very effective.

95
00:06:55,053 --> 00:06:59,313
Constraints actually come in many forms.
You can see the different sources here,

96
00:06:59,313 --> 00:07:05,023
system constraints, environmental
resource, and schedule,

97
00:07:05,023 --> 00:07:10,393
economic, political, and technical.
There's some examples there.

98
00:07:10,590 --> 00:07:15,920
Each of these sources of constraints
needs to be evaluated very closely.

99
00:07:16,915 --> 00:07:23,345
In the past, I've been burned by not
properly understanding the constraints

100
00:07:23,345 --> 00:07:28,894
that, for example, legal issues with
open source software

101
00:07:28,894 --> 00:07:31,904
if you don't have that documented
very carefully.

102
00:07:31,904 --> 00:07:36,474
People have been bitten on that one.
Security requirements, there's different

103
00:07:36,474 --> 00:07:39,644
security requirements for here
versus Europe.

104
00:07:39,644 --> 00:07:43,572
So you have to really go into the details,
you know, licensing issues.

105
00:07:43,572 --> 00:07:47,652
There are multiple licensing types 
for open-source software,

106
00:07:47,652 --> 00:07:51,932
which one are you going to use?
So these all have to be considered

107
00:07:51,932 --> 00:07:54,842
during a requirements phase as
constraints on the problem,

108
00:07:54,842 --> 00:07:59,282
these limit the degrees of freedom
so you need to consider these early

109
00:07:59,282 --> 00:08:00,874
during this phase.

110
00:08:00,874 --> 00:08:03,994
The next thing you want to do is 
separate the problem from the solution.

111
00:08:03,994 --> 00:08:09,654
You have the problem situation,
you need to obviously create a

112
00:08:09,663 --> 00:08:14,243
problem statement and implementation
statement and then that's going to be used

113
00:08:14,243 --> 00:08:20,343
ultimately for verification, the
implementation, definition back to the


114
00:08:20,343 --> 00:08:24,473
problem statement to make sure you're
building what you were told to build

115
00:08:24,473 --> 00:08:28,234
and then there's going to be a validation
step back to the problem situation

116
00:08:28,234 --> 00:08:31,184
to make sure you're actually
solving problem.

117
00:08:31,184 --> 00:08:34,484
There will be some correctness
and correspondence relationships

118
00:08:34,484 --> 00:08:38,904
between the problem statement 
and the problem situation

119
00:08:38,904 --> 00:08:47,464
to the system and we will -- but it first
starts with, rather than proposing

120
00:08:47,464 --> 00:08:54,114
the solution, first separate problem
situation and look at it from top-down.

121
00:08:54,114 --> 00:08:58,174
The most obvious problem might not be
the one that you need to solve,

122
00:08:58,174 --> 00:09:01,314
so that's why it's good to separate 
the problem first,

123
00:09:01,314 --> 00:09:05,314
look at it independently,
discuss the problem statement

124
00:09:05,314 --> 00:09:10,724
with your stakeholders, and look at 
the different design choices.

125
00:09:10,724 --> 00:09:16,814
So, again, the most obvious problem may not
be the one you're actually trying to solve.

126
00:09:16,815 --> 00:09:21,775
You want to check for the solution
correctly solves the stated problem.

127
00:09:21,775 --> 00:09:24,085
But, also, check that
the problem statement

128
00:09:24,085 --> 00:09:27,505
corresponds to the real needs
of the stakeholders.

129
00:09:29,700 --> 00:09:32,340
Problems can be separated
in different ways.

130
00:09:32,340 --> 00:09:35,560
For example, let's consider this one
requirement.

131
00:09:35,560 --> 00:09:38,990
You want to prevent unauthorized access
to a University of Texas machine.

132
00:09:38,990 --> 00:09:42,030
Well, we can separate this into different
domains.

133
00:09:42,030 --> 00:09:44,990
On the left, you see the application
domain.

134
00:09:44,990 --> 00:09:49,370
These are the things that the machine --
the computer, cannot observe directly.

135
00:09:49,370 --> 00:09:54,500
Like, students, intruders, sysadmin,
signed forms, even stickies

136
00:09:54,500 --> 00:09:56,580
with your password on them.

137
00:09:56,580 --> 00:10:01,110
This is in, I'll call this the real world
domain, or the application domain.

138
00:10:01,110 --> 00:10:03,250
On the right-hand side is
the machine domain.

139
00:10:03,250 --> 00:10:05,710
This is where your software is going
to run things that are private

140
00:10:05,710 --> 00:10:07,190
to the machine.

141
00:10:07,190 --> 00:10:10,900
The encryption algorithms, the password
files, etc.

142
00:10:10,900 --> 00:10:13,780
And then the that thing in the middle --
the shared things --

143
00:10:13,780 --> 00:10:17,780
Think of this almost as the interphase
requirements for the system.

144
00:10:17,780 --> 00:10:22,880
Where you need to deal with things, like
T-cards, or passwords, or user names,

145
00:10:22,880 --> 00:10:28,285
or things being typed at the keyboard.
Shared things between the real world,

146
00:10:28,285 --> 00:10:30,265
and the machine.

147
00:10:30,265 --> 00:10:33,155
Normally in the form of the user
interphase,

148
00:10:33,155 --> 00:10:37,715
and this is where we also begin to think
about our user interphase requirements.

149
00:10:37,806 --> 00:10:41,806
So, now we can think of these domain
properties, and requirements, on the left.

150
00:10:41,806 --> 00:10:45,346
Again, that's the application domain.
That's where we have domain properties,

151
00:10:45,346 --> 00:10:47,166
and requirements.

152
00:10:47,166 --> 00:10:52,206
Domain properties, think of them as things
in the application domain that remain true

153
00:10:52,206 --> 00:10:54,196
whether or not we ever build the system.

154
00:10:54,196 --> 00:10:57,086
You know the sun's going to come up,
and the sun's going to set.

155
00:10:57,086 --> 00:11:00,966
These things are true regardless of
whether we ever build a system or not.

156
00:11:00,966 --> 00:11:04,546
The requirements are the things in
the application domain

157
00:11:04,546 --> 00:11:09,806
that we want to be true by delivering
on the system we're proposing.

158
00:11:09,806 --> 00:11:13,196
So, those are the things in the application
domain. On the right-hand side,

159
00:11:13,196 --> 00:11:16,876
in the machine domain, we have
computers and we have programs.

160
00:11:16,876 --> 00:11:21,196
The things that actually implement --
that control one way or the other

161
00:11:21,196 --> 00:11:23,876
the application domain.
And then in the middle,

162
00:11:23,876 --> 00:11:28,676
we have the specification. The specification
is a description of the behaviors

163
00:11:28,676 --> 00:11:32,826
that our program has to have in order
to meet the requirements.

164
00:11:33,092 --> 00:11:36,522
Normally written in terms of shared
phenomenon.

165
00:11:36,522 --> 00:11:39,612
Again, things through the user interphase.

166
00:11:39,612 --> 00:11:44,722
Data being passed back and forth between
the machine and the user. Things like this.

167
00:11:44,722 --> 00:11:48,622
Some of that is described in
the specification.

168
00:11:48,622 --> 00:11:51,562
Which is the shared phenomenon.

169
00:11:51,562 --> 00:11:55,812
Now, in this application, and machine
domain, kind of Venn diagram here,

170
00:11:55,812 --> 00:11:57,612
we can shift things around as well.

171
00:11:57,612 --> 00:11:59,632
We can move the boundaries.

172
00:11:59,632 --> 00:12:02,542
If we're building an elevator control
system, for example,

173
00:12:02,542 --> 00:12:05,922
here's how that might look. The application
domain would be the real world.

174
00:12:05,922 --> 00:12:08,742
You know, people waiting; people in
the elevator; people wanting

175
00:12:08,742 --> 00:12:12,742
to go to a particular floor; the elevator
motors and safety rules

176
00:12:12,742 --> 00:12:15,992
that are bolted to the elevator.

177
00:12:15,992 --> 00:12:18,572
We have the scheduling algorithms,
and the control programs

178
00:12:18,572 --> 00:12:21,562
actually running in the machine domain,
and then we have all this

179
00:12:21,562 --> 00:12:24,562
overlap. All this intersection.

180
00:12:24,562 --> 00:12:27,612
The elevator call buttons; the floor
request buttons; etc.

181
00:12:27,612 --> 00:12:31,722
Now, we could move things from
the application domain

182
00:12:31,722 --> 00:12:34,672
into the shared domain

183
00:12:34,672 --> 00:12:37,842
by changing how the system's
going to behave.

184
00:12:37,842 --> 00:12:41,782
We can add sensors, for example,
to detect when people are waiting.

185
00:12:41,782 --> 00:12:45,382
And doing this type of thing changes
the nature of the problem being solved.

186
00:12:45,382 --> 00:12:48,242
So, all this --

187
00:12:48,242 --> 00:12:51,512
The application domain, the shared
domain, the machine domain,

188
00:12:51,512 --> 00:12:54,782
what goes where can change based on
how we define the problem.