{"id":3083,"date":"2012-09-13T16:59:32","date_gmt":"2012-09-13T23:59:32","guid":{"rendered":"https:\/\/www.jamasoftware.com\/?p=3083"},"modified":"2023-01-12T16:57:08","modified_gmt":"2023-01-13T00:57:08","slug":"cosmic-truths-about-software-requirements-part-2","status":"publish","type":"post","link":"https:\/\/www.jamasoftware.com\/legacy\/blog\/2012\/09\/13\/cosmic-truths-about-software-requirements-part-2\/","title":{"rendered":"Cosmic Truths about Software Requirements, Part 2"},"content":{"rendered":"

The first article in this series presented three \u201ccosmic truths,\u201d realities about requirements that I\u2019ve discovered to apply to virtually all software projects. This article continues with three more such insights, focusing on requirements and the project stakeholders.<\/p>\n

Cosmic Truth #4: The interests of all the project stakeholders intersect in the requirements process.<\/h2>\n

Consultant Tim Lister once defined project success as \u201cmeeting the set of all requirements and constraints held as expectations by key stakeholders.\u201d A stakeholder<\/i> is an individual or group who is actively involved in the project, who is affected by the project, or who can influence its outcome. Figure 1 identifies some typical software project stakeholders. Certain stakeholders are internal to the project team, such as the project manager, business analysts, developers, and testers. Other stakeholders are external, including customers who select, specify, or fund products; users who employ the systems; compliance certifiers; auditors; and marketing, sales, and support groups. The business analyst performs a central communication role, being responsible for interacting with all these stakeholders. Further, the BA is responsible for seeing that the system being defined will be fit for use by all customers, perhaps working with a system architect to achieve this goal.<\/p>\n

\"\"

Figure 1. Some typical software project stakeholders.<\/p><\/div>\n

Identify your key stakeholder groups at the beginning of the project. Then determine which individuals will best represent the interests of each group. You can count on stakeholders having conflicting interests that must be reconciled. They can\u2019t all have veto power over each other. You need to identify early on the decision makers who will resolve these conflicts, and these decision makers must determine what their decision-making process will be. As my friend Chris, a seasoned project manager, points out, \u201cI have found that there is usually one primary decision maker on a project, oftentimes the key sponsor within the organization. I don\u2019t rest until I have identified that person, and then I make sure he is always aware of the project\u2019s progress.\u201d<\/p>\n

Cosmic Truth #5: Customer involvement is the most critical contributor to software quality.<\/h2>\n

Various studies have confirmed that inadequate customer involvement is a leading cause of the failure of software projects. Customers often claim they can\u2019t spend time working on requirements. However, customers who aren\u2019t happy because the delivered product missed the mark always find plenty of time to point out the problems. The development team is going to get the customer input it needs eventually. It\u2019s a lot cheaper\u2014and a lot less painful\u2014to get that input early on, rather than after the project ostensibly is done.<\/p>\n

Customer involvement requires more than holding a workshop or two early in the project. Ongoing engagement by suitably empowered and enthusiastic customer representatives is a critical success factor for software development. Following are some good practices for engaging customers in requirements development (see my book Software Requirements, 2nd Edition<\/i> for more information about these practices):<\/p>\n

Identify user classes.<\/b> Customers are a subset of stakeholders, and users are a subset of customers. You can further subdivide your user community into multiple user classes that have largely distinct needs. Unrepresented user classes are likely to be disappointed with the project outcome.<\/p>\n

Select product champions.<\/b> You need to determine who will serve as the literal voice of the customer for each user class. I call these people product champions. Ideally, product champions are actual users who represent their user-class peers. In some cases, though, you might have limited access to actual users, so you need to employ surrogates to speak for certain user classes to the best of their ability. Such surrogates might be subject matter experts or marketing personnel. When developers are forced into the position of trying to identify user needs, they often don\u2019t do a great job.<\/p>\n

Build prototypes.<\/b> Prototypes provide opportunities for user representatives to interact with a simulation or portion of the ultimate system. Prototypes are far more tangible than written requirements specifications and easier for users to relate to. However, prototypes aren\u2019t a substitute for documenting the detailed requirements. You also have to watch out for the risk that users who evaluate prototypes will conclude that the system is almost done and press the development team to release the prototype as a delivered product. This is usually a disaster.<\/p>\n

Agree on customer rights and responsibilities.<\/b> People who must work together rarely discuss the nature of their collaboration. The BA should negotiate with the customer representatives early in the project to agree on the responsibilities each party has with respect to the requirements process. An agreed-upon collaboration strategy is a strong contributor to the participants\u2019 mutual success.<\/p>\n

Cosmic Truth #6: The customer is not always right, but the customer always has a point.<\/h2>\n

It\u2019s popular in some circles to do whatever any customer demands, claiming \u201cThe customer is always right.\u201d Of course, the customer is not<\/i> always right! We all know this. Sometimes customers are in a bad mood, uninformed, or unreasonable. If you receive conflicting input from multiple customers, which one of those customers is \u201calways right\u201d? It\u2019s a silly philosophy.<\/p>\n

The customer might not always be right, but the BA needs to understand and respect whatever point each customer is trying to make through his request for certain product features or attributes. The BA must be alert for situations in which the customer could be in the wrong. Rather than simply promising anything a customer requests, strive to understand the rationale behind the customer\u2019s thinking and negotiate an acceptable outcome. Following are some examples of situations in which a customer might not be right:<\/p>\n