Software people are often eager to try out the newest technologies, tools, and methods to solve their clients’ development woes. This attitude often leads to a focus on building the product right rather than building the right product. Too often, software people go overboard with complex models and documentation. Or they rush to code, building the wrong software or writing code laden with defects.
Changing requirements because of changing market and business conditions is largely unavoidable; the problem is the avoidable scope creep that happens when you haven’t clarified and prioritized requirements.
This article is based on the book “Requirements by collaboration” from Ellen Gottesdiener and describes some crucial technics to get the right requirements before the software people starts to develop.
I have had the pleasure and honor of working on a really great team. We worked hard, had lots of fun, got the job done, and pleased our customers. Some people call this a “jelled” team. On our team, we were like a family. We had our problems, but we were respectful, passionate, forthright, sometimes argumentative, always trusting.
One of the most important factors contributing to great teams is that everyone shares the same purpose. If you’ve ever been on a team or attended a meeting in which your understanding of why you were doing this work, or having this meeting, didn’t match another person’s understanding, you know what I mean. Energy gets redirected from work to purpose-seeking. Conversation shifts from content to context. You spend time clarifying and debating purpose.
To have an effective requirements workshop, you must make your purpose crystal-clear to all the workshop players before everyone walks into the room.
Defining Project Scope
Every project must define its scope: what’s “in” and what’s “out.” Scope breathes life into a project’s business goals by broadly defining the who, what, when, why, where, and how associated with project goals and objectives. Scope determines the context for the user requirements effort.
If you think your project needs to define high-level or detailed user requirements in a workshop, check—and then double-check—with stakeholders about how clear the scope really is.
The expression scope creep (also known as feature creep, creeping user requirements, or requirements creep) has become part of the vernacular of software development. It means that new or expanded requirements have “crept” into the project after everyone thought the requirements had been defined.
Scope creep can be devastating to projects; it’s one of the most vexing problems in software development and a chief cause of failed, late, and over-budget projects. Most projects are at risk of scope creep, so assume that your project will also suffer (or could suffer) from it.
Workshops can help prevent scope creep. While you’re gathering information from stakeholders, listen carefully for potential differences among the players in their understanding of the scope. If there are conflicting messages about what’s in and out of scope, you may recommend that a team conduct a scope workshop rather than a detailed requirements workshop. Be clear with workshop stake-holders that without clear scope, a more detailed workshop cannot be successful.
Software requirements derive from user requirements, which in turn derive from business requirements. There are overlaps among these requirements levels, as shown in Figure 1-1.
Figure 1-1 Overlapping Requirements Levels Specification
Requirements can be documented in different ways:
- Business requirements can be recorded in a project charter, initiation document, or vision document.
- User requirements can be documented in a user requirements document, or a use case document if use cases are the primary technique being used to express the system’s functionality.
Requirements documentation can also take the form of a software requirements specification. Some organizations use a generic “requirements document” that includes both user and software requirements.
User requirements span business and software requirements, thus bridging the needs of the business to those of the software.
One of the biggest sources of difficulty is gaps in communication between software and business people
Whatever its form, the primary purpose of a requirements model is to communicate. Defining requirements is a discovery process for users and customers. User requirements evolve from the process of users “trying out” their requirements through models.
Workshops And Collaboration
Collaboration occurs when all members of a group or team share a common purpose, there’s mutual trust, and everyone uses agreed-upon approaches for the work. The members operate like a jazz ensemble: multiple voices interwoven, playing together and individually, generously and inventively, sharing a single theme.
Collaboration doesn’t just happen; teams don’t just form and jell automatically. Rather, collaboration must be engineered into a team’s work. Requirements workshop participants should include a healthy mix of business and software people who share a common goal and have stakes in the same project. A key element of successful collaborative workshops is that the participants agree ahead of time to the workshop purpose, principles for participation, and products. They also determine a decision-making process ahead of time; this permits the group to reach closure on their deliverables and the actions they will take after the workshop.
The cost of ineffective meetings is staggering. The average person attends seven to ten meetings a week, half of which are unproductive, and the average meeting involves nine people (two managers, four co-workers, two subordinates, and one outsider) who have as little as two hours’ prior notice. What’s more, the average meeting has no written agenda, and its purported purpose is completed only half the time.
Meeting participants complain that they waste time discussing irrelevant issues. Many people feel pressured to espouse opinions with which they privately disagree, or they feel they have little or no influence on the discussion. They don’t consider the results creative; most of them, in fact, think that underlying issues outside the scope of the official agenda are the real subjects under discussion.
Perhaps the most important distinctions between workshops and meetings are the presence of specific process roles—facilitator and recorder—in workshops and the fact that workshops deliver specific, predefined products.
A neutral facilitator assists the group by leading the workshop planning process and then guiding the group through the workshop. A person serving in another process role, the recorder (or scribe), might also assist by capturing the group’s work in real time.
Neither the facilitator nor the recorder operates as a content expert, nor does either collaborate in product creation. As a result, they’re free to focus on the process. As the group becomes more familiar with the workshop process, the facilitator’s role in controlling the process can be relaxed.
The facilitator’s job is to balance the needs of content, process, and people.
- Balancing content involves ensuring that the necessary user requirements are delivered at the right level of detail and with the necessary degree of quality.
- Process balancing requires the facilitator to design a sequence of activities that follows a logical progression within the specified time constraints, to promote participation, and to keep participants energized and engaged.
- Balancing people needs is also a key responsibility of the facilitator. This involves helping participants to build their relationships, exploiting the strengths of different styles of thinking, learning, and interacting, and helping participants become a high-performing group.
Workshops And Iterative Development
Many software projects with fast delivery cycles have adopted an iterative development life cycle. This involves delivering cohesive chunks of the product incrementally over the course of numerous releases. In each release, you use a development life cycle that loosely follows the stages of defining, designing, developing, testing, and implementing.
With this technique, you can initially focus your workshops on high-priority areas and get started with software development, deferring lower-priority requirements for later exploration. This approach reduces the risks associated with trying to get all the requirements right at the very beginning of the requirements stage.
Iterative life cycles make use of prototypes to elicit or verify requirements. This method gives customers and users early visibility of the software, and that tends to promote their ongoing involvement. Iterative prototyping complements, or can be integrated into, requirements workshops. Workshops are woven into early iterations either to define the requirements in terms of a prototype or to create a low-fidelity prototype: a representation of screens or screen flows created on a whiteboard or poster or with posts (sticky notes) on a wall. These types of prototypes tend to reduce the risks associated with software prototypes.
Size matters, so be careful not to overload the workshops with too many people. The number of participants should not exceed 16 unless you use 2 facilitators. Most workshops have between 7 and 12 participants. Each additional person can add more time to the workshop or reduce the number of deliverables. Strive for the minimum number of participants who can represent the collective needs of customers, users, testers, designers, and analysts.
The Evolution Of Requirements
Requirements define the operational capabilities of a system or a process that must exist to satisfy a legitimate business need. The generic term requirements covers both functional requirements, which specify the functionality that users expect, and nonfunctional requirements, which include user quality attributes such as performance; system requirements such as security and maintainability; and system constraints such as database and language.
Taken together, these types of requirements are based on business requirements: the reasons for undertaking a project. No requirements should exist without a good business reason that make them valid. Each requirement should be testable and verified throughout the development process.
Figure 2-1 shows the various requirements levels and illustrates how they evolve.
Figure 2-1 Requirements Levels (Based on Wiegers, 1999)
Business requirements are the higher-level needs that, when addressed, will permit the organization to do things such as increase revenue, reduce costs, improve service, and meet regulatory requirements.
Business requirements are usually defined in a project charter document that answers the question, Why do this project? (Some organizations call the document a vision document, initiation document, or business case.) The business requirements in this document are typically written in broad strokes. For example, your charter might include a list of software features or functions such as “provide users with an easy-to-use and up-to-date inventory search capability.” These functions, in turn, should be associated with one or more business goals, such as “retain existing customers.”
Your charter is a tool for marshaling people, money, and other organizational resources. Many organizations require sponsor sign-off of a formal charter document before any project is launched. The charter document should describe the project infrastructure in terms of the six questions to be answered:
- Why: business vision, goals, and objectives
- What: organizational, financial, temporal, and functional scope
- Who: staffing, roles, and responsibilities
- How: project controls; success metrics; assumptions and critical success factors; team and user education, coaching, and training; risks and risk mitigation strategies
- Where: locations of staff and potential users and customers
- When: high-level work plan and release strategy
User requirements bridge the requirements of the business and the requirements of the software. It’s this bridge that’s most often difficult to cross because the languages, models, knowledge, and work styles of the players on either side are different. This is where I using workshops to facilitate understanding while concurrently creating the models to represent the needs of business stakeholders.
Gause and Weinberg (1989) broadly define a user as anyone who affects or is affected by the product. This definition includes people and things (devices, databases, external systems) that interact directly with the system being modeled as well as other people and things that receive system by-products (decisions, secondary reports, questions). To elicit user requirements more completely in workshops, you may need to include stakeholders other than direct users.
You can specify user requirements in a separate user requirements document. This document typically includes the definitions of stakeholder classes, functional scope, detailed user requirements, quality attributes such as speed, usability, and capability (if possible), and general attributes such as priority, version, and status. Or your organization might choose to integrate user requirements into your software specification document. Some organizations include user requirements in their charter document.
Software operates within certain constraints, which are the functional and nonfunctional requirements that make up software requirements. The doing parts of software are the functions that derive directly from your user requirements. Typically, these functions are expressed as text decompositions of a list of user requirements. In classic software engineering, functional requirements are decomposed into lower-level functions, forming a functional hierarchy.
The being parts of software are the nonfunctional needs that must be satisfied, including the users’ desired quality attributes, technical requirements related to auditing and security, quality attributes such as capacity and reliability, and constraints such as platform and database. These nonfunctional requirements are often critical distinguishing aspects of a software product. After all, you certainly would not use a Web site that is slow or unreliable. For this reason, it is important to discover nonfunctional requirements, which you can often elicit simultaneously with functional requirements.
Model Views, Focuses, And Levels Of Detail
You model primarily to facilitate communication. Models can be depicted with words, drawings, or both. The process of modeling allows you to elicit, discover, and specify views of the problem domain or other area of study. To select the most appropriate requirements models to use in your workshop, you must understand their basic purposes and what they can communicate. Figure 2-2 presents the concepts I use to help you gain that understanding: model view, focus, and level of detail.
Figure 2-2. Model View, Focus, and Level of Detail
Many of us know about the six great focus questions: who, what, when, where, why, and how. Rudyard Kipling’s poem “The Elephant’s Child” refers to these questions as the “six honest serving men.” John Zachman (1987) uses them as the “columns” of his systems architecture. Journalists use them as guidance for writing a story. I use these questions as a shortcut to describe the requirements models according to focus, as illustrated in Figure 2-4.
Table 2-2 Focus Questions Versus Requirements Models
A Shared Purpose
Unproductive requirements meetings are like any other unproductive meeting: They are boring and longer than they should be. Topics move in circles. Conclusions and decisions are elusive. Not everyone participates (whereas some participate too much). The content moves up and down with regard to the level of detail.
Requirements workshops offer a better way to gather requirements quickly and decisively because the purpose of these workshops is crystal-clear. Before the gathering, the stakeholders in the requirements process perform considerable work to ensure a successful workshop. Among the outcomes of that pre-work is a clear, concise statement of purpose—the shared purpose—that all the participants understand and share a stake in. To begin with the end in mind, a requirements workshop begins with a statement about the workshop’s purpose.
To make the best use of your shared purpose, you should implement these keys to success:
- Before your requirements workshops, hold a project charter or “visioning” workshop if the purpose isn’t as clear as it should be.
- If the scope of the requirements is unclear, conduct a scope workshop.
- Plan for your workshops as the project is being commissioned.
- Ratify the workshop’s statement of purpose with project stakeholders beforehand.
- Remind the participants about the workshop’s purpose throughout each session.
- Note also the following interactions and trade-offs associated with a shared purpose:
- Performing information gathering while you are trying to define the purpose helps you to identify the right people for the workshop (see the next section).
- There is a time trade-off between conducting a workshop sooner and doing it later after you have defined the shared purpose.
The Right People
You accelerate your project by having the right people together at the same time and in the same place to clarify your requirements. The right people means customers, users, and software suppliers. Each of these groups has gaps in its knowledge and experience that another can fill:
- Customers are sometimes disconnected from the work context of direct users.
- Users sometimes do not know the “big picture” that provides a context for funding a project.
- Users as well as customers may not have a grasp of the technical trade-offs they face when defining some of their requirements.
- Suppliers may not understand customers’ pressures and the day-to-day task needs of the users.
One of the outcomes of your workshops is to ease communications among these sometimes incongruent groups. A well-planned and well-run workshop is a forum for listening, sharing, and learning for each group.
Having the right people requires sponsorship. The very acts of identifying these people before the workshop, gathering them during the workshop, and dealing with them appropriately after the workshop communicate volumes to the project team about the importance of getting it right, fast.
The following risks are associated with trying to find the right people:
- Having to fall back on surrogate (substitute) users instead of the actual direct users
- Concerns about freeing up key people to attend the workshop
- Concerns about travel expenses
- Not having decision makers in the workshop
- Failing to involve people who have downstream stakes in the workshop products
- To make the best use of the right people, you should implement these keys to success:
- Obtain both business and software sponsor commitment.
- Conduct reviews of workshop deliverables with the larger user community.
- Make a business case for having the right people at the workshop.
- Ensure that workshop participants are included in reviewing and reaching closure on any post-workshop deliverables.
- Provide incentives for participants, such as toys and fun in the workshop, release from some normal work responsibilities, and recognition from management and peers after the workshop.
- Note also the following interactions and trade-offs associated with identifying the right people:
- Defining the shared purpose (see the preceding section) helps in defining the right people.
- There’s a trade-off between delivering requirements of lesser quality with the help of surrogate users and delivering higher-quality requirements over a longer period of time with direct users.
The workshop sponsor makes it possible for people to be present, to prepare, and to participate in shared space. Funding for that time and workshop space is necessary.
Experienced software project managers of geographically distributed project teams have learned that even though technology can facilitate communications, the team must periodically gather in person to reconnect. After all, we are human, and people communicate in many ways other than words and pictures. We communicate with voice inflection, facial expressions, and the myriad nonverbal behaviors that are possible to read or hear only when we gather at the same time and place.
Shared space is not just a room; it includes places and tools that allow content to be shared by the participants. This includes whiteboards, posters, “sticky” walls or notes, colored markers, a laptop computer with a drawing tool and a word processing program, a printer, a laptop projector, a whiteboard recorder, digital camera, or any combination of these tools.
A requirements workshop is based on Aristotle’s premise that “the whole is more than the sum of its parts. The part is more than a fraction of the whole.” By your judgment, some of the participants are smart, experienced, and knowledgeable, whereas others may have less knowledge on certain content or less experience in software projects, or they may be newer to the project. Nevertheless, this collection of people is much wiser than any one person in the room. In other words, groups are wise.
The group’s strength lies in its diversity. Because software projects are rarely solo efforts—they require the collective efforts of numerous individuals—the work must be done by a community of people gathered for a shared purpose.
Highly regarded leaders recognize this. Consider those leaders you admire and seek to be near. They act more like facilitators than directors. They listen more than they talk. They trust more than they test. They challenge and cajole rather than threaten and scare. So, too, must you trust in this wisdom and engineer a group process that taps into the group’s collective wisdom and energy.
Note also the following interactions and trade-offs associated with this ingredient:
- Wise groups require the right people; group wisdom is promoted by the use of collaborative closure.
- There is a trade-off between gathering requirements in a linear manner, over a longer period of time, and gathering them in a shorter period of time during intense, highly focused workshops.
- Groups cannot be truly wise without the presence of an atmosphere of honesty and willingness to confront difficult project trade-offs.
All high-performing groups engage in serious play. This oxymoron has two meanings. First, it means playing with models as a means of innovation, invention, and collaboration (Schrage, 2000). This involves interacting with user requirements models during a workshop to shape requirements, which is the heart of the workshop activity. Serious play also means having fun in meetings as a means of enhancing the group’s productivity, energy, and relationships.
The group often holds celebrations, and the participants tease and cajole one another, all the while producing results. Without a doubt, the most productive and memorable workshops include elements of fun. Humor serves to relieve tension, introduce joy, and courteously reveal difficult truths.
You can facilitate fun for a group by using playful activities and tools such as colored pens, sticky notes, and toys. Use whatever is fun and reinforces the principle that everyone contributes to finding incomplete or incorrect requirements and, most importantly, helps the group achieve its goals.
A group with trust acts interdependently—relying on its members’ mutual strengths and putting faith in individuals’ skills and knowledge, helping them feel secure that they can do their best. They are able to recover from problems quickly and without personal offense. In workshops, this can have powerful effects. Trust saves time, and that enables quicker delivery of products of higher quality. Better yet, these behaviors tend to get transferred to the project as a whole, and teams begin to jell.
The irony is that it takes time to build trust, but once it is established, it saves time. Many of us are impatient or unwilling to make the time in our workshops to build trust. This effort must commence at the outset. You begin to build trust before the workshop, and then you choose activities early in the workshop that reinforce a sense of safety and mutual trust.
“Evolution is chaos, with feedback,” said physicist Joseph Ford. To learn and grow, we must reflect on our thinking and work. In the long run, the act of slowing down to reflect has the effect of permitting the group to speed up.
The ritual of frequent debriefs, which involve participants reviewing, playing back, and thinking retrospectively about how the group process is working (or not working), is essential to ongoing success. These debriefs can be scheduled into the workshop but are often initiated by the facilitator when she notices a conflict brewing, a task that is completed, the emergence of an important issue not previously surfaced, or some other significant group occurrence. Debriefing during requirements workshops allows the group to become more self-sufficient and productive more quickly.
Asking a group to reflect on its work and its interactions helps it to evolve more quickly through the natural progression of group formation. It also promotes internal and public commitment to both the products of the workshop and the processes used to arrive at them.
If you now successfully have gotten all the requirements then it is time for Software people to try out the newest technologies, tools, and methods to solve your development needs. Now they shall code and building the right software since the requirements are clear.