There's other forms of software 
requirements.

There's also architectural requirements.
By component naming, you want to be

consistent. Compatibility with other 
systems. Interfaceability, you want

loose coupling to allow you to meet
that one.

Upgradability, so this is important if you
want to -- if you think you'll be

putting out future versions at a
later time.

And even buildability, can you do
daily builds? Can you make that easy

to be able to deploy more software,
more quickly to more customers.

So there's a lot of things that go
into the architectural aspects

of how you build your software
that roll up into non-functional

requirements. There's constraints -- 
requirements related to constraints like

system design, there may be 
hardware restrictions,

standards conformance,
legal issues,

organizational issues,
we've talked about functional or

non-functional, and may even come from
users and organizations

and be conflicting, so those all need
to be resolved as well.

So these fall into the category of 
contraints.

Good requirements have to be --
have to have a number of attributes.

They have to be possible,
feasible to actually do within budget.

You have to be necessary,
someone has to really want them,

you have to trace it back to a
use case or user story.

You have to be prioritized. Unfortunately,
our customers can't say that everything is

top-priority, so we have to find a way
of prioritizing them.

Unambiguous is only one interpretation.
It's easy to read, easy to understand.

You have to be concise. Only the 
information needed, don't need to go

into noisy explanation, that's not
necessary.

And then Verifiable. If you can't test it
or measure it, then you don't know

whether you'll be done. So these are
just some imporant characteristics

of requirements that need to be
understood.

In this next section, let's talk about 
the requirements development process.

Here, Weinberg shows these steps
to ellicit and analyze requirements.

Starts with problem recognition,
discovering and gathering,

then evaluation and synthesis.
Modeling, we'll talk about modeling,

and then specification --
packaging and format final review for --

this is his process for eliciting
and analyzing requirements.

And the first circled section there
is what we'll concentrate on first,

the elicitation analysis, then we'll go
into the modeling, and then finally talk

a little bit about -- we'll talk about
specification then a little bit about

modeling and validation.

At a high level, Carl Weiger's 
requirements development process

is somewhat similar. Elicitation into
analysis, there may be some clarification

that has to go back into the
elicitation phase.

Into the specicication, validation may
cause us to rewrite the specification.

Validation may also cause us to 
reevaluate the requirements

and even to close and correct gaps
in the requirements which takes us

all the way back to
the elicitation phase.

So you can see even in the
requirements process,

it can't be waterfall-ish. It's got 
to have feedback. Re-do clarification,

reevaluation, so even just the
requirements phase itself

is a multi-phase process or subprocess
and so rework and reevaluation often

is necessary. From a capability maturity
model integrated software framework

at level two maturity -- maturity 
level two, you start to already see

requirements, management coming
into play, so this is important already

at level two. The staged model and
so what this is basically saying --

saying that of the seven basic things
you need to be able to do

from project management perspective
and key knowledge areas,

requirements management along with
project planning, project monitoring

and control, supplier agreement,
management measurement analysis,

project planning and quality assurance,
and configuration management.

These are the top seven that form
the basis, one of which is requirements.

Some more details here. Each of the
maturity levels.

The name of that maturity level --
initial, managed, defined,

quantitatively managed
and optimizing --

And you can see where requirements
management is at level two,

but requirements development is
at level three.

These things show early and are
very important to set the basis,

the foundations for all the maturity
levels to come,

so requirements are very important
to address early.

There's a five-step process to do 
problem analysis during the

requirements phase. Step one is to
identify the problem.

The little template there can be used
to specify that problem.

You basically fill it out, so on the left,
the problem of, then you describe

your problem effects, and then you 
identify the stakeholders affected by

the problem, the result of which is an
impact on some set of stakeholders

in business activities,
you need to describe that.

And then the benefits of your new system
are indicated.

The proposed solution -- you indicate
the proposed solution,

list of few key benefits that your
new system wiill provide.

Once you identify the problem.
we have the root cause of problems,

so you can use in step two,
fishbone or Ishikawa diagram

to help you identify the problem.
Step three, identify the actors.

Step four, draw the system boundaries
so you know what's inside

and what's outside. And step five,
you need to be able to identify

the constraints on your proposed
solution.

This is an actual example of an Ishikawa
diagram from industry

trying to address the issue or the 
problem of a Linux distribution technology

that was difficult to use. You can see
the main focal areas are on technology,

people, process and quality
and customer support, and logistics,

and you can see some of the details --
we went down to about three levels here...

to allow us to get the data 
we needed to make adecision

on the requirements, changes we needed
to get our new product out the door.

So I just wanted to show you what
it looks like when you do this

in real industry environments.
These techniques I'm talking to you about

are actually used in industry settings 
and are very effective.

Constraints actually come in many forms.
You can see the different sources here,

system constraints, environmental
resource, and schedule,

economic, political, and technical.
There's some examples there.

Each of these sources of constraints
needs to be evaluated very closely.

In the past, I've been burned by not
properly understanding the constraints

that, for example, legal issues with
open source software

if you don't have that documented
very carefully.

People have been bitten on that one.
Security requirements, there's different

security requirements for here
versus Europe.

So you have to really go into the details,
you know, licensing issues.

There are multiple licensing types 
for open-source software,

which one are you going to use?
So these all have to be considered

during a requirements phase as
constraints on the problem,

these limit the degrees of freedom
so you need to consider these early

during this phase.

The next thing you want to do is 
separate the problem from the solution.

You have the problem situation,
you need to obviously create a

problem statement and implementation
statement and then that's going to be used

ultimately for verification, the
implementation, definition back to the

problem statement to make sure you're
building what you were told to build

and then there's going to be a validation
step back to the problem situation

to make sure you're actually
solving problem.

There will be some correctness
and correspondence relationships

between the problem statement 
and the problem situation

to the system and we will -- but it first
starts with, rather than proposing

the solution, first separate problem
situation and look at it from top-down.

The most obvious problem might not be
the one that you need to solve,

so that's why it's good to separate 
the problem first,

look at it independently,
discuss the problem statement

with your stakeholders, and look at 
the different design choices.

So, again, the most obvious problem may not
be the one you're actually trying to solve.

You want to check for the solution
correctly solves the stated problem.

But, also, check that
the problem statement

corresponds to the real needs
of the stakeholders.

Problems can be separated
in different ways.

For example, let's consider this one
requirement.

You want to prevent unauthorized access
to a University of Texas machine.

Well, we can separate this into different
domains.

On the left, you see the application
domain.

These are the things that the machine --
the computer, cannot observe directly.

Like, students, intruders, sysadmin,
signed forms, even stickies

with your password on them.

This is in, I'll call this the real world
domain, or the application domain.

On the right-hand side is
the machine domain.

This is where your software is going
to run things that are private

to the machine.

The encryption algorithms, the password
files, etc.

And then the that thing in the middle --
the shared things --

Think of this almost as the interphase
requirements for the system.

Where you need to deal with things, like
T-cards, or passwords, or user names,

or things being typed at the keyboard.
Shared things between the real world,

and the machine.

Normally in the form of the user
interphase,

and this is where we also begin to think
about our user interphase requirements.

So, now we can think of these domain
properties, and requirements, on the left.

Again, that's the application domain.
That's where we have domain properties,

and requirements.

Domain properties, think of them as things
in the application domain that remain true

whether or not we ever build the system.

You know the sun's going to come up,
and the sun's going to set.

These things are true regardless of
whether we ever build a system or not.

The requirements are the things in
the application domain

that we want to be true by delivering
on the system we're proposing.

So, those are the things in the application
domain. On the right-hand side,

in the machine domain, we have
computers and we have programs.

The things that actually implement --
that control one way or the other

the application domain.
And then in the middle,

we have the specification. The specification
is a description of the behaviors

that our program has to have in order
to meet the requirements.

Normally written in terms of shared
phenomenon.

Again, things through the user interphase.

Data being passed back and forth between
the machine and the user. Things like this.

Some of that is described in
the specification.

Which is the shared phenomenon.

Now, in this application, and machine
domain, kind of Venn diagram here,

we can shift things around as well.

We can move the boundaries.

If we're building an elevator control
system, for example,

here's how that might look. The application
domain would be the real world.

You know, people waiting; people in
the elevator; people wanting

to go to a particular floor; the elevator
motors and safety rules

that are bolted to the elevator.

We have the scheduling algorithms,
and the control programs

actually running in the machine domain,
and then we have all this

overlap. All this intersection.

The elevator call buttons; the floor
request buttons; etc.

Now, we could move things from
the application domain

into the shared domain

by changing how the system's
going to behave.

We can add sensors, for example,
to detect when people are waiting.

And doing this type of thing changes
the nature of the problem being solved.

So, all this --

The application domain, the shared
domain, the machine domain,

what goes where can change based on
how we define the problem.