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.