We have adapted a partial example project illustrating how you could use Volere to specify the requirements for a product that controls library loans.
Purpose of the Project
The User Business or Background of the Project Effort
The clients of Library Loans Ltd. are public and university libraries all over the world. Feedback from clients is that they have a high incidence of late returns of library book loans. Some books are never returned. We have decided to invest in this project because our market research indicates that the new functionality will be taken up by a majority of our customers. Also, potential new customers will be influenced to buy our software rather than that of our competitors. The changes to the software will help the libraries to minimize the late/non return of library loans. This project will produce a new version of our existing Library Management product.
Goals of the Project
-
Goal 1
- Purpose: To provide functionality to control the late/non return of library loans.
- Advantage: To avoid losses due to late or non return of books.
- Measure: At any time the library will know how many loans are outstanding and when they need to follow them up in order to avoid them turning into overdue loans.
-
Goal 2
- Purpose: We want to sell the new functionality to our existing customers.
- Advantage: To retain our customer base.
- Measure: 80% of our existing customer base will buy the new library loans software within 12 months of its release.
-
Goal 3
- Purpose: We want to increase our customer base.
- Advantage: To be the number 1 supplier of library software worldwide.
- Measure: 30% increase in the number of customers and revenue in our customer base within 2 years of its release. Refer to the sales projection graph SP2012.
Stakeholders
Scope of the Work
The Current Situation
The work of library loans is currently carried out with a mixture of file cards, Exel spreadsheets, Access databases, manual procedures and some custom built pieces of software including the Library Management System marketed by Library Loans Ltd. See the attached library business process models for details on the “how now” situation of how the work is carried out.
The Context of the Work
Business Use Cases
Scope of the Product
Product Boundary
The product scope diagram identifies the boundaries between the users (actors) and the product. This diagram is a summary of all of the product use cases (PUCs). You arrive at the product boundary by analyzing each business use case and determining, in conjunction with the appropriate stakeholders, which part of the business use case should be automated (or satisfied by some sort of product) and what part should be done by the user of the product. This task must take into account the abilities of the actors, the constraints, the goals of the project, and your knowledge of both the work and the technology that can make the best contribution to the work.
Product Use Cases
Functional and Non-Functional Requirements
Functional Requirements:
Traceability of Requirements to Product Use Cases:
We acknowledge that this page uses material from the Volere Requirements Specification Template.
Copyright © 1995 – 2019 the Atlantic Systems Guild Limited.
Try ReqView