The problem of need-to-delivered-capability traceability is compounded by
dispersed ownership of the seven (more or less) domains.  Last year the
Department initiated a Requirements Manager Certification and Training Program
that has potential for bringing the management and oversight of the non-materiel
domains under a designated requirements manager.  Although there was good
response to the notion of a designated RM to pull together the non-materiel
domains during the program's concept phase, it hasn't come about. Consequently
we don't have a practical way of conducting capability trade studies amongst the
seven domains.

Len Sadauskas

--- In Requirements-Engineering@yahoogroups.com, Donald Firesmith <dgf@...>
wrote:
>
> If one considers the intersection of requirements with human system
integration, then personnel, training, and habitation are in the system. So your
set of domains is not the only DoD set. Also, facilities are sometime
deliverables, like the F-35 training facility.
> Don Firesmith
>
>
>
> UNCLASSIFIED
>
> I want to further explore Jerry's conclusion, below, that "There will be
> levels of languages. Some of which have audience of business
> stakeholders and users."
>
> In the Defense Department we have established several levels of
> language, each having a discipline that is evolving to accommodate
> emerging methodologies. In broad terms these levels embrace the mission
> owners and their analysts, the financiers, the engineers and managers
> within the acquisition community, and the end users who will employ the
> system to achieve the desired mission outcome.
>
> If we agree that the scope of our definition of requirements includes
> the mission owner's needs, then we can explore the interface between the
> language of the business analyst and the requirements engineer. We
> require the business analyst to provide a validated statement of need
> and measures that will enable an assessment of how well the resulting
> system met those needs, all in natural language. The statement of need
> includes the task(s) that the mission owner wants to accomplish and the
> measures that quantifiably describe the outcome of each task(s). The
> next language is that of the requirements engineers who develop
> alternative solutions to each of the tasks and produce a functional
> description of a preferred solution for management decision. Other
> languages come into play as design and deployment proceed.
>
> The problem I am working on is the traceability of the design and
> functional requirements to the need statement. We describe the needed
> outcome in terms of procedural and cultural changes to seven variables:
> Doctrine, organization, training, materiel(the system), leadership and
> education, personnel, and facilities (DOTMLPF). From a systems
> engineering perspective, each is in the trade space, but only the
> materiel portion is reflected in the system requirements and subsequent
> contract specifications. My thought is to describe the outcome vector
> in terms of these seven variables and then allocate the desired outcome
> to each. Execution could be through a series of trade studies as the
> knowledge for each variable becomes actionable, but that would further
> complicate what is already a complex acquisition process.
>
> How do other agencies and industry deal with traceability of needs to
> system requirements?
>
> Wishing all a pleasant holiday,
>
> Leonard Sadauskas
>
> -----Original Message-----
> From:
Requirements-Engineering@yahoogroups.com<mailto:Requirements-Engineering%40yahoo\
groups.com>
>
[mailto:Requirements-Engineering@yahoogroups.com<mailto:Requirements-Engineering\
%40yahoogroups.com>] On Behalf Of Jerry Zhu
> Sent: Sunday, November 22, 2009 2:44 PM
> To:
Requirements-Engineering@yahoogroups.com<mailto:Requirements-Engineering%40yahoo\
groups.com>
> Subject: Re: {Requirements-Engineering} Re: are requirements measurable?
>
> Capers meant attributes, not features, of requirements. Requirements are
> defined as features of software. Features of requirements sounds like
> requirements of requirements. I like this concept of levels that is
> negelected in theory and practice. "If not absurd at the begining, there
> is no hope." Einstein.
>
> A quick conclusion is that software engineering is indeed a branch of
> mathematics whose underlying disciplines are logic and
> organization/business disciplines. As I said many times in many places,
> software engineering today is civil engineering before Newton. Roman
> engineers wont understand Newtonian sciences we are immersed in today.
> Science and technology are two wheels of any matural engineering.
> Software engineering, still in its infancy as a field with only
> technology, is guesswork rather than scientific work. It does not mean
> that software engineering will never become scientific discipline. One
> needs to study history of engineering at least to discuss this, Better
> to study philosohy of science, philosophy of technology, history of
> science and history of technology to have deeper analysis. Those who do
> not know history cannot know future.
>
> Requirements are functions of software under development. We want to
> measure software to know what functions to be implemented. In the same
> way we provide speed, acceleration of a sports car as requirements
> before designing it. My point is that we can not have the measurement
> (mathematically) directly to know the functions for business/enterprise
> software to be developed. That is what software engineering is doing
> today, trying to know the unknowable, measure the unmeasureable. A
> popular way is to develop through trial and error a working version to
> be able to measure what are needed and continuously revise. Much like
> Roman engineers who built many adquates and bridges within margin of
> error. At the same time they pursued the hieght of apparment houses many
> of them collapsed.
>
> Roman engineers applied opinions (the cross section of a beam, for
> example) whereby technical solution was found. Modern civil engineers
> apply scientific knowledge where technical solutions are derived. There
> is definitely order and regularity of any phenomenon men can come to
> understand, Indeed, without order and regularity, the concept of science
> is impossible. For any well established organizations, there are order
> and regularity men can understand..such as the types of products and
> services, customers whose lifecycles are much longer than lifecycles of
> software projects.
>
> In the near future, we shall not speak natural laugnages to describe
> enterprise software ( we may do now), but scientific languages. There
> will be levels of languages. Some of which have audience of business
> stakeholders and users. We must have different languages with
> presupposing disciplines designed for different audience. To achieve
> this goal, we need to attempt an exposition of the fundamental
> principles that are to be applied in the construction of logic and
> mathematics. The evaluation and analysis of such principles are the
> tasks of a special discipline, called methodology of deductive science
> or the methodology of mathematics. It is through this discipline we
> construct the scientific discipline of requirements engineering. The
> actual meaning the discipline refers to is not needed in constructing
> such a discipline.
>
> Jerry Zhu
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

Hi, Umar


>  Can you guys please give you input and help me? Following are
> the topics:
> 1 - Requirement Traceablity

http://www.cmcrossroads.com/agile-scm/6685-the-trouble-with-tracing-traceability\
-dissected

...might give you a few useful leads to follow when pondering
your approach.

Paul Oldfield
Capgemini

IEEE defintion may refer conditions as precoditions, the concept in use case
modeling.

Functional and quality requirements are two sides of the same coin. Now we also
have nonfunctional requirements like availability, security, safety etc.

Jerry




________________________________
From: Roger L. Cauvin <roger@...>
To: Requirements-Engineering@yahoogroups.com
Sent: Wed, November 25, 2009 9:56:34 AM
Subject: {Requirements-Engineering} Re: are requirements measurable?

 
Jerry Zhu wrote:

> I did not put forward a requirements definition but
> use that of IEEE and UP, behavior and quality
> requirements.

Actually, the very first sentence you wrote in this discussion was:

> Requirements are typically defined as what the system
> should do, referred to as functional requirements.

As you can see, you equated "requirement" with "functional requirement" and
neglected quality/nonfunction al requirements (what the system should "be").

> Your definition did not help me, a requirements
> engineer, with my job. I know i need to figure
> out what stakeholder to talk about what problem.
> So what you tell me? IEEE definition is helpful.

Yet your criticism of my definition was that it gave you no guidance about which
stakeholders form the basis of requirements. The IEEE definition you hold up as
so helpful is subject to the exact same criticism. It gives you no help in
deciding which stakeholder or which needs form the basis for requirements. (It
also suffers from another flaw, and I cited a blog entry that describes it.)

> The capability is offered by the product, called
> functions.

It certainly does simplify matters for you to focus on "capabilities" and equate
them with functions. However, it completely ignores "conditions" (mentioned in
the IEEE definition, but not by you) that can represent nonfunctional
requirements.

--
Roger L. Cauvin
@rcauvin (Twitter)
cauvin.blogspot. com (blog)




[Non-text portions of this message have been removed]

Leonard,

I discuss below.

________________________________
From: "Sadauskas, Leonard, CTR, NII/DoD-CIO" Leonard.Sadauskas.ctr@...
 
UNCLASSIFIED

I want to further explore Jerry's conclusion, below, that "There will belevels
of languages. Some of which have audience of business stakeholders and users."

In the Defense Department we have established several levels of language, each
having a discipline that is evolving to accommodate emerging methodologies. In
broad terms these levels embrace the mission
owners and their analysts, the financiers, the engineers and managers within the
acquisition community, and the end users who will employ the system to achieve
the desired mission outcome.

<Jerry> I see three levels here. The context of mission owners..I call it
customer (outside of, receive value from, the org) level. Next is business
level, the tasks performed by the org units to meet mission owner needs, or
delivering value to the customers. Still next is the agent level, where users
interact with the system to realize the tasks that realize mission
outcomes. The three levels are modeled as customer, business and agent models
respectively. Customer model describes mission outcome and business model
describe tasks that realize customer model. Agent model describe usrs and system
interactions that realize business model. <Jerry>

If we agree that the scope of our definition of requirements includes the
mission owner's needs, then we can explore the interface between the language of
the business analyst and the requirements engineer.

<J> Certainly we can define requirements as such, but it conflicts with IEEE
definition and flatten out the levels. Requirements are specifications of the
system done by systems analysts. Business analysts specify the business, not
the system. The deliverable of business analysis is business model. System
analysts subclass or refine, or implement business model into agent model that
contain use cases, UI prototypes, data model and quality/nonfunctional
requirements.  the creation of each of the three models require a
discipline. <Customer model, business model> constitutes an axiom system
where customer model contains axioms and business model contains theorems
logically proved. The customer model is described in natural language, while
the discipline of creating business model requires organizational theory as the
preceding discipline. <business model, agent model> is next level axiom system
with BM containing axioms and AM contains
  theorems logically proved. We can continue to have <AM, PIM>.  PIM as platform
indepent model the discipline has OO modeling as preceding discipline<Jerry>

We require the business analyst to provide a validated statement of need and
measures that will enable an assessment of how well the resulting system met
those needs, all in natural language. The statement of need
includes the task(s) that the mission owner wants to accomplish and the measures
that quantifiably describe the outcome of each task(s). The next language is
that of the requirements engineers who develop alternative solutions to each of
the tasks and produce a functional description of a preferred solution for
management decision. Other languages come into play as design and deployment
proceed.

The problem I am working on is the traceability of the design and functional
requirements to the need statement.

<J> Traceability describes relationship between CM, BM, AM, and PIM models.
Many create artiftacts at different levels and connect them after. It is
like producing design documentation after the design is done. The CM, BM and
AM are quantatively constructed based on the relationship
between levels. Therefore tracebility goes before model artifact
creation not the other way around. Tracebility matrix is not manually created
but generated by the tool. <J>  


We describe the needed outcome in terms of procedural and cultural changes to
seven variables:
Doctrine, organization, training, materiel(the system), leadership and
education, personnel, and facilities (DOTMLPF). From a systems engineering
perspective, each is in the trade space, but only the
materiel portion is reflected in the system requirements and subsequent contract
specifications. My thought is to describe the outcome vector in terms of these
seven variables and then allocate the desired outcome
to each. Execution could be through a series of trade studies as the knowledge
for each variable becomes actionable, but that would further complicate what is
already a complex acquisition process.

<J> we are talking about customer model here. The first thing to do by the gov
program people is to define the boundary of the business model. Who are
customers, how the business outcome is defined that relates to the system to be
developed? What values are to be created by mission owners that are relevant? We
must draw a boundary clearly here. The boudary and the CM should be created by
program people and put into the RFPs. How much does that resonate to you?
<J>

Jerry
-----Original Message-----
From: Requirements- Engineering@ yahoogroups. com
[mailto:Requirements- Engineering@ yahoogroups. com] On Behalf Of Jerry Zhu
Sent: Sunday, November 22, 2009 2:44 PM
To: Requirements- Engineering@ yahoogroups. com
Subject: Re: {Requirements- Engineering} Re: are requirements measurable?

Capers meant attributes, not features, of requirements. Requirements are
defined as features of software. Features of requirements sounds like
requirements of requirements. I like this concept of levels that is
negelected in theory and practice. "If not absurd at the begining, there
is no hope." Einstein.

A quick conclusion is that software engineering is indeed a branch of
mathematics whose underlying disciplines are logic and
organization/ business disciplines. As I said many times in many places,
software engineering today is civil engineering before Newton. Roman
engineers wont understand Newtonian sciences we are immersed in today.
Science and technology are two wheels of any matural engineering.
Software engineering, still in its infancy as a field with only
technology, is guesswork rather than scientific work. It does not mean
that software engineering will never become scientific discipline. One
needs to study history of engineering at least to discuss this, Better
to study philosohy of science, philosophy of technology, history of
science and history of technology to have deeper analysis. Those who do
not know history cannot know future.

Requirements are functions of software under development. We want to
measure software to know what functions to be implemented. In the same
way we provide speed, acceleration of a sports car as requirements
before designing it. My point is that we can not have the measurement
(mathematically) directly to know the functions for business/enterprise
software to be developed. That is what software engineering is doing
today, trying to know the unknowable, measure the unmeasureable. A
popular way is to develop through trial and error a working version to
be able to measure what are needed and continuously revise. Much like
Roman engineers who built many adquates and bridges within margin of
error. At the same time they pursued the hieght of apparment houses many
of them collapsed.

Roman engineers applied opinions (the cross section of a beam, for
example) whereby technical solution was found. Modern civil engineers
apply scientific knowledge where technical solutions are derived. There
is definitely order and regularity of any phenomenon men can come to
understand, Indeed, without order and regularity, the concept of science
is impossible. For any well established organizations, there are order
and regularity men can understand.. such as the types of products and
services, customers whose lifecycles are much longer than lifecycles of
software projects.

In the near future, we shall not speak natural laugnages to describe
enterprise software ( we may do now), but scientific languages. There
will be levels of languages. Some of which have audience of business
stakeholders and users. We must have different languages with
presupposing disciplines designed for different audience. To achieve
this goal, we need to attempt an exposition of the fundamental
principles that are to be applied in the construction of logic and
mathematics. The evaluation and analysis of such principles are the
tasks of a special discipline, called methodology of deductive science
or the methodology of mathematics. It is through this discipline we
construct the scientific discipline of requirements engineering. The
actual meaning the discipline refers to is not needed in constructing
such a discipline.

Jerry Zhu




[Non-text portions of this message have been removed]

Because the requirements have many different stakeholders with different needs,
they need different requirements specifications. Luckily the advent of
requirements tools and databases enable different specs for different
stakeholders to be automatically generated using templates and metadata. This
helps with the different languages, but does not solve it.
Don Firesmith

________________________________
From: Requirements-Engineering@yahoogroups.com
<Requirements-Engineering@yahoogroups.com>
To: Requirements-Engineering@yahoogroups.com
<Requirements-Engineering@yahoogroups.com>
Sent: Wed Nov 25 14:02:06 2009
Subject: RE: {Requirements-Engineering} Re: are requirements measurable? (U)



UNCLASSIFIED

I want to further explore Jerry's conclusion, below, that "There will be
levels of languages. Some of which have audience of business
stakeholders and users."

In the Defense Department we have established several levels of
language, each having a discipline that is evolving to accommodate
emerging methodologies. In broad terms these levels embrace the mission
owners and their analysts, the financiers, the engineers and managers
within the acquisition community, and the end users who will employ the
system to achieve the desired mission outcome.

If we agree that the scope of our definition of requirements includes
the mission owner's needs, then we can explore the interface between the
language of the business analyst and the requirements engineer. We
require the business analyst to provide a validated statement of need
and measures that will enable an assessment of how well the resulting
system met those needs, all in natural language. The statement of need
includes the task(s) that the mission owner wants to accomplish and the
measures that quantifiably describe the outcome of each task(s). The
next language is that of the requirements engineers who develop
alternative solutions to each of the tasks and produce a functional
description of a preferred solution for management decision. Other
languages come into play as design and deployment proceed.

The problem I am working on is the traceability of the design and
functional requirements to the need statement. We describe the needed
outcome in terms of procedural and cultural changes to seven variables:
Doctrine, organization, training, materiel(the system), leadership and
education, personnel, and facilities (DOTMLPF). From a systems
engineering perspective, each is in the trade space, but only the
materiel portion is reflected in the system requirements and subsequent
contract specifications. My thought is to describe the outcome vector
in terms of these seven variables and then allocate the desired outcome
to each. Execution could be through a series of trade studies as the
knowledge for each variable becomes actionable, but that would further
complicate what is already a complex acquisition process.

How do other agencies and industry deal with traceability of needs to
system requirements?

Wishing all a pleasant holiday,

Leonard Sadauskas

-----Original Message-----
From:
Requirements-Engineering@yahoogroups.com<mailto:Requirements-Engineering%40yahoo\
groups.com>
[mailto:Requirements-Engineering@yahoogroups.com<mailto:Requirements-Engineering\
%40yahoogroups.com>] On Behalf Of Jerry Zhu
Sent: Sunday, November 22, 2009 2:44 PM
To:
Requirements-Engineering@yahoogroups.com<mailto:Requirements-Engineering%40yahoo\
groups.com>
Subject: Re: {Requirements-Engineering} Re: are requirements measurable?

Capers meant attributes, not features, of requirements. Requirements are
defined as features of software. Features of requirements sounds like
requirements of requirements. I like this concept of levels that is
negelected in theory and practice. "If not absurd at the begining, there
is no hope." Einstein.

A quick conclusion is that software engineering is indeed a branch of
mathematics whose underlying disciplines are logic and
organization/business disciplines. As I said many times in many places,
software engineering today is civil engineering before Newton. Roman
engineers wont understand Newtonian sciences we are immersed in today.
Science and technology are two wheels of any matural engineering.
Software engineering, still in its infancy as a field with only
technology, is guesswork rather than scientific work. It does not mean
that software engineering will never become scientific discipline. One
needs to study history of engineering at least to discuss this, Better
to study philosohy of science, philosophy of technology, history of
science and history of technology to have deeper analysis. Those who do
not know history cannot know future.

Requirements are functions of software under development. We want to
measure software to know what functions to be implemented. In the same
way we provide speed, acceleration of a sports car as requirements
before designing it. My point is that we can not have the measurement
(mathematically) directly to know the functions for business/enterprise
software to be developed. That is what software engineering is doing
today, trying to know the unknowable, measure the unmeasureable. A
popular way is to develop through trial and error a working version to
be able to measure what are needed and continuously revise. Much like
Roman engineers who built many adquates and bridges within margin of
error. At the same time they pursued the hieght of apparment houses many
of them collapsed.

Roman engineers applied opinions (the cross section of a beam, for
example) whereby technical solution was found. Modern civil engineers
apply scientific knowledge where technical solutions are derived. There
is definitely order and regularity of any phenomenon men can come to
understand, Indeed, without order and regularity, the concept of science
is impossible. For any well established organizations, there are order
and regularity men can understand..such as the types of products and
services, customers whose lifecycles are much longer than lifecycles of
software projects.

In the near future, we shall not speak natural laugnages to describe
enterprise software ( we may do now), but scientific languages. There
will be levels of languages. Some of which have audience of business
stakeholders and users. We must have different languages with
presupposing disciplines designed for different audience. To achieve
this goal, we need to attempt an exposition of the fundamental
principles that are to be applied in the construction of logic and
mathematics. The evaluation and analysis of such principles are the
tasks of a special discipline, called methodology of deductive science
or the methodology of mathematics. It is through this discipline we
construct the scientific discipline of requirements engineering. The
actual meaning the discipline refers to is not needed in constructing
such a discipline.

Jerry Zhu





[Non-text portions of this message have been removed]

If one considers the intersection of requirements with human system integration,
then personnel, training, and habitation are in the system. So your set of
domains is not the only DoD set. Also, facilities are sometime deliverables,
like the F-35 training facility.
Don Firesmith

________________________________
From: Requirements-Engineering@yahoogroups.com
<Requirements-Engineering@yahoogroups.com>
To: Requirements-Engineering@yahoogroups.com
<Requirements-Engineering@yahoogroups.com>
Sent: Wed Nov 25 14:02:06 2009
Subject: RE: {Requirements-Engineering} Re: are requirements measurable? (U)



UNCLASSIFIED

I want to further explore Jerry's conclusion, below, that "There will be
levels of languages. Some of which have audience of business
stakeholders and users."

In the Defense Department we have established several levels of
language, each having a discipline that is evolving to accommodate
emerging methodologies. In broad terms these levels embrace the mission
owners and their analysts, the financiers, the engineers and managers
within the acquisition community, and the end users who will employ the
system to achieve the desired mission outcome.

If we agree that the scope of our definition of requirements includes
the mission owner's needs, then we can explore the interface between the
language of the business analyst and the requirements engineer. We
require the business analyst to provide a validated statement of need
and measures that will enable an assessment of how well the resulting
system met those needs, all in natural language. The statement of need
includes the task(s) that the mission owner wants to accomplish and the
measures that quantifiably describe the outcome of each task(s). The
next language is that of the requirements engineers who develop
alternative solutions to each of the tasks and produce a functional
description of a preferred solution for management decision. Other
languages come into play as design and deployment proceed.

The problem I am working on is the traceability of the design and
functional requirements to the need statement. We describe the needed
outcome in terms of procedural and cultural changes to seven variables:
Doctrine, organization, training, materiel(the system), leadership and
education, personnel, and facilities (DOTMLPF). From a systems
engineering perspective, each is in the trade space, but only the
materiel portion is reflected in the system requirements and subsequent
contract specifications. My thought is to describe the outcome vector
in terms of these seven variables and then allocate the desired outcome
to each. Execution could be through a series of trade studies as the
knowledge for each variable becomes actionable, but that would further
complicate what is already a complex acquisition process.

How do other agencies and industry deal with traceability of needs to
system requirements?

Wishing all a pleasant holiday,

Leonard Sadauskas

-----Original Message-----
From:
Requirements-Engineering@yahoogroups.com<mailto:Requirements-Engineering%40yahoo\
groups.com>
[mailto:Requirements-Engineering@yahoogroups.com<mailto:Requirements-Engineering\
%40yahoogroups.com>] On Behalf Of Jerry Zhu
Sent: Sunday, November 22, 2009 2:44 PM
To:
Requirements-Engineering@yahoogroups.com<mailto:Requirements-Engineering%40yahoo\
groups.com>
Subject: Re: {Requirements-Engineering} Re: are requirements measurable?

Capers meant attributes, not features, of requirements. Requirements are
defined as features of software. Features of requirements sounds like
requirements of requirements. I like this concept of levels that is
negelected in theory and practice. "If not absurd at the begining, there
is no hope." Einstein.

A quick conclusion is that software engineering is indeed a branch of
mathematics whose underlying disciplines are logic and
organization/business disciplines. As I said many times in many places,
software engineering today is civil engineering before Newton. Roman
engineers wont understand Newtonian sciences we are immersed in today.
Science and technology are two wheels of any matural engineering.
Software engineering, still in its infancy as a field with only
technology, is guesswork rather than scientific work. It does not mean
that software engineering will never become scientific discipline. One
needs to study history of engineering at least to discuss this, Better
to study philosohy of science, philosophy of technology, history of
science and history of technology to have deeper analysis. Those who do
not know history cannot know future.

Requirements are functions of software under development. We want to
measure software to know what functions to be implemented. In the same
way we provide speed, acceleration of a sports car as requirements
before designing it. My point is that we can not have the measurement
(mathematically) directly to know the functions for business/enterprise
software to be developed. That is what software engineering is doing
today, trying to know the unknowable, measure the unmeasureable. A
popular way is to develop through trial and error a working version to
be able to measure what are needed and continuously revise. Much like
Roman engineers who built many adquates and bridges within margin of
error. At the same time they pursued the hieght of apparment houses many
of them collapsed.

Roman engineers applied opinions (the cross section of a beam, for
example) whereby technical solution was found. Modern civil engineers
apply scientific knowledge where technical solutions are derived. There
is definitely order and regularity of any phenomenon men can come to
understand, Indeed, without order and regularity, the concept of science
is impossible. For any well established organizations, there are order
and regularity men can understand..such as the types of products and
services, customers whose lifecycles are much longer than lifecycles of
software projects.

In the near future, we shall not speak natural laugnages to describe
enterprise software ( we may do now), but scientific languages. There
will be levels of languages. Some of which have audience of business
stakeholders and users. We must have different languages with
presupposing disciplines designed for different audience. To achieve
this goal, we need to attempt an exposition of the fundamental
principles that are to be applied in the construction of logic and
mathematics. The evaluation and analysis of such principles are the
tasks of a special discipline, called methodology of deductive science
or the methodology of mathematics. It is through this discipline we
construct the scientific discipline of requirements engineering. The
actual meaning the discipline refers to is not needed in constructing
such a discipline.

Jerry Zhu





[Non-text portions of this message have been removed]

UNCLASSIFIED

I want to further explore Jerry's conclusion, below, that "There will be
levels of languages. Some of which have audience of business
stakeholders and users."

In the Defense Department we have established several levels of
language, each having a discipline that is evolving to accommodate
emerging methodologies. In broad terms these levels embrace the mission
owners and their analysts, the financiers, the engineers and managers
within the acquisition community, and the end users who will employ the
system to achieve the desired mission outcome.

If we agree that the scope of our definition of requirements includes
the mission owner's needs, then we can explore the interface between the
language of the business analyst and the requirements engineer.  We
require the business analyst to provide a validated statement of need
and measures that will enable an assessment of how well the resulting
system met those needs, all in natural language.  The statement of need
includes the task(s) that the mission owner wants to accomplish and the
measures that quantifiably describe the outcome of each task(s).  The
next language is that of the requirements engineers who develop
alternative solutions to each of the tasks and produce a functional
description of a preferred solution for management decision. Other
languages come into play as design and deployment proceed.

The problem I am working on is the traceability of the design and
functional requirements to the need statement.  We describe the needed
outcome in terms of procedural and cultural changes to seven variables:
Doctrine, organization, training, materiel(the system), leadership and
education, personnel, and facilities (DOTMLPF).  From a systems
engineering perspective, each is in the trade space, but only the
materiel portion is reflected in the system requirements and subsequent
contract specifications.  My thought is to describe the outcome vector
in terms of these seven variables and then allocate the desired outcome
to each.  Execution could be through a series of trade studies as the
knowledge for each variable becomes actionable, but that would further
complicate what is already a complex acquisition process.

How do other agencies and industry deal with traceability of needs to
system requirements?

Wishing all a pleasant holiday,

Leonard Sadauskas



-----Original Message-----
From: Requirements-Engineering@yahoogroups.com
[mailto:Requirements-Engineering@yahoogroups.com] On Behalf Of Jerry Zhu
Sent: Sunday, November 22, 2009 2:44 PM
To: Requirements-Engineering@yahoogroups.com
Subject: Re: {Requirements-Engineering} Re: are requirements measurable?



Capers meant attributes, not features, of requirements. Requirements are
defined as features of software. Features of requirements sounds like
requirements of requirements. I like this concept of levels that is
negelected in theory and practice. "If not absurd at the begining, there
is no hope." Einstein.

A quick conclusion is that software engineering is indeed a branch of
mathematics whose underlying disciplines are logic and
organization/business disciplines. As I said many times in many places,
software engineering today is civil engineering before Newton. Roman
engineers wont understand Newtonian sciences we are immersed in today.
Science and technology are two wheels of any matural engineering.
Software engineering, still in its infancy as a field with only
technology, is guesswork rather than scientific work. It does not mean
that software engineering will never become scientific discipline. One
needs to study history of engineering at least to discuss this, Better
to study philosohy of science, philosophy of technology, history of
science and history of technology to have deeper analysis. Those who do
not know history cannot know future.

Requirements are functions of software under development. We want to
measure software to know what functions to be implemented. In the same
way we provide speed, acceleration of a sports car as requirements
before designing it. My point is that we can not have the measurement
(mathematically) directly to know the functions for business/enterprise
software to be developed. That is what software engineering is doing
today, trying to know the unknowable, measure the unmeasureable. A
popular way is to develop through trial and error  a working version to
be able to measure what are needed and continuously revise. Much like
Roman engineers who built many adquates and bridges within margin of
error. At the same time they pursued the hieght of apparment houses many
of them collapsed.

Roman engineers applied opinions (the cross section of a beam, for
example) whereby technical solution was found. Modern civil engineers
apply scientific knowledge where technical solutions are derived. There
is definitely order and regularity of any phenomenon men can come to
understand, Indeed, without order and regularity, the concept of science
is impossible. For any well established organizations, there are order
and regularity men can understand..such as the types of products and
services, customers whose lifecycles are much longer than lifecycles of
software projects.

In the near future, we shall not speak natural laugnages to describe
enterprise software ( we may do now), but scientific languages. There
will be levels of languages. Some of which have audience of business
stakeholders and users. We must have different languages with
presupposing disciplines designed for different audience. To achieve
this goal, we need to attempt an exposition of the fundamental
principles that are to be applied in the construction of logic and
mathematics. The evaluation and analysis of such principles are the
tasks of a special discipline, called methodology of deductive science
or the methodology of mathematics. It is through this discipline we
construct the scientific discipline of requirements engineering. The
actual meaning the discipline refers to is not needed in constructing
such a discipline.

Jerry Zhu

Jerry Zhu wrote:

> I did not put forward a requirements definition but
> use that of IEEE and UP, behavior and quality
> requirements.

Actually, the very first sentence you wrote in this discussion was:

> Requirements are typically defined as what the system
> should do, referred to as functional requirements.

As you can see, you equated "requirement" with "functional requirement" and
neglected quality/nonfunctional requirements (what the system should "be").

> Your definition did not help me, a requirements
> engineer, with my job. I know i need to figure
> out what stakeholder to talk about what problem.
> So what you tell me? IEEE definition is helpful.

Yet your criticism of my definition was that it gave you no guidance about which
stakeholders form the basis of requirements.  The IEEE definition you hold up as
so helpful is subject to the exact same criticism.  It gives you no help in
deciding which stakeholder or which needs form the basis for requirements.  (It
also suffers from another flaw, and I cited a blog entry that describes it.)

> The capability is offered by the product, called
> functions.

It certainly does simplify matters for you to focus on "capabilities" and equate
them with functions.  However, it completely ignores "conditions" (mentioned in
the IEEE definition, but not by you) that can represent nonfunctional
requirements.

--
Roger L. Cauvin
@rcauvin (Twitter)
cauvin.blogspot.com (blog)

I will be out of the office starting Wed 11/25/2009 and will not return
until Mon 11/30/2009.

I will respond to your message when I return.

I will be out of the office starting  11/24/2009 and will not return until
11/30/2009.

I will be out of the office from Wednesday Nov 25 and returning Monday Nov
30.  I will have very limited   access to email during my absence.  For
urgent matters, Please contact  my  assistant  Sally Hulett at
512-473-8115. Thank you.

[Non-text portions of this message have been removed]

Roger,

I did not put forward a requirements definition but use that of IEEE and UP,
behavior and quality requirements.

Your definition did not help me, a requirements engineer, with my job. I know i
need to figure out what stakeholder to talk about what problem. So what you tell
me? IEEE definition is helpful. It clearly defines the boundary of the software
system. Requirements are in the context of the product, the capability needed by
the users. The capability is offered by the product, called functions. The
function of the product is the function of the whole, none of the parts has.
Requirements are system level properties not properties of the parts.
Requrements are not anything higher than the users, such as business
processes. Requirements come from the immediate context of the system. This
explanation of IEEE and UP's definition help me well with my work.

Jerry

  


 



________________________________
From: Roger L. Cauvin <roger@...>
To: Requirements-Engineering@yahoogroups.com
Sent: Tue, November 24, 2009 9:02:43 AM
Subject: {Requirements-Engineering} RE: are requirements measurable?

 
Jerry Zhu wrote:

> Your definition covers lots of ground. Stakeholder and
> problem. Every body is a stakeholder and what problem?
> Is it global warming problem or world hunger problem or
> high unemployment rate problem?

Fair criticism. However, the requirements analyst's job is to determine which
stakeholders to consider and which problems to solve.

> IEEE and Unified Process limit requirements as the
> needed behavior and way of behaving of the software
> No more and no less.

Hah! What behavior is "needed", and who needs it? Not only does the IEEE have
the exact same drawback you ascribed to mine, but it suffers the additional flaw
I described here:

http://cauvin. blogspot. com/2006/ 02/ieee-definiti on-of-requiremen t.html

> If we put a adjectives before requirements, we category
> them into different kinds of behaviors.

It's interesting that you quoted the Wikipedia entry earlier but neglected to
mention the first sentence:

"[A] requirement is a singular documented need of what a particular product or
service should be or perform."

At the outset of this discussion, you characterized a requirement only as what a
system should do and left out what the system should be. In other words, some
requirements ("nonfunctional" ) are not "behaviors" but are attributes/conditio
ns the system must exhibit.

--
Roger L. Cauvin
@rcauvin (Twitter)
cauvin.blogspot. com (blog)




[Non-text portions of this message have been removed]

Jerry Zhu wrote:

> Your definition covers lots of ground. Stakeholder and
> problem. Every body is a stakeholder and what problem?
> Is it global warming problem or world hunger problem or
> high unemployment rate problem?

Fair criticism.  However, the requirements analyst's job is to determine which
stakeholders to consider and which problems to solve.

> IEEE and Unified Process limit requirements as the
> needed behavior and way of behaving of the software
> No more and no less.

Hah! What behavior is "needed", and who needs it?  Not only does the IEEE have
the exact same drawback you ascribed to mine, but it suffers the additional flaw
I described here:

http://cauvin.blogspot.com/2006/02/ieee-definition-of-requirement.html

> If we put a adjectives before requirements, we category
> them into different kinds of behaviors.

It's interesting that you quoted the Wikipedia entry earlier but neglected to
mention the first sentence:

"[A] requirement is a singular documented need of what a particular product or
service should be or perform."

At the outset of this discussion, you characterized a requirement only as what a
system should do and left out what the system should be.  In other words, some
requirements ("nonfunctional") are not "behaviors" but are attributes/conditions
the system must exhibit.

--
Roger L. Cauvin
@rcauvin (Twitter)
cauvin.blogspot.com (blog)

Here is a view of mine on the measures for requirements.

The measure of requirements is a need of the enduser (or customer or business as
relevant to the context). I expect it to be in the units that a end-user can
understand. We have seen many measures that reflect what it takes to engineer
the requirements.

ost of Engineering in $ terms or efforts or schedule are expected by the end
user. Yes, these are also used by the engineering team for managing the process.
However, these are the measures that the end users many times used to make
decisions.

The same requirement has a measure in function points from a developer point of
view. Defect density from a tester point of view.

We probably need a conversion methodology among these various measures and that
I have not come across much.

Another aspect on Requirements vs Features is that we tended to use them equal.
However, I personally held a view that a feature provides a few more details
than a requirement. Requirement is a description of a basic need, whereas,
feature details some background and the value of the realization to the business
and the contexts of its use.

This discussion is very interesting.

Hi All,
How are you? I am Master leadings to PhD student. I have been given two topic to
select for my thesis. I am little bit confused. Can you guys please give you
input and help me? Following are the topics:
1 - Requirement Traceablity
2 - Requirement Verification & Validation

My question is, I want to go in industry after completing my degree. As all of
you guys are more expericiend than me. So please guide me which area would be
good for me to start and get expertise?
When you answer, please let me know that which could interesting question.
Thanks,
Umar

Roger,

Your definition covers lots of ground. Stakeholder and problem. Every body is a
stakeholder and what problem? Is it global warming problem or world hunger
problem or high unemployment rate problem?

IEEE and Unified Process limit requirements as the needed behavior and way of
behaving of the software. No more and no less. If we put a adjectives before
requirements, we category them into different kinds of behaviors.

Jerry




________________________________
From: Roger L. Cauvin <roger@...>
To: Requirements-Engineering@yahoogroups.com
Sent: Mon, November 23, 2009 10:10:27 AM
Subject: {Requirements-Engineering} RE: are requirements measurable?

 

Jerry Zhu wrote:

> In software engineering, “requirements” are typically defined
> as what the system should do, as explained by Wikipedia: “In
> systems engineering, a requirement can be a description of what
> a system must do, referred to as a functional requirement. This
> type of requirements specifies something that the delivered
> system must be able to do. Another type of requirements
> specifies something about the system itself, and how well it
> performs its functions. Such requirements are often called
> nonfunctional requirements, or ‘quality of service
> requirements.’ Examples of such requirements include
> availability, testability, maintainability, and ease of use.”

Note that "what the system should do" describes only one type of requirement in
the Wikipedia definition. In your original message, you wrote:

> Requirements are typically defined as what the system should
> do, referred to as functional requirements.

I'm not sure whether you did so inadvertently, but this statement equates
"requirement" with "functional requirement" .

My definition of requirement is:

"A requirement specifies the least stringent condition that must hold to solve
or avoid a stakeholder problem."

(The central stakeholders are typically prospective customers.)

This definition differs in a subtle but critical way from the IEEE definition,
as I wrote here:

http://cauvin. blogspot. com/2005/ 06/definition- of-requirement. html

--
Roger L. Cauvin
@rcauvin (Twitter)
cauvin.blogspot. com (blog)

Jerry Zhu wrote:

> In software engineering, “requirements” are typically defined
> as what the system should do, as explained by Wikipedia:  “In
> systems engineering, a requirement can be a description of what
> a system must do, referred to as a functional requirement. This
> type of requirements specifies something that the delivered
> system must be able to do. Another type of requirements
> specifies something about the system itself, and how well it
> performs its functions. Such requirements are often called
> nonfunctional requirements, or ‘quality of service
> requirements.’ Examples of such requirements include
> availability, testability, maintainability, and ease of use.”

Note that "what the system should do" describes only one type of requirement in
the Wikipedia definition.  In your original message, you wrote:

> Requirements are typically defined as what the system should
> do, referred to as functional requirements.

I'm not sure whether you did so inadvertently, but this statement equates
"requirement" with "functional requirement".

My definition of requirement is:

"A requirement specifies the least stringent condition that must hold to solve
or avoid a stakeholder problem."

(The central stakeholders are typically prospective customers.)

This definition differs in a subtle but critical way from the IEEE definition,
as I wrote here:

http://cauvin.blogspot.com/2005/06/definition-of-requirement.html

--
Roger L. Cauvin
@rcauvin (Twitter)
cauvin.blogspot.com (blog)

Don,

What you said make sense. The need for somthing and the function of that thing
may overlap however. The defining function of an automobile is to move people
from one place to another. That function may also be a need.

I used to think that current definition of requierments and software are the
cause of the problem (software industry has lots of problems civil engineering
used to have but not any more). So redefining requirements and reconceptualizing
enterprise software may be way to go. I realize that this may cause marketing
difficulties. We can still use the language as is and add on new concepts. This
not only reduces the amount of education needed but also clarifies the
relationships of different concepts of different levels. So I go by below
requirements definition on the mainstream.

In software engineering, “requirements” are typically defined as what the
system should do, as explained by Wikipedia:  “In systems engineering, a
requirement can be a description of what a system must do, referred to as a
functional requirement. This type of requirements specifies something that the
delivered system must be able to do. Another type of requirements specifies
something about the system itself, and how well it performs its functions. Such
requirements are often called nonfunctional requirements, or ‘quality of
service requirements.’ Examples of such requirements include availability,
testability, maintainability, and ease of use.”
 
Below is IEEE-610’s definition of requirement:
 
1.        A condition or capability needed by a user to solve a problem
or achieve an objective
2.        A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard, specification, or
other formally imposed document
3.        A documented representation of a condition or capability as in
1 or 2
The above definitions separate users from software or system. We often say to
install, configure systems that exclude users. The sharp distinction
of boundary of software make it easy for us to see other levels of
abstraction, such as agent and business levels. We must process information in
the order of the level of abstraction from the most abstraction to the most
concrete. In object oriented paradigm, we must know abstract class before know
the derived classes. Current software engineering text and practice donot make
sharp or scentific distinctions of levels and begin with concrete levels,
causing rework and failures. And we give ourselves excuses of requirements
change. Requirements donot change in most cases. It is our understanding of them
that keep change. The reason for which is lack of scientific knowledge to define
requirements.

Jerry



________________________________
From: Donald Firesmith <dgf@...>
To: "Requirements-Engineering@yahoogroups.com"
<Requirements-Engineering@yahoogroups.com>
Sent: Sun, November 22, 2009 4:00:17 PM
Subject: RE: {Requirements-Engineering} Re: are requirements measurable?

 
Jerry,
Requirements are not features (of software or anything else). At best,
requirements are the needs or mandate to produce a solution/system/ application
that has the required features. There is a big difference between something and
the need for (or mandate to produce) that thing.
Don Firesmith

From: Requirements- Engineering@ yahoogroups. com [mailto:Requirements-
Engineering@ yahoogroups. com] On Behalf Of Jerry Zhu
Sent: Sunday, November 22, 2009 2:44 PM
To: Requirements- Engineering@ yahoogroups. com
Subject: Re: {Requirements- Engineering} Re: are requirements measurable?



Capers meant attributes, not features, of requirements. Requirements are defined
as features of software. Features of requirements sounds like requirements of
requirements. I like this concept of levels that is negelected in theory and
practice. "If not absurd at the begining, there is no hope." Einstein.

A quick conclusion is that software engineering is indeed a branch of
mathematics whose underlying disciplines are logic and organization/ business
disciplines. As I said many times in many places, software engineering today is
civil engineering before Newton. Roman engineers wont understand Newtonian
sciences we are immersed in today. Science and technology are two wheels of any
matural engineering. Software engineering, still in its infancy as a field with
only technology, is guesswork rather than scientific work. It does not mean that
software engineering will never become scientific discipline. One needs to study
history of engineering at least to discuss this, Better to study philosohy of
science, philosophy of technology, history of science and history of technology
to have deeper analysis. Those who do not know history cannot know future.

Requirements are functions of software under development. We want to measure
software to know what functions to be implemented. In the same way we provide
speed, acceleration of a sports car as requirements before designing it. My
point is that we can not have the measurement (mathematically) directly to know
the functions for business/enterprise software to be developed. That is what
software engineering is doing today, trying to know the unknowable, measure the
unmeasureable. A popular way is to develop through trial and error a working
version to be able to measure what are needed and continuously revise. Much like
Roman engineers who built many adquates and bridges within margin of error. At
the same time they pursued the hieght of apparment houses many of them
collapsed.

Roman engineers applied opinions (the cross section of a beam, for example)
whereby technical solution was found. Modern civil engineers apply scientific
knowledge where technical solutions are derived. There is definitely order and
regularity of any phenomenon men can come to understand, Indeed, without order
and regularity, the concept of science is impossible. For any well established
organizations, there are order and regularity men can understand.. such as the
types of products and services, customers whose lifecycles are much longer than
lifecycles of software projects.

In the near future, we shall not speak natural laugnages to describe enterprise
software ( we may do now), but scientific languages. There will be levels of
languages. Some of which have audience of business stakeholders and users. We
must have different languages with presupposing disciplines designed for
different audience. To achieve this goal, we need to attempt an exposition of
the fundamental principles that are to be applied in the construction of logic
and mathematics. The evaluation and analysis of such principles are the tasks of
a special discipline, called methodology of deductive science or the methodology
of mathematics. It is through this discipline we construct the scientific
discipline of requirements engineering. The actual meaning the discipline refers
to is not needed in constructing such a discipline.

Jerry Zhu



____________ _________ _________ __
From: rwf60048 <rwferguson@gmail. com<mailto:rwferguson% 40gmail.com> >
To: Requirements- Engineering@ yahoogroups. com<mailto:Requirement
s-Engineering% 40yahoogroups. com>
Sent: Sun, November 22, 2009 1:06:37 PM
Subject: {Requirements- Engineering} Re: are requirements measurable?


Requirements have been measured many times. Capers answer is one. Basili showed
an interesting correlation at SEL when he demonstrated a 99% correlation between
familiarity and SLOC. Familiar requirements took less code than unfamiliar
requirements.

However, the idea that we can achieve 100% perfection in requirements is far
from possible and not even a reasonable ideal goal.

Requirements must be considered an agreement between customer and developer.
Since neither understands the other perfectly the requirements are not perfect
in any but the most primitive examples. Before one makes such a terrible
assumption go back an read "Understanding Computers and Cognition" by Winograd
and Flores.

The challenge of requirements (and other forms of standards and specifications)
is that we must use language to communicate them. The basis is communications
and not a formal grammar. If we intend to deal with real customers who will use
our products in domains that we do not fully understand and who's business is
changing at a pace that we cannot fully observe, THEN we must face the reality
of an incomplete definition. All our methods must deal with the reality of this
incompleteness and the concomitant changes.

The implication is not whether requirements engineering is somehow unneeded or
unimportant. Rather it means the job is not completed by a formal logic or
engineering discipline. The job requires constant checking for agreement by
whatever means we can define. It is not a matter of getting the requirements
"right". It is rather a determination of defining requirements that will achieve
customer value. Further, since the requirements must be stated in language that
the engineers use for communications, the onus is on the engineering team to
determine whether the customers understand us.

Bob Ferguson

--- In Requirements- Engineering@ yahoogroups. com, Jerry Zhu <jerryyz@... >
wrote:
>
> Hi All,
>
> Requirements are typically defined as what the system should do, referred to
as functional requirements. Measurability of requierments depends on the type of
software.
>
> There has been an increasing complexity of software over the years. Software
engineers started out with relatively simple software such as scientific
computation software and then worked up to relatively complex business software
such as that for accounting and finance. A design task involves the knowledge of
an increasing number of business disciplines. An important recent development is
that software not only includes business elements but also social elements.
Along the dimension of software, complexity increases from simple computation
software, through business software, to enterprise information systems.
>
> For business and enterprise software, requirements can not be known directly.
This can be explained by uncertainty principle we can not measure the position
and speed of a moving object at the same time. The more accruate we measure one,
the less accurate we measure the other. But we can measure position at any time
and calculate the speed and acceleration at any time precisely. This is how we
control a robot with output feedback only without measuring speed and
acceleration of the robot link torque.
>
> Requirements are measurements of speed for business software and acceleration
for enterprise software. Trying to measure unmeasurable information is the root
cause of requirements errors, rework and failure. No one knows what requirements
are, only guess them. Hence requirements engineering is guesswork.
>
> There are measureable information users do know about for business and
enterprise software from which precise, concise, stable requirements are
calculated. The process of identifying and measuring measureable information and
then deriving requirements from them transforms requirements engineering from
guesswork to scientific work. That is, we can arrive precise and stable
requirements upfront without rework and failure. It means thats Chaos report can
be changed from 34% success rate to 100% over night. All large scale enterprise
software projects will succeed without doubts.
>
> Jerry Zhu
>
> [Non-text portions of this message have been removed]
>

[Non-text portions of this message have been removed]


[Non-text portions of this message have been removed]




[Non-text portions of this message have been removed]

Jerry,
Requirements are not features (of software or anything else). At best,
requirements are the needs or mandate to produce a solution/system/application
that has the required features. There is a big difference between something and
the need for (or mandate to produce) that thing.
Don Firesmith

From: Requirements-Engineering@yahoogroups.com
[mailto:Requirements-Engineering@yahoogroups.com] On Behalf Of Jerry Zhu
Sent: Sunday, November 22, 2009 2:44 PM
To: Requirements-Engineering@yahoogroups.com
Subject: Re: {Requirements-Engineering} Re: are requirements measurable?



Capers meant attributes, not features, of requirements. Requirements are defined
as features of software. Features of requirements sounds like requirements of
requirements. I like this concept of levels that is negelected in theory and
practice. "If not absurd at the begining, there is no hope." Einstein.

A quick conclusion is that software engineering is indeed a branch of
mathematics whose underlying disciplines are logic and organization/business
disciplines. As I said many times in many places, software engineering today is
civil engineering before Newton. Roman engineers wont understand Newtonian
sciences we are immersed in today. Science and technology are two wheels of any
matural engineering. Software engineering, still in its infancy as a field with
only technology, is guesswork rather than scientific work. It does not mean that
software engineering will never become scientific discipline. One needs to study
history of engineering at least to discuss this, Better to study philosohy of
science, philosophy of technology, history of science and history of technology
to have deeper analysis. Those who do not know history cannot know future.

Requirements are functions of software under development. We want to measure
software to know what functions to be implemented. In the same way we provide
speed, acceleration of a sports car as requirements before designing it. My
point is that we can not have the measurement (mathematically) directly to know
the functions for business/enterprise software to be developed. That is what
software engineering is doing today, trying to know the unknowable, measure the
unmeasureable. A popular way is to develop through trial and error  a working
version to be able to measure what are needed and continuously revise. Much like
Roman engineers who built many adquates and bridges within margin of error. At
the same time they pursued the hieght of apparment houses many of them
collapsed.

Roman engineers applied opinions (the cross section of a beam, for example)
whereby technical solution was found. Modern civil engineers apply scientific
knowledge where technical solutions are derived. There is definitely order and
regularity of any phenomenon men can come to understand, Indeed, without order
and regularity, the concept of science is impossible. For any well established
organizations, there are order and regularity men can understand..such as the
types of products and services, customers whose lifecycles are much longer than
lifecycles of software projects.

In the near future, we shall not speak natural laugnages to describe enterprise
software ( we may do now), but scientific languages. There will be levels of
languages. Some of which have audience of business stakeholders and users. We
must have different languages with presupposing disciplines designed for
different audience. To achieve this goal, we need to attempt an exposition of
the fundamental principles that are to be applied in the construction of logic
and mathematics. The evaluation and analysis of such principles are the tasks of
a special discipline, called methodology of deductive science or the methodology
of mathematics. It is through this discipline we construct the scientific
discipline of requirements engineering. The actual meaning the discipline refers
to is not needed in constructing such a discipline.

Jerry Zhu



________________________________
From: rwf60048 <rwferguson@...<mailto:rwferguson%40gmail.com>>
To:
Requirements-Engineering@yahoogroups.com<mailto:Requirements-Engineering%40yahoo\
groups.com>
Sent: Sun, November 22, 2009 1:06:37 PM
Subject: {Requirements-Engineering} Re: are requirements measurable?


Requirements have been measured many times. Capers answer is one. Basili showed
an interesting correlation at SEL when he demonstrated a 99% correlation between
familiarity and SLOC. Familiar requirements took less code than unfamiliar
requirements.

However, the idea that we can achieve 100% perfection in requirements is far
from possible and not even a reasonable ideal goal.

Requirements must be considered an agreement between customer and developer.
Since neither understands the other perfectly the requirements are not perfect
in any but the most primitive examples. Before one makes such a terrible
assumption go back an read "Understanding Computers and Cognition" by Winograd
and Flores.

The challenge of requirements (and other forms of standards and specifications)
is that we must use language to communicate them. The basis is communications
and not a formal grammar. If we intend to deal with real customers who will use
our products in domains that we do not fully understand and who's business is
changing at a pace that we cannot fully observe, THEN we must face the reality
of an incomplete definition. All our methods must deal with the reality of this
incompleteness and the concomitant changes.

The implication is not whether requirements engineering is somehow unneeded or
unimportant. Rather it means the job is not completed by a formal logic or
engineering discipline. The job requires constant checking for agreement by
whatever means we can define. It is not a matter of getting the requirements
"right". It is rather a determination of defining requirements that will achieve
customer value. Further, since the requirements must be stated in language that
the engineers use for communications, the onus is on the engineering team to
determine whether the customers understand us.

Bob Ferguson

--- In Requirements- Engineering@ yahoogroups. com, Jerry Zhu <jerryyz@... >
wrote:
>
> Hi All,
>
> Requirements are typically defined as what the system should do, referred to
as functional requirements. Measurability of requierments depends on the type of
software.
>
> There has been an increasing complexity of software over the years. Software
engineers started out with relatively simple software such as scientific
computation software and then worked up to relatively complex business software
such as that for accounting and finance. A design task involves the knowledge of
an increasing number of business disciplines. An important recent development is
that software not only includes business elements but also social elements.
Along the dimension of software, complexity increases from simple computation
software, through business software, to enterprise information systems.
>
> For business and enterprise software, requirements can not be known directly.
This can be explained by uncertainty principle we can not measure the position
and speed of a moving object at the same time. The more accruate we measure one,
the less accurate we measure the other. But we can measure position at any time
and calculate the speed and acceleration at any time precisely. This is how we
control a robot with output feedback only without measuring speed and
acceleration of the robot link torque.
>
> Requirements are measurements of speed for business software and acceleration
for enterprise software. Trying to measure unmeasurable information is the root
cause of requirements errors, rework and failure. No one knows what requirements
are, only guess them. Hence requirements engineering is guesswork.
>
> There are measureable information users do know about for business and
enterprise software from which precise, concise, stable requirements are
calculated. The process of identifying and measuring measureable information and
then deriving requirements  from them transforms requirements engineering from
guesswork to scientific work. That is, we can arrive precise and stable
requirements upfront without rework and failure. It means thats Chaos report can
be changed from 34% success rate to 100% over night. All large scale enterprise
software projects will succeed without doubts.
>
> Jerry Zhu
>
> [Non-text portions of this message have been removed]
>

[Non-text portions of this message have been removed]



[Non-text portions of this message have been removed]

Capers meant attributes, not features, of requirements. Requirements are defined
as features of software. Features of requirements sounds like requirements of
requirements. I like this concept of levels that is negelected in theory and
practice. "If not absurd at the begining, there is no hope." Einstein.

A quick conclusion is that software engineering is indeed a branch of
mathematics whose underlying disciplines are logic and organization/business
disciplines. As I said many times in many places, software engineering today is
civil engineering before Newton. Roman engineers wont understand Newtonian
sciences we are immersed in today. Science and technology are two wheels of any
matural engineering. Software engineering, still in its infancy as a field with
only technology, is guesswork rather than scientific work. It does not mean that
software engineering will never become scientific discipline. One needs to study
history of engineering at least to discuss this, Better to study philosohy of
science, philosophy of technology, history of science and history of technology
to have deeper analysis. Those who do not know history cannot know future.

Requirements are functions of software under development. We want to measure
software to know what functions to be implemented. In the same way we provide
speed, acceleration of a sports car as requirements before designing it. My
point is that we can not have the measurement (mathematically) directly to know
the functions for business/enterprise software to be developed. That is what
software engineering is doing today, trying to know the unknowable, measure
the unmeasureable. A popular way is to develop through trial and error  a
working version to be able to measure what are needed and continuously revise.
Much like Roman engineers who built many adquates and bridges within margin of
error. At the same time they pursued the hieght of apparment houses many of
them collapsed.  

Roman engineers applied opinions (the cross section of a beam, for
example) whereby technical solution was found. Modern civil engineers apply
scientific knowledge where technical solutions are derived. There is definitely
order and regularity of any phenomenon men can come to understand, Indeed,
without order and regularity, the concept of science is impossible. For any well
established organizations, there are order and regularity men can
understand..such as the types of products and services, customers
whose lifecycles are much longer than lifecycles of software projects.

In the near future, we shall not speak natural laugnages to describe
enterprise software ( we may do now), but scientific languages. There will be
levels of languages. Some of which have audience of business stakeholders and
users. We must have different languages with presupposing disciplines designed
for different audience. To achieve this goal, we need to attempt an exposition
of the fundamental principles that are to be applied in the construction of
logic and mathematics. The evaluation and analysis of such principles are the
tasks of a special discipline, called methodology of deductive science or the
methodology of mathematics. It is through this discipline we construct the
scientific discipline of requirements engineering. The actual meaning the
discipline refers to is not needed in constructing such a discipline.



Jerry Zhu




 



________________________________
From: rwf60048 <rwferguson@...>
To: Requirements-Engineering@yahoogroups.com
Sent: Sun, November 22, 2009 1:06:37 PM
Subject: {Requirements-Engineering} Re: are requirements measurable?

 
Requirements have been measured many times. Capers answer is one. Basili showed
an interesting correlation at SEL when he demonstrated a 99% correlation between
familiarity and SLOC. Familiar requirements took less code than unfamiliar
requirements.

However, the idea that we can achieve 100% perfection in requirements is far
from possible and not even a reasonable ideal goal.

Requirements must be considered an agreement between customer and developer.
Since neither understands the other perfectly the requirements are not perfect
in any but the most primitive examples. Before one makes such a terrible
assumption go back an read "Understanding Computers and Cognition" by Winograd
and Flores.

The challenge of requirements (and other forms of standards and specifications)
is that we must use language to communicate them. The basis is communications
and not a formal grammar. If we intend to deal with real customers who will use
our products in domains that we do not fully understand and who's business is
changing at a pace that we cannot fully observe, THEN we must face the reality
of an incomplete definition. All our methods must deal with the reality of this
incompleteness and the concomitant changes.

The implication is not whether requirements engineering is somehow unneeded or
unimportant. Rather it means the job is not completed by a formal logic or
engineering discipline. The job requires constant checking for agreement by
whatever means we can define. It is not a matter of getting the requirements
"right". It is rather a determination of defining requirements that will achieve
customer value. Further, since the requirements must be stated in language that
the engineers use for communications, the onus is on the engineering team to
determine whether the customers understand us.

Bob Ferguson

--- In Requirements- Engineering@ yahoogroups. com, Jerry Zhu <jerryyz@... >
wrote:
>
> Hi All,
>  
> Requirements are typically defined as what the system should do, referred to
as functional requirements. Measurability of requierments depends on the type of
software.
>  
> There has been an increasing complexity of software over the years. Software
engineers started out with relatively simple software such as scientific
computation software and then worked up to relatively complex business software
such as that for accounting and finance. A design task involves the knowledge of
an increasing number of business disciplines. An important recent development is
that software not only includes business elements but also social elements.
Along the dimension of software, complexity increases from simple computation
software, through business software, to enterprise information systems.
>  
> For business and enterprise software, requirements can not be known directly.
This can be explained by uncertainty principle we can not measure the position
and speed of a moving object at the same time. The more accruate we measure one,
the less accurate we measure the other. But we can measure position at any time
and calculate the speed and acceleration at any time precisely. This is how we
control a robot with output feedback only without measuring speed and
acceleration of the robot link torque.
>  
> Requirements are measurements of speed for business software and acceleration
for enterprise software. Trying to measure unmeasurable information is the root
cause of requirements errors, rework and failure. No one knows what requirements
are, only guess them. Hence requirements engineering is guesswork.
>  
> There are measureable information users do know about for business and
enterprise software from which precise, concise, stable requirements are
calculated. The process of identifying and measuring measureable information
and then deriving requirements  from them transforms requirements engineering
from guesswork to scientific work. That is, we can arrive precise and
stable requirements upfront without rework and failure. It means thats Chaos
report can be changed from 34% success rate to 100% over night. All large scale
enterprise software projects will succeed without doubts.
>  
> Jerry Zhu
>
> [Non-text portions of this message have been removed]
>




[Non-text portions of this message have been removed]

Jerry (and Bob),
I support Bob's position below and agree with everything except the last
sentence.
;-)
The engineers are only one stakeholder of the requirements, and the requirements
are used as a means of communication among many different stakeholders. To the
degree that it can be practically done, the requirements should be in the
language of the customer/user/maintainer/trainer/sustainer/etc. rather than in
the technical jargon of the engineer. The onus is on the engineering team to
understand the stakeholders and communicate with them much more than it is on
making the stakeholders understand us. The one place where this breaks down is
in formal specifications in which there are two sets of requirements, natural
language for the stakeholders and requirements specification language for the
engineers.
Don Firesmith

From: Requirements-Engineering@yahoogroups.com
[mailto:Requirements-Engineering@yahoogroups.com] On Behalf Of rwf60048
Sent: Sunday, November 22, 2009 1:07 PM
To: Requirements-Engineering@yahoogroups.com
Subject: {Requirements-Engineering} Re: are requirements measurable?



Requirements have been measured many times. Capers answer is one. Basili showed
an interesting correlation at SEL when he demonstrated a 99% correlation between
familiarity and SLOC. Familiar requirements took less code than unfamiliar
requirements.

However, the idea that we can achieve 100% perfection in requirements is far
from possible and not even a reasonable ideal goal.

Requirements must be considered an agreement between customer and developer.
Since neither understands the other perfectly the requirements are not perfect
in any but the most primitive examples. Before one makes such a terrible
assumption go back an read "Understanding Computers and Cognition" by Winograd
and Flores.

The challenge of requirements (and other forms of standards and specifications)
is that we must use language to communicate them. The basis is communications
and not a formal grammar. If we intend to deal with real customers who will use
our products in domains that we do not fully understand and who's business is
changing at a pace that we cannot fully observe, THEN we must face the reality
of an incomplete definition. All our methods must deal with the reality of this
incompleteness and the concomitant changes.

The implication is not whether requirements engineering is somehow unneeded or
unimportant. Rather it means the job is not completed by a formal logic or
engineering discipline. The job requires constant checking for agreement by
whatever means we can define. It is not a matter of getting the requirements
"right". It is rather a determination of defining requirements that will achieve
customer value. Further, since the requirements must be stated in language that
the engineers use for communications, the onus is on the engineering team to
determine whether the customers understand us.

Bob Ferguson

--- In
Requirements-Engineering@yahoogroups.com<mailto:Requirements-Engineering%40yahoo\
groups.com>, Jerry Zhu <jerryyz@...> wrote:
>
> Hi All,
>
> Requirements are typically defined as what the system should do, referred to
as functional requirements. Measurability of requierments depends on the type of
software.
>
> There has been an increasing complexity of software over the years. Software
engineers started out with relatively simple software such as scientific
computation software and then worked up to relatively complex business software
such as that for accounting and finance. A design task involves the knowledge of
an increasing number of business disciplines. An important recent development is
that software not only includes business elements but also social elements.
Along the dimension of software, complexity increases from simple computation
software, through business software, to enterprise information systems.
>
> For business and enterprise software, requirements can not be known directly.
This can be explained by uncertainty principle we can not measure the position
and speed of a moving object at the same time. The more accruate we measure one,
the less accurate we measure the other. But we can measure position at any time
and calculate the speed and acceleration at any time precisely. This is how we
control a robot with output feedback only without measuring speed and
acceleration of the robot link torque.
>
> Requirements are measurements of speed for business software and acceleration
for enterprise software. Trying to measure unmeasurable information is the root
cause of requirements errors, rework and failure. No one knows what requirements
are, only guess them. Hence requirements engineering is guesswork.
>
> There are measureable information users do know about for business and
enterprise software from which precise, concise, stable requirements are
calculated. The process of identifying and measuring measureable information and
then deriving requirements from them transforms requirements engineering from
guesswork to scientific work. That is, we can arrive precise and stable
requirements upfront without rework and failure. It means thats Chaos report can
be changed from 34% success rate to 100% over night. All large scale enterprise
software projects will succeed without doubts.
>
> Jerry Zhu
>
> [Non-text portions of this message have been removed]
>



[Non-text portions of this message have been removed]

Requirements have been measured many times. Capers answer is one. Basili showed
an interesting correlation at SEL when he demonstrated a 99% correlation between
familiarity and SLOC. Familiar requirements took less code than unfamiliar
requirements.

However, the idea that we can achieve 100% perfection in requirements is far
from possible and not even a reasonable ideal goal.

Requirements must be considered an agreement between customer and developer.
Since neither understands the other perfectly the requirements are not perfect
in any but the most primitive examples. Before one makes such a terrible
assumption go back an read "Understanding Computers and Cognition" by Winograd
and Flores.

The challenge of requirements (and other forms of standards and specifications)
is that we must use language to communicate them. The basis is communications
and not a formal grammar. If we intend to deal with real customers who will use
our products in domains that we do not fully understand and who's business is
changing at a pace that we cannot fully observe, THEN we must face the reality
of an incomplete definition.  All our methods must deal with the reality of this
incompleteness and the concomitant changes.

The implication is not whether requirements engineering is somehow unneeded or
unimportant. Rather it means the job is not completed by a formal logic or
engineering discipline. The job requires constant checking for agreement by
whatever means we can define. It is not a matter of getting the requirements
"right". It is rather a determination of defining requirements that will achieve
customer value. Further, since the requirements must be stated in language that
the engineers use for communications, the onus is on the engineering team to
determine whether the customers understand us.

Bob Ferguson

--- In Requirements-Engineering@yahoogroups.com, Jerry Zhu <jerryyz@...> wrote:
>
> Hi All,
> �
> Requirements are typically defined as what the system should do, referred to
as functional requirements. Measurability of requierments depends on the type of
software.
> �
> There has been an increasing complexity of software over the years. Software
engineers started out with relatively simple software such as scientific
computation software and then worked up to relatively complex business software
such as that for accounting and finance. A design task involves the knowledge of
an increasing number of business disciplines. An important recent development is
that software not only includes business elements but also social elements.
Along the dimension of software, complexity increases from simple computation
software, through business software, to enterprise information systems.
> �
> For business and enterprise software, requirements can not be known directly.
This can be explained by uncertainty principle we can not measure the position
and speed of a moving object at the same time. The more accruate we measure one,
the less accurate we measure the other. But we can measure position at any time
and calculate the speed and acceleration at any time precisely. This is how we
control a robot with output feedback�only without measuring speed and
acceleration of the robot link torque.
> �
> Requirements are measurements of speed for business software and acceleration
for enterprise software. Trying to measure unmeasurable information is the root
cause of requirements errors, rework and failure. No one knows what requirements
are, only guess them. Hence requirements engineering is guesswork.
> �
> There are measureable information users do know about�for business and
enterprise software�from which precise, concise, stable requirements are
calculated. The process of�identifying and measuring measureable information and
then deriving requirements�from them�transforms requirements engineering from
guesswork to scientific work. That is, we can arrive precise and
stable�requirements upfront without rework and failure. It means thats Chaos
report can be changed from 34% success rate to 100% over night.�All large scale
enterprise software projects will succeed without doubts.
> �
> Jerry Zhu
>
> [Non-text portions of this message have been removed]
>

Great.  A lot of data...thought provoking.  I have yet to appreciate what a
function point measures and how it applies to various functions.

Putcha V. Narasimham
Mobile 98660 71582 Home 040 6666 9393

--- On Sun, 22/11/09, Capers@... <Capers@...> wrote:


From: Capers@... <Capers@...>
Subject: Re: {Requirements-Engineering} are requirements measurable?
To: Requirements-Engineering@yahoogroups.com
Date: Sunday, 22 November, 2009, 3:17 PM


 



All,

Some features of requirements can be measured using function point metrics.
Here are a few examples.

Requirements volume ranges between about 0.5 and 1.2 pages per function
point in terms of paper documentation. Use cases push the volume up a bit.

Requirements defect density averages about 1.0 defects per function point.

By measuring requirements volume using function points at the end of the
requirements phase and then again at delivery, it has been found that the
growth rate of creeping requirements runs between 1% and 3% per calendar month;
Agile projects may top 10% per calendar month.

By looking at usage patterns of software in production, some interesting
correlations with work performance are possible. For example project managers
on successful software projects use about 18 kinds of project management
tools totalling roughly 30,000 function points. For projects that fail
managers use only 3 to 6 kinds of tools and less than 6,000 function points.

The most significant differences between successful and failing projects
are in the areas of testing and quality tools; successful projects tend to use
8 quality predictive and measurement tools totalling around 10,000 function
points. Failures may use no tools at all.

Software developers use about a dozen tools totalling around 25,000
function points. Development tool usage is more consistent than project
management
tool usage.

Such correlations are possible for other kinds of knowledge workers using
tools such as medical instruments, legal research tools, marketing and sales
analysis, accounting, etc.

It is also possible to accumulate the function point totals of software
embedded in modern automobiles, aircraft navigation, smart appliances, etc.

Ordinary consumers with a modern auto, smart appliances, a home burglar
alarm, and a couple of personal computers have daily access to about 3,000,000
function points. We don't use all these function points on a daily basis,
but probably make use of about 25,000 function points during a typical day.

Microsoft office 2007 is around 100,000 function points in total size; few
users make use of more than about 7,000 function points of its features.

Windows Vista was about 150,000 function points in size; few users make use
of more than about 10,000 function points of its features.

By contrast Linux is only about 20,000 function points in size, but users
typically make use of at least 10,000 function points of its features.

Large ERP packages in the class of SAP and Oracle may top 300,000 function
points when all features and components are summed; most companies only use
about 25,000 function points of these features.

A full portfolio in a Fortune 500 company may top 5,000 applications and
10,000,000 function points. About half of the applications are either dead or
declining in use. There are some correlations between business success and
portfolio size and usage; although more research is needed.

These findings are preliminary and have a large margin of error, but the
fact that such topics can be studied at all is interesting.

I have some papers that quantify the volume of software engineering tools
and also appliances, autos, and other modern devices running on embedded
software.

Capers Jones

[Non-text portions of this message have been removed]









       The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.
http://in.yahoo.com/

All,

Some features of requirements can be measured using function point metrics.
  Here are a few examples.

Requirements volume ranges between about 0.5 and 1.2 pages per function
point in terms of paper documentation.  Use cases push the volume up a bit.

Requirements defect density averages about 1.0 defects per function point.

By measuring requirements volume using function points at the end of the
requirements phase and then again at delivery, it has been found that the
growth rate of creeping requirements runs between 1% and 3% per calendar month;
Agile projects may top 10% per calendar month.

By looking at usage patterns of software in production, some interesting
correlations with work performance are possible.  For example project managers
on successful software projects use about 18 kinds of project management
tools totalling roughly 30,000 function points.  For projects that fail
managers use only 3 to 6 kinds of tools and less than 6,000 function points.

The most significant differences between successful and failing projects
are in the areas of testing and quality tools; successful projects tend to use
8 quality predictive and measurement tools totalling around 10,000 function
points.  Failures may use no tools at all.

Software developers use about a dozen tools totalling around 25,000
function points.  Development tool usage is more consistent than project
management
tool usage.

Such correlations are possible for other kinds of knowledge workers using
tools such as medical instruments, legal research tools, marketing and sales
analysis, accounting, etc.

It is also possible to accumulate the function point totals of software
embedded in modern automobiles, aircraft navigation, smart appliances, etc.

Ordinary consumers with a modern auto, smart appliances, a home burglar
alarm, and a couple of personal computers have daily access to about 3,000,000
function points.  We don't use all these function points on  a daily basis,
but probably make use of about 25,000 function points during a typical day.

Microsoft office 2007 is around 100,000 function points in total size; few
users make use of more than about 7,000 function points of its features.

Windows Vista was about 150,000 function points in size; few users make use
of more than about 10,000 function points of its features.

By contrast Linux is only about 20,000 function points in size, but users
typically make use of at least 10,000 function points of its features.

Large ERP packages in the class of SAP and Oracle may top 300,000 function
points when all features and components are summed; most companies only use
about 25,000 function points of these features.

A full portfolio in a Fortune 500 company may top 5,000 applications and
10,000,000 function points.  About half of the applications are either dead or
declining in use.  There are some correlations between business success and
portfolio size and usage; although more research is needed.

These findings are preliminary and have a large margin of error, but the
fact that such topics can be studied at all is interesting.

I have some papers that quantify the volume of software engineering tools
and also appliances, autos, and other modern devices running on embedded
software.

Capers Jones






[Non-text portions of this message have been removed]

Hi All,
�
Requirements are typically defined as what the system should do, referred to as
functional requirements. Measurability of requierments depends on the type of
software.
�
There has been an increasing complexity of software over the years. Software
engineers started out with relatively simple software such as scientific
computation software and then worked up to relatively complex business software
such as that for accounting and finance. A design task involves the knowledge of
an increasing number of business disciplines. An important recent development is
that software not only includes business elements but also social elements.
Along the dimension of software, complexity increases from simple computation
software, through business software, to enterprise information systems.
�
For business and enterprise software, requirements can not be known directly.
This can be explained by uncertainty principle we can not measure the position
and speed of a moving object at the same time. The more accruate we measure one,
the less accurate we measure the other. But we can measure position at any time
and calculate the speed and acceleration at any time precisely. This is how we
control a robot with output feedback�only without measuring speed and
acceleration of the robot link torque.
�
Requirements are measurements of speed for business software and acceleration
for enterprise software. Trying to measure unmeasurable information is the root
cause of requirements errors, rework and failure. No one knows what requirements
are, only guess them. Hence requirements engineering is guesswork.
�
There are measureable information users do know about�for business and
enterprise software�from which precise, concise, stable requirements are
calculated. The process of�identifying and measuring measureable information and
then deriving requirements�from them�transforms requirements engineering from
guesswork to scientific work. That is, we can arrive precise and
stable�requirements upfront without rework and failure. It means thats Chaos
report can be changed from 34% success rate to 100% over night.�All large scale
enterprise software projects will succeed without doubts.
�
Jerry Zhu

[Non-text portions of this message have been removed]

International Institute for Software Testing (IIST)
******************************************************

IIST Important Links
==============
IIST Homepage  - http://www.testinginstitute.com/
IIST Public Training - http://www.testinginstitute.com/stpw/
IIST On-line Training  - http://www.testinginstitute.com/online/
IIST On-site Training  - http://www.testinginstitute.com/courses.php
IIST Free Training  - http://www.testinginstitute.com/seminar.php

This week's featured event:

Dallas - ITCW - Dallas, TX  December 7-11, 2009
===========================================
The International Testing Certification Week (ITCW), Offering World-Class,
Practical Education For Software Testing and QA Professionals, Is Coming to
Dallas, TX

* Offering multiple full-day classes each day
* Learn industry best practices taught in a practical manner
* Return to your job a more confident & skilled professional
* All classes earn credit toward CSTP or CTM Certification

Find out more about this event, please visit;
http://www.testinginstitute.com/stpw/dallas2009/index.php

Upcoming Public Training (ITCW)
========================
The International Institute for Software Testing (IIST) offers a wide variety of
educational
opportunities and education-based professional certifications to help you meet
day-to-day challenges and to
improve your skills.
All classes are offered in the following formats with details on each listed
below:

2009 Schedule:
****************
Dallas, TX - December 7-11, 2009

2010 Schedule:     Just Announced!
****************************************
Tampa, FL - February 8-12, 2010
San Antonio, TX - February 22-26, 2010
Anaheim, CA - March 8-12, 2010
Chicago, IL - March 22-26, 2010
Minneapolis, MN - April 12-16, 2010
Boston, MA - June 14-18, 2010

To find out more information about these and other public training events
offered, please visit:  http://www.testinginstitute.com/stpw/


IIST Certifications
==============
CSTP Certification - http://www.testinginstitute.com/cstp.php
CTM Certification - http://www.testinginstitute.com/ctm.php

On-line Training
===========
As organizations face the challenge of improving results while cutting costs,
demand for online training is increasing
as a cost-effective option to improve employee performance.
IIST offers a wide variety of classes for you to improve your skill sets. All
IIST courses count toward
either CSTP or CTM certification.
http://www.testinginstitute.com/online/

On-site Training
===========
Bringing courses onsite makes the most sense if you have a team of 10 or more.
In addition to the cost saving, onsite classes offers flexibility and
customization not available in public or online classes.
With on-site training, you get more “bang” for your education dollars –
significantly less than other
training options on a per student basis.
http://www.testinginstitute.com/courses.php

Free Webinars
===========
All of our free online webinars are purely educational and packed with practical
advice. They are designed to help project teams gain control over their projects
and deliver the quality your customers expect.
http://www.testinginstitute.com/seminar.php

The Value of Certification
=====================
Software test and quality professionals around the world have been seeking ways
to boost their credibility both within their own organizations and in the
software community. The most logical choice is certification with one of the
national or international certification programs available. However, there have
been many questions, even doubts, regarding the value of certification. Hiring
managers are getting frustrated when they hire certified testers or certified
quality personnel and discover that they are not capable of performing some of
the most basic tasks in their job. This has caused some hiring managers and
organizations to question the value of certification.
http://www.testinginstitute.com/value.php


International Institute for Software Testing
636 Mendelssohn Ave. N, Golden Valley, MN 55427  - Phone: 877-GET-IIST or
763-546-0072
Email: info@... Website: http://www.iist.org

Donald, all:

The companies that seem to do best in dealing with human factors tend to
have fairly elaborate usability labs.  I've been in such labs where everything
is instrumented and researchers are behind one-way mirrors watching people
try to use software (or hardware).  The get measurements on human response
times, software response times, keystroke errors, boot-up times, etc.

Dr. Bill Curtis is a psychologist - he also did the human portion of the
capability maturity model.  No doubt he can shed some light on the question.

Best Regards,
Capers Jones




[Non-text portions of this message have been removed]

Dear All,
We have been parcticing agile - scrum methodology on software projects for
almost a year and half now.Couple of project leaders from various scrum teams in
my organization discussed the Requirement elicitation in agile with me. What I
concluded from the discussion was�that they are looking for �a training cum
presentation on areas like:
1. Mapping of requirements into themes using an example on mapping of software
or any non technical requirements into themes
I will like to state affinity diagram as a way of doing it. Any other thoughts.
2. Prioritization of the themes using a software example or any non technical
example on themes, functional grouping of themes & prioritization
Let me take old example of hospital to explain functional grouping
Lets say that medical services are functional requirement for hospital then how
do we relate
this requirement to theme and what can be the functional grouping of this
requirement.
3. Creation of user stories (how to create, any format, some software or non
technical examples)
4. Creation of the product backlog ordered by While I have some idea on how to
go about with this presentation.
Just wanted to know, if anyone has done such training or presentation in his/her
company earlier and
more importantly how did it go. Feedback from participants and any improvements
suggested.
It will be of great help and easy to make the teams understand on if I can have
examples from different industries based on experiences of each one of us from
various industries ( for some great software , non software examples for steps
from 1 to 4.)
�
Regards,
Dushy


       Yahoo! India has a new look. Take a sneak peek http://in.yahoo.com/trynew

[Non-text portions of this message have been removed]

I am out of the office until 11/16/2009.

I am in San Juan, Puerto Rico, for a 40th Anniversary get away and will not
be checking e-mail or voice mail until Monday November 16, 2009.


Note: This is an automated response to your message  "
{Requirements-Engineering} Online Courses - Reduced Rate Until November
30th" sent on 11/10/09 16:13:43.

This is the only notification you will receive while this person is away.

I have been getting up-to-speed on Human System Integration (HSI) which
integrates the domains of Human Factors Engineering, Manpower, Personnel, and
Training (MPT); environment, safety, and occupational health (ESOH),
habitability, and personnel survivability. HSI is basically everything to do
with how humans impact a system and the system impacts humans. HSI intersects
with all of system engineering including requirements engineering (specifically
the engineering of HSI requirements).  Most requirements engineers are used to
specifying system requirements but not human requirements. For example, use case
modeling basically addresses how the system must (shall) behave as a reaction
external actors' actions.

What does the group think about explicitly specifying system requirements (shall
statements) on humans who interact with the system (as if they are a part of the
system rather than external to it)?

Donald Firesmith
Acquisition Support Program
Software Engineering Institute

"Seeing reality takes a lot of imagination - but it takes disciplined
imagination, which is sensitive to scientific knowledge, humble before it, and
committed to consistency with it. The undisciplined imagination cannot learn
because it refuses all constraints; it claims "Anything is possible!" when in
fact, much of what it imagines is not possible, while most of what is possible,
it will never imagine. Scientific knowledge does limit the imagination, but only
in the same healthy way that sanity limits what we take as real."
-Joel R. Primack and Nancy Ellen Abrams, The View from the Center of the
Universe



[Non-text portions of this message have been removed]

-------------------------------------------------------------------------
Complete your Education-Based Certification through Online Courses for
Software Testing and Process Improvement Professionals
-------------------------------------------------------------------------

IIST & IISP Certifications
==========================
CSTP Certification - http://www.testinginstitute.com/cstp.php
CTM Certification - http://www.testinginstitute.com/ctm.php
ISPIC Certification -
http://www.software-process-institute.com/certification.htm

******************************************************************************
ALL online classes – Live and Recorded - Discounted now until November 30th.
******************************************************************************

Why IIST or IISP Online Courses?
================================
As organizations face the challenge of improving results while cutting costs,
demand for online training
is increasing as a cost-effective option to improve employee performance.

In recognition of this need, IIST and IISP are discounting
ALL online classes – both Live and Pre-Recorded - from now until November
30th.

Every Software Testing or Process Improvement class is discounted by $100:

Pre-Recorded Online classes:   $395
Live Online classes:           $495

Better yet, ALL classes count toward CSTP, CTM or ISPIC certification!

Learn More about IIST's online courses »
http://www.testinginstitute.com/online/
Learn More about IISP's online courses »
http://www.software-process-institute.com/online/

How Do Pre-Recorded, Self-paced On-line Courses Work?
=====================================================
* You do not have to wait for a registration period. Sign up for courses any day
of the week - 24 hours a day.
* For courses that were recorded from live interactive sessions, you will enjoy
listening to the questions and discussion that occurred during the live session.
* You will have the opportunity to post your questions, get answers, and engage
in a stimulating discussion with other professionals through the on-line Class
Discussions feature.
* You will have a full 30 days access to the course. During this 30 day period,
you must complete the exam for that on-line course if it is to be counted
towards certification.

Learn More about IIST's online Pre-Recorded courses »
http://www.testinginstitute.com/online/prerecorded.php#cost
Learn More about IISP's online Pre-Recorded courses »
http://www.software-process-institute.com/online/prerecorded/

How Do Live Interactive On-line Courses Work?
=============================================
* You register for the courses which are held at specific dates and times.
* You will have the opportunity to listen and interact with instructor and
course attendees live. You can ask your specific questions and receiving
real-time answers.
* After the live event, you also have a full 30 days to listen to a recorded
version of the class to further reinforce key points and learning objectives.
Listen as many times as you wish at your own pace, day or night.
* You will have full 30 days to write the test for the course on-line.


Learn More about IIST's online Live Interactive courses »
http://www.testinginstitute.com/online/liveinteractive.php#cost
Learn More about IISP's online Live Interactive courses »
http://www.software-process-institute.com/online/#live


IIST Important Links
---------------------
IIST Homepage  - http://www.testinginstitute.com/
IIST Public Training - http://www.testinginstitute.com/stpw/
IIST On-line Training  - http://www.testinginstitute.com/online/
IIST On-site Training  - http://www.testinginstitute.com/courses.php
IIST Free Training  - http://www.testinginstitute.com/seminar.php

IISP Important Links
---------------------
IISP Homepage - http://www.software-process-institute.com/
IISP Public Training  - http://www.software-process-institute.com/training/
IISP On-line Training  - http://www.software-process-institute.com/online/
IISP On-site Training  - http://www.software-process-institute.com/onsite.htm
IISP Free Training - http://www.software-process-institute.com/freeseminars/


International Institute for Software Testing  - International Institute for
Software Process
636 Mendelssohn Ave. N, Golden Valley, MN 55427  - Phone: 877-GET-IIST or
763-546-0072
Email: info@... or info@... Website: http://www.iist.org or
http://www.spinstitute.org