• Summary

<aside> 💡 Just because a requirement exists doesn’t mean it’s reusable in its present form. You might have to tune up the original requirements to increase their value to future BAs

• It could be specific to a particular project
• It might be written at too high a level because the BA could safely assume certain knowledge on the part of the development team or because some details were communicated only verbally
• A requirement could be lacking information about how possible exceptions should be handled </aside>

<aside> 💡 Well-written requirements lend themselves to reuse. Making requirements more reusable also makes them better requirements

The steps you take to make requirements more reusable also increases their value to the project for which you originally write them; it simply makes them better requirements

</aside>

<aside> 💡 Reuse saves your team time and money. Although making something readily reusable is likely to cost time and money

• It will take some effort to generalize the initially presented requirement
• That’s the investment you make in reusability, anticipating that you will recoup the investment—and more—through multiple, future reuse instances
• It’s up to you to decide whether to simply place today’s requirements into a shared location for possible reuse or to invest effort to improve their reusability on future projects </aside>

<aside> 💡 Reusable requirements must be written at the right level of abstraction and scope. Although it’s tricky to find the right balance between making reuse easier (with more abstract or generalized requirements) and making reuse pay off (with more detailed or specific requirements)

• Domain-specific requirements are written at a low level of abstraction. They are likely to be applicable only in their original domain
• Generic requirements have broader applicability for reuse in a variety of systems. However, if you attempt to reuse requirements at too general a level, you won’t save much effort because the BA will still have to elaborate the details </aside>

Accept payments

• Imagine you have an application that includes a user requirement to accept credit card payments. This user requirement would expand into a set of related functional and nonfunctional requirements around handling credit card payments. Other applications also might need to take payments by credit card, so that’s a potentially reusable set of requirements
• But suppose you could generalize that user requirement to encompass several payment mechanisms: credit card, debit card, gift card, eCheck, and electronic funds transfer. The resulting requirement offers greater reuse potential in a wider range of future projects. One project might need just credit card processing, whereas others require several of the payment processing methods
• Generalizing an initial user requirement like this—from “accept credit card payment” to “accept payment”—could be valuable even on the current project. Even if the customer only asked to handle credit card payments initially, users might really like to accept multiple payment methods either now or in the future

The “reusable requirements” explosion

A cautionary tale of how to reduce the potential value of reuse by writing excessively detailed requirements

• BAs decided to document all of the details for each requirement separately. A team tasked with writing requirements for a new project was obsessed with reuse. The BAs thought that if they documented all of the details for each requirement separately, then they could be reused
• They ended up with more than 14,000 requirements! The repository contained entries that should have been just one requirement but had been structured as a parent with multiple child requirements, each giving a specific detail about the parent. Requirements this detailed were relevant only to that one application
• It was hard to test these requirements, they also never did fully stabilize. This volume of requirements also made the testing cycle much more difficult, leading to daily complaints from the testers. It was taking them much longer than expected to write test cases because they had to wade through such a vast quantity of requirements. The testers had to document the requirement ID in their test cases to ensure that test coverage of the requirements was achieved for traceability, but the number of traces on this many requirements became difficult to manage. In addition, the requirements underwent extensive change; they never did fully stabilize
• All of these factors led to the project being deployed a year late, without producing the desired collection of reusable requirements