CS 641 – Requirements Engineering Chapter 13. Reusing Requirements @ Dr. Ahmad F. Shubita

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. @ Dr. Ahmad F. Shubita

Reusing Requirements 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?" @ Dr. Ahmad F. Shubita

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. @ Dr. Ahmad F. Shubita

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. @ Dr. Ahmad F. Shubita

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? @ Dr. Ahmad F. Shubita

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. @ Dr. Ahmad F. Shubita

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. @ Dr. Ahmad F. Shubita

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. @ Dr. Ahmad F. Shubita

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. @ Dr. Ahmad F. Shubita

Sources of Reusable Requirements A domain is a subject matter area. A domain model is a generic model of knowledge that applies to any product built for use in that domain. You can reuse requirements or knowledge from: colleagues' experiences, existing requirements specifications, and domain models. @ Dr. Ahmad F. Shubita

Requirements Patterns Requirements Patterns imply a collection of requirements that make up some logical grouping of functions. Typically we use requirements patterns that capture the process for a business use case. Requirements Patterns improve the accuracy and completeness of requirements specifications and reduce the time needed . Requirements Patterns is usually an abstraction and you may have to do a little work to adapt it to your own needs. @ Dr. Ahmad F. Shubita

Example- Requirements Pattern A requirements pattern for selling a book in a shop is as follow: 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. @ Dr. Ahmad F. Shubita

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

A Business Event Pattern Context of Event Response The process context model is a summary of the subject matter covered by the pattern. Used 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. @ Dr. Ahmad F. Shubita

The Customer Wants to Buy a Product Pattern Example Process Context model @ Dr. Ahmad F. Shubita

Process Context model The Process context model defines the boundaries of the pattern and the Event Response. The arrows identify flows of data and material. Some flows come from or go to adjacent systems such as Suppliers or Customers. Other flows come from or go to stores of information such as Product. The individual requirements are inside the process Fill Order. Other ways of showing this pattern are using UML activity and sequence diagrams. @ Dr. Ahmad F. Shubita

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. @ Dr. Ahmad F. Shubita

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. @ Dr. Ahmad F. Shubita

The END… @ Dr. Ahmad F. Shubita