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.