CS 641 – Requirements Engineering Chapter 13. Reusing Requirements

Reusing Requirements In our everyday lives we all reuse knowledge. It is knowledge that we have gained by studying and practicing what we have already discovered for ourselves, or more often what others have already defined. Reusing Requirements reuse the knowledge that already exists and enhance it to suit our particular situation.

Reusing Requirements remember that engineers don't invent things when they can find something that can be reused." When specifying the requirements for a new product, you can often save a lot of effort if you start by asking, "Have these requirements or similar ones already been specified?"

What Is Reusing Requirements? When you take advantage of work that has already been done, your efficiency as a requirements gatherer increases significantly. Early in your requirements projects look for reusable requirements that have already been written, and incorporate these "free" requirements into your own project.

Reusing requirements making use of requirements written for other projects. They can come from a number of sources: a reuse library of specifications, other requirements specifications that are similar or in the same domain, or informally from other people's experience.

Reusing Requirements To determine whether you have any relevant reusable requirements, you need to know something about the work that you are investigating. When you run a project blastoff meeting, pay particular attention to the first seven sections of the requirements specification: The Purpose of the Project: Are there other projects in the organization that are compatible or that cover substantially the same domains or work areas? The Client, the Customer, and Other Stakeholders: Can you reuse an existing list of stakeholders, a stakeholder map, or a stakeholder analysis spreadsheet? Users of the Product: Do other products involve the same users and thus have similar usability requirements?

Reusing Requirements Constraints: Have your constraints already been specified for another project? Naming Conventions and Definitions: You can almost certainly make use of parts of someone else's glossary, rather than having to invent all of your own glossary. The Scope of the Work: Your project has a very good chance of being an adjacent system to other projects that are under way in your organization. Make use of the interfaces that have been established by other work context models.

At project blastoff time the subject matter of the context,/ Scope together with its adjacent systems and boundary data flows, should indicate the potential for reusing requirements from previous projects.

Sources of Reusable Requirements Once you know the Scope of your work, you can look for requirements specifications that deal with all or part of that context and use them as the source of potentially reusable requirements.

Sources of Reusable Requirements You can reuse requirements or knowledge from: colleagues' experiences, existing requirements specifications, and models.

Reusing Requirements One of the benefits of using a disciplined process for writing requirements specifications is that you naturally produce requirements that are more easily reusable by future projects.

Requirements Patterns Requirements patterns improve the accuracy and completeness of requirements specifications. You reduce the time needed to produce a specification because you reuse a functional grouping of requirements knowledge that has already been specified by other projects. To do so, look for patterns that may have some application in your project. Keep in mind that the pattern is usually an abstraction and you may have to do a little work to adapt it to your own needs.

Requirements Patterns Patterns imply a collection of requirements that make up some logical grouping of functions. For example, we can think of a requirements pattern for selling a book in a shop: Determine the price; compute the tax, if any; collect the money; wrap the book; thank the customer. If this is a successful pattern, then it pays you to use the pattern for any future bookselling activities, rather than reinvent how to sell a book. Typically we use requirements patterns that capture the processing policy for a business use case. If we use the business use case as a unit of work, As a consequence, we can treat it as a stand-alone mini-system.

A Business Event Pattern Example of a requirements pattern. This pattern is based on the response to a business event:

A Business Event Pattern Context of Event Response The context model is a summary of the subject matter covered by the pattern. You use the diagram to determine whether the details of the pattern might be relevant to the work you are doing. If the majority of these flows are compatible with the inputs and outputs of your event, then the pattern is probably usable in your project.

Processing for Event Response A large pattern can be partitioned into a number of sub-patterns. From this diagram, we can identify other potentially reusable group of requirements. Other ways of showing this pattern are to use a UML activity diagram, a sequence diagram, or a scenario.

Data for Event Response This class diagram shows the objects and associations between them that are part of the pattern Customer Wants to Buy a Product. whenever we need to specify requirements for a product we can potentially reuse some or all of this knowledge.

Summary If you reuse a requirement, you probably get the design and the code and objects for free. By reusing knowledge from earlier stages in the development cycle, you get the advantage of reusing the full product.

Quiz Briefly Describe the Sources of Reusable Requirements. List the advantages of using Requirements Patterns

The END…