Welcome to the e-newsletter that explores requirements-related topics. This issue explores the questions:

Note 1:  Find out about our new workshop on Verifying Requirements in About Us (below).

Note 2:  If you plan to attend the World Congress for Business Analysts, November 15-18, 2005 in Orlando, you can use priority code: SPKRM171920DG to receive a 25% discount on standard event registration fees.   I speak about Use Cases at 3:00PM on the 17th.  Come by and say hello.

Remember, if you find The Exchange useful, please send it to friends and colleagues.  Thanks.

David Gelperin
ClearSpecs Enterprises

It wasn't going well. The marketers were having trouble describing their requirements. We understood that marketing campaigns needed to be managed, but were having trouble getting the details. This difficulty was in sharp contrast to our experience improving the accounting system, because the accountants had little difficulty providing details. We needed to figure out how to help the marketers tell us what they wanted.

During requirements development, we wish for commitment, cooperation, communication, and trust among the stakeholders. These success factors are interdependent -- that is strength in one strengthens the others, but weakness in one weakens the others.

Cooperation can be difficult when there are strong differences in learning style. Successful requirements development entails learning by every stakeholder. When learning styles are similar, for example accountants and business analysts, cooperation (and communication) is easier. When learning styles are different, for example marketers and software developers, it is harder.

The work of David Kolb helps us understand the nature of learning styles. Take a look at the Diagram of Kolb's Learning Styles (pdf). Your learning style is determined by how you engage (do or watch or a mixture) and respond (feel or think or a mixture) to the world. Your comfort zone is the area in the engage-respond plane that describes how you like to learn.

If your customers have a strong:

The principle is to match your acquisition approach to your customer's learning style by determining your customer's comfort zone (perhaps by testing -- see the references below) and then selecting an information acquisition approach that matches their learning preferences. Inevitable differences in learning style mean that one acquisition approach does not fit all situations.

How have you dealt with critical stakeholders who have difficulty supplying details? Let us hear about your experiences and strategies.

If you'd like to measure learning styles, check out learning-styles-online.com.  Find out more about David Kolb's model of learning styles at businessballs.com.

So you've gathered some requirements and they need checking.  If you'd like to learn how to detect more of your defective and missing requirements, consider our new on-site workshop Verifying Requirements.  You'll learn to use more than 25 powerful, but practical, verification techniques.

ClearSpecs Enterprises provides powerful techniques for the specification and verification of requirements and guidance on requirements development and management. We provide information, training, consulting, and software (Q1 '06).  

If you would like help improving your requirements practices, check out our services and contact us to discuss how we might help.

Welcome to the The Exchange, the e-newsletter that explores requirements-related topics.   In this issue, we look at the state of the practice as measured by survey questions posted on the ClearSpecs website.

Drop us an email and tell us about your practices.

Remember, if you find The Exchange useful, please forward it to friends and colleagues.  Thanks.

David Gelperin
ClearSpecs Enterprises

For several years, we have been surveying the state of the practice in requirements development and management on the ClearSpecs Website. Results from six of the survey questions are profiled below. Compare your practices to these profiles.

Our surveying strategy is to post a multiple-choice question and wait for 200 responses before posting the next one. In addition, we have no controls on the responders i.e., anyone who visits the site can vote. Please keep this strategy in mind when interpreting the results.

Poll Questions and Answers

• What is your primary USE for requirements?
  
  While the primary use is for building products or systems (60%), the remaining 40% is divided among testing (13%), planning (11%), documentation and training (6%), outsourcing (5%), and buying (5%). This shows that requirements information, good or bad, impacts a broad range of project activities.
  
  
• For a typical project, what percent of the time is spent on requirements?
  
  
  • 17% of respondents said 00 to 09% of project time
  • 20% of respondents said 10 to 19% of project time
  • 24% of respondents said 20 to 29% of project time
  • 13% of respondents said 30 to 39% of project time
  • 15% of respondents said 40% or more of project time
  • 11% of respondents have no typical projects or did not know
  
  Hopefully, the projects investing less than 20% of their time in requirements are successfully using agile methods and/or have development staffs with a deep understanding of customer needs.
  
  
• What percent of your software defects have been traced to requirements problems?
  
  
  • 21% of respondents said 0 to 29% of defects
  • 18% of respondents said 30 to 59% of defects
  • 30% of respondents said 60 to 99% of defects
  • 31% of respondents do not do root cause analysis
  
  Of those doing root cause analysis, half report that over half their defects have been traced to requirements.
  
  
• Rate the AVERAGE EFFECTIVENESS of your requirements in meeting the information needs of managers, architects, and testers.
  
  
  • 14% of respondents said their reqts have little or no value
  • 24% of respondents said their reqts have some value, but are not satisfactory
  • 19% of respondents said their reqts are barely satisfactory
  • 43% of respondents said their reqts are effective or very effective
  
  While many requirements suites (62%) satisfy their communication objectives, many others (38%) do not.
  
  
• What is your primary form of automated support for requirements DEVELOPMENT?
  
  While most use word processors (46%), others use UML modelers (14%), spreadsheets (10%), databases (6%), and commercial reqts. mgmt. systems (6%). Some do not use automation (13%).
  The heavy use of word processors makes it difficult to escape the "requirements as document" perspective and move to the "requirements as multi-dimensional network of interconnected information" perspective.
  
  
• What form of automated support do you use for requirements MANAGEMENT?
  
  While most use no automated support (39%), others use commercial and custom reqts. mgmt. systems (30%), the modification tracking capability of their word processor (22%), and commercial and custom configuration mgmt systems (9%).
  Many projects do not see the value of requirements management. Perhaps for some their requirements aren't worth managing.

If there are practices you are curious about that we have not already surveyed, please submit candidate questions. Note that we must be able to put them in a multiple-choice format.  Let us hear from you.

You can find the details of these survey questions as well as others on the ClearSpecs website: Past Survey Results

ClearSpecs Enterprises provides comprehensive frameworks of powerful techniques for the specification and verification of requirements. We provide information, training, consulting, and software(Q1 '06).  

If you would like to improve your requirements practices, check out our services and contact us to discuss how we might help.

Welcome to the The Exchange, the e-newsletter that explores requirements-related topics.   In this issue, we examine the elements of American culture that make requirements development difficult.

Drop us an email and tell us about your experiences and opinions.

Remember, if you find The Exchange useful, please forward it to friends and colleagues.  Thanks.

David Gelperin
ClearSpecs Enterprises

Ivy Hooks and Kristin Farry have written a book on requirements especially for managers titled "Customer-Centered Products: Creating Successful Products Through Smart Requirements Management" (American Management Association 2001).   Read this book, if you are interested in developing and managing requirements.

In a wonderful chapter titled "Why Johnny Can't Write Requirements" they describe the cultural, educational, and management influences on requirements development.  The chapter identifies eight forces in American culture that make effective requirements development difficult.  These forces are:

• Insistence on choice
• Obsession with big and more
• Pursuit of impossible dreams
• Impatience with time
• Focus on "what's new"
• Urge to improvise
• Acceptance of mistakes
• Willingness to assume

"… Neither customers nor developers want any limits on their choices.  We all think big and view those trying to scope us down as "unimaginative" or lacking that "can do" attitude that made America great."

Choice may be essential for product usability or effectiveness, but insistence on unnecessary choices by customers or developers results in scope creep and unnecessary complexity.  Obsession with "big and more" leads to unbridled scope creep.  "Interesting" and "comprehensive" are the enemies of "cost-effective" and "good enough".

Sometimes customers ask for feature sets that are technically or economically infeasible.  "Can do" attitudes coupled with failure to analyze feature interactions lead to the late and expensive discovery of technical and economic reality.  Even when a feature set is feasible, the project schedule may be infeasible.  Customers want their products yesterday.  Delivery pressure seems a perfect reason for compressing requirements development, so design and build can start earlier.

Focus on "new and interesting" causes lack of attention to "familiar or uninteresting".  Little interest in dealing with invalid input and exception conditions leads to brittle products.  We value the ingenuity and valor of "heroic" developers over effective failure prevention.  Since detailed requirements might lead to "boring" projects and are not "fun", they are avoided.

Most developers assume that mistakes are unavoidable.  Careful work is not a priority, mistakes are corrected in the next iteration, and executable code is valued much more than detailed analysis.  For many reasons including unawareness, ego, and embarrassment, we do not check our understanding of the task details.  Our acceptance of mistakes and the convenient excuse of tight schedules makes it easier to "guess wrong" than to confirm assumptions.

In the last newsletter, we identified eight inherent human and environmental conditions that create significant challenges for requirements development.  These eight American cultural conditions add to that challenge.

For those of you who are not "saddled" with American culture, what are the forces in your culture that make requirements development difficult?  Let's hear from you.

You can find Ivy and Kristin's book at: www.complianceautomation.com/Book/BookOverview.htm

ClearSpecs Enterprises promotes the ClearSpecs pattern framework with information, training, consulting, and software(Q4 '05).  

If you would like to improve your requirements practices or acceptance testing, check out our services and contact us to discuss how we might help.

Welcome to the The Exchange, the e-newsletter that explores requirements-related topics.   In this issue, we consider the challenges of requirements development and why things don't seem to be getting any easier.

The Exchange will only live up to its name if you share your experiences and opinions.  Please consider dropping us an email.

Remember, if you find The Exchange useful, please forward it to friends and colleagues.  Thanks.

David Gelperin
ClearSpecs Enterprises

If you had to choose between having a root canal procedure or developing system requirements, which would you pick? It might be the dental work because the interval of pain is shorter and novacaine can help. Why is requirements development (RD) so difficult and why don't we just figure out how to make it easier?.

The problem is that the major challenges of RD are not problems, but inherent conditions. Problems can be solved, conditions can only be managed. Hunger in the United States is a problem that could be solved with sufficient commitment and resources. Crime is a condition.

Inherent conditions (challenges) of RD are the:

• unavailable or unfocussed stakeholders
• concrete thinking of critical stakeholders -- descriptions and models don't help much, only the implementation communicates
• tacit knowledge of stakeholders -- hard to access
• emergent understanding of stakeholders -- pace of emergence can not be scheduled
• stakeholder misunderstandings -- due to ambiguous language and communication
• stakeholder disagreements about requirements
• implicit requirements -- may escape detection during development
• rapid changes in the application or technical domain

Notice that the first six conditions relate to people and the workings of the mind, while the last two relate to the nature of application and technical domains. Neither providing more resources, using new tools, nor reorganizing project teams will have much affect on these conditions.

While all conditions are not present on every project, most projects will encounters some of them. Effective management of these challenges begins with early recognition and then uses focussed mitigation strategies such as replacing an unavailable stakeholder or cancelling the project in the face of irreconcilable disagreements between critical stakeholders.

What mitigation strategies have been successful for you? Have you experienced other challenges that we should add to the list?  Let us hear from you.

To enjoy requirements development is to enjoy major challenges.

You may find help expanding your collection of mitigation strategies in:

• Surfacing Tacit Knowledge in Requirements Negotiation by Paul Grunbacher and Robert Briggs. Pdf available at: csdl.computer.org/comp/proceedings/hicss/2001/0981/01/09811062.pdf



• Detecting Ambiguities in Requirements Documents using Inspections by Erik Kamsties, Daniel M. Berry, and Barbara Paech. Pdf available at: se.uwaterloo.ca/~dberry/FTP_SITE/tech.reports/kamsties.berry.paech.pdf

ClearSpecs Enterprises promotes the ClearSpecs specification techniques with information, training, consulting, and software('05).  

If you would like to improve your requirements practices or acceptance testing, check out our services and contact us to discuss how we might help.

Welcome to the The Exchange, the e-newsletter that explores requirements-related topics.   In this issue, we examine the what not how principle to understand when it applies.

The Exchange will only live up to its name if you share your experiences and opinions.  Please consider dropping us an email.

Some have asked about public training on ClearSpecs techniques.  Find out about one opportunity in "Going Public".

Remember, if you find The Exchange useful, please forward it to friends and colleagues.  Thanks.

David Gelperin
ClearSpecs Enterprises

Requirements should specify what needs to be done, but not how to do it.   This is common advise about the scope of requirements information.  The rationale is that requirements should specify needs, desires, and preferences (the problem) but not unnecessarily constrain the design or implementation of the corresponding system (a solution).   The technical staff should be free to make the best technical decisions

• Does this mean that hows should rarely be specified or never be specified?
• Can the technical staff always make effective use of the freedom to choose?
• What does "unnecessarily constrain" mean exactly?
• Is it sufficient to ask for safe or secure software and provide measures for these general qualities?
• Are there situations where requiring specific components, algorithms, or mechanisms (e.g., encryption) can significantly improve the chances of developing a successful product or modification?

Specifying a how in no way reduces the need to: (1) specify its corresponding what or (2) provide information sufficient to verify the how and its corresponding what.

When considering a how, the trade-off is the danger of forcing an inferior solution verses the danger of failing to guide limited experience and suffering product failure or significant amounts of rework.   If developers have significant expertise with a required capability or quality (e.g., safety), then constraining their design or implementation choices may be counter-productive.   However, if developers have little successful experience with the required capability or quality, then effective constraints are likely to be welcomed.

An alternative approach uses specific components, algorithms, or mechanisms as benchmarks and requires capabilities or qualities "at least as good as" those supplied by the specified elements.  This provides guidance without excluding better ideas.

Have you been unnecessarily constrained or floundered due of inadequate guidance?  Let us hear about your experiences.

There will be a 1-day tutorial on the ClearSpecs specification techniques on September 28th (Tuesday) in conjunction with the Better Software Conference 04 in San Jose, CA.   The tutorial is called Writing Detailed Requirements.

You can get a special 20% discount on this tutorial or any other conference activity by using the ClearSpecs Enterprises Customer Code: CBBV when you register.

Register by calling SQE customer service at 888-268-8770 or 904-278-0524.  Remember to use our code.

Act quickly because prices increase after August 27th.

ClearSpecs Enterprises promotes the ClearSpecs specification techniques with information, training, consulting, and software('05).  

If you would like to improve your requirements practices or acceptance testing, check out our services and contact us to discuss how we might help.

Welcome to the third issue of The Exchange, a quarterly exploration of requirements development.   We continue our focus on effective involvement by looking at the dynamics of developing an effective requirements team.  

Remember, if you find The Exchange useful, please forward it to friends and colleagues.   Thanks.

David Gelperin
LiveSpecs Enterprises

Forming, Storming, Norming, and Performing.  No they are not a law firm, but the stages of team development proposed by Bruce Tuckman in 1965.  I wish I had found this model much earlier in my career.  If you haven't seen it before and want to help your requirements team, read on.

Part of the challenge of requirements work is transforming a diverse group of stakeholders into a productive and efficient team.  Tuckman proposed a staged model of team development that has stood the test of time.  Understanding of this model can improve the quality of stage interactions and reduce the time spent developing an effective team.

In brief, the development stages are:

1. Forming - team is meeting and greeting; everyone is polite; some are excited; nothing important is decided; no visible conflict



2. Storming - differences surface in points of view, priorities, and style; confusion and disagreements are apparent regarding team objectives, priorities, organization, and strategies; suspicions and impatience appear about team members and the project; misunderstandings are frequent; very little progress toward goals



3. Norming - mutual understanding and respect begins; criticism is expressed thoughtfully and constructively; consensus forms on work rules, goals, boundaries, roles, and strategy; much better listening and open sharing; foundation for cooperation created



4. Performing - relationships established; focus is on major issues and important tasks; pride in the team increases; work is getting done; substantial progress

Unless a team has successfully worked together previously or is extremely homogenous in outlook, style, and understanding, there is no way to skip the Storming and Norming stages.  Requirements efforts rarely satisfy these skipping criteria.

This model certainly describes my experience with teams of diverse stakeholders.  For example, from personal mistakes, I now understand that it matters a great deal when some important suggestions are introduced to the team.  A suggestion e.g. about strategy, introduced before context and trust have been established may be rejected along with a significant loss of time in wasteful discussions that are full of misunderstandings.  The same suggestion introduced in later stages is accepted with little discussion.

A variant of the Tuckman model is Forming, Storming, Ignoring, and Pretending.  During these stages:

• Storming uncovers or should uncover major conflicts in goals, priorities, or strategy among critical stakeholders
• Ignoring fails to either resolve the conflicts or halt the project
• Pretending follows the protocols of requirements development with little hope of project success

Do these models describe any of your requirements experiences?  Let us hear from you.

George Gates states that workplace teams are un-American.   I enjoyed his article "Why Teams Fail".   You might too.

LiveSpecs Enterprises promotes the five ClearSpecs™ specification techniques with information, training, software (by year end), and consulting.   In February, several papers were added and revised on the website, so if you haven't visited www.clearspecs.com in a while, take a look.  

If you would like to improve your requirements practices or user acceptance testing, check out our services and contact us to discuss how we might help.