-
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.
