Welcome to the second issue of The Exchange, the bimonthly exploration of requirements development.   This issue continues our focus on effective stakeholder involvement by considering the need for a winning game plan.  

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

David Gelperin
LiveSpecs Software

Requirements Development (RD) has much in common with Olympic Basketball.  Both are team games.  Both require knowledgeable participants to succeed.

Both teams face internal and external challenges.  Both are significantly affected by human factors such as confusion, distraction, and ego.  Both are formed for the duration of the event and then disbanded.

In both games, teams have different strategies that reflect the styles of coaches and players. Some teams play better than others.

To build a successful RD team, your players (stakeholders) must understand your game and want to play.  Below, we outline the initial elements of the LiveSpecs' approach to creating a winning game plan.

RD Preconditions:

1. Project goals have been described along with budget and schedule constraints.
2. The initial group of stakeholders has been identified.

RD Assumptions:

1. Stakeholders bring experiences and knowledge to a project as well as their own agendas, their interpretations of needs and priorities.
2. Initially, stakeholders do not share a common understanding of application terminology, critical features, usage scenarios, or project and system risks and costs.
3. Project initiation is justified by a set of assumptions and choices that may change during the project due to environmental factors (new laws), business factors (new competitor products), enterprise factors (reorganization), or stakeholder learning.
4. System development may not be feasible for a variety of reasons that are best discovered early.

RD Goals:

1. To discover, specify and manage system assumptions, priorities, issues, and alternate features and constraints.
2. To rapidly develop common and accurate understanding of the items in Goal 1.
3. To negotiate and develop informed consensus on the requirements, the selected alternatives.
4. To monitor project justification factors and feasibility and, if necessary, stop the project during RD.

This view suggests that the following are important elements of an RD strategy:

• expectation and activity management
• team communication and rapid learning
• exploration, specification, and management of all items in Goal 1
• negotiation and consensus-building
• justification and feasibility monitoring (e.g., via incremental commitment)

Which of these strategy elements has been the most challenging for you?  What other issues have you found to be critical?  Let us hear from you.

Check out any of the general references on our website.

In The Only Winning Move, a column to appear in November on the StickyMinds website, Dave writes about the virtue of stopping a project.

LiveSpecs Software promotes clear requirements that anchor project communication and satisfy the information needs of managers, designers, testers, and technical writers.   Our website, www.clearspecs.com is home to a quartet of new, mutually-supportive specification techniques that produce clear, detailed descriptions of usage and behavior.   Find out more by downloading free descriptions and examples.

If you are interested in clear requirements and smart testing, check out our services and contact us to discuss how we can help.

Information about 3 public workshops on Writing Detailed Use Cases is available on the website.   The November '03 workshops are being held in Chicago, San Francisco, and New York.