Note: this is a “living document”, meaning its content will change with the implementation of the project. Use it to capture key project requirements and make sure that your product features match the requirements exactly – if you wish to add any features, they must be added first to the requirements. The requirements document, and all changes to it, must be approved by the customer (instructor).
Your are strongly encouraged to continue updating this document with clarifications and details. Clarifications should be indicated [in square brackets].
Remove this text and the descriptive paragraphs in each section stating what to do before you add this to your repository or turn it in to your instructor.
We represent a funding group (Investiny Corp.) chartered to create applications for the benefit of communities all around the country. The product we envision is called Tool Share. At its core, Tool Share is meant to enable neighbors in a community to be able to share items of common use. The successful implementation should make it easy to anyone wanting to participate to register and be able to share or borrow items.
The Tool Share product is intended to improve communities by providing and easy mechanism for sharing items between neighbors. We envision this to primarily consist of tool exchanges but the implementation must be easily extended to include items of different kinds.
We want a product whose emphasis is on ease of use, whose navigation is straightforward and where the status of items and users is clearly displayed.
Replace this text and the instructions below with your statement in black. (2-5 lines describing the problem being addressed. Note that even if you are simply restating what is already in the needs document, you must rephrase it in your words. This gives an opportunity for the customer to identify and provide feedback on differences in interpretation, if any).
Replace this text and the instructions below with your list in black.
Investiny Corp. Board of Directors – oversee the projects funding and expenses. Have vested interest in the proven success of the product but are not involved in the planning and execution.
Investiny Corp. Product Owner – will act as principle representative for Tool Share product needs. He/she champions the product with the Board of Directors, helps facilitate product decisions and has the ultimate say on when and what features should be released.
Software Engineering Team – is responsible for the day-to-day operations and coordination of all aspects related to the software product's life-cycle. This include, among others: planning and delegation of team roles and responsibilities; elicitation and clarification of requirements; analysis and design; implementation, testing and release of all software components.
Beta Testing Team – represent the target user base for Tools Share. Will be available in later phases of the project to conduct acceptance testing and provide feedback on product release.
Replace this text and the instructions below with your statement in black. (Identify who will be using the system, in what mode, and their profile in terms of familiarity with using computers and such software. If taking material from needs document, then rephrase in your words).
The target user must:
- have basic experience using computers and browsing the internet. Has filled out online forms or surveys and may have purchased or sold a product.
- have a computer with access to the internet
- have an interest in improving their community by lending or borrowing items of common use with others living near by
- is willing to share information such as home address and contact information
Replace this text and the instructions below with your statement in black.
(1 or more lines identifying the system requirements for your solution. If you require particular languages and libraries, list them as well).
At a high-level this project will be source controlled in SVN, run on Django using python, sqlite and needs to be compatible with the latest browsers.
Although the application needs to be accessible through the internet, deployments and demonstrations for this phase of the project will take place within the RIT Software Engineering environment. To this end, you must understand and document the target platforms from the perspective of the client browser as well as that of the server. Make sure to capture versions or software dependencies, programming languages and hardware specifications that are available for your use and proceed only after you document and confirm these with the customer.
Feature requirements (user stories)
Read the instructions below and fill in the table. Delete all the blue text before adding this to your repository or turning it in to your instructor. (This is a numbered list of user stories that are the features of the system to be implemented. Each user story is an operation that the user can perform on/with the system. For each user story, provide a fairly detailed description so you know what to build and so you can write a test case to demonstrate that your system provides that feature. For each user story, you will identify (during release planning) the release in which it will be implemented: R1, R2 or R3. Typically, your system will have 10-20 stories or features, but feel free to add more table rows if you decide to use finer-grain stories).
The following list of user stories is neither final nor comprehensive. You must consider it your responsibility to maintain it's relevance, clarify any misunderstandings and keep it up-to-date. Any changes must be discussed with the Product Owner for approval.
User Story Name
Registrant shall provide personal information and preferences to the System upon registering and becoming a User. (for example: Last name or Pickup Arrangements)
System will create a new Share Zone upon registration of User with previously unregistered zipcode
Upon registration System will associate user with an already created Share Zone based on zipcode
Account Management - change personal info
User shall be able to change personal information after registration (for example: change address).
System will warn User if changing of community and effect any necessary changes to the item list.
Account Management - change user preferences
User shall be able to change preferences after registration (for example: email reminder frequency, pickup arrangements)
Community Shed creation
User shall be able to create a Shed for his Share Zone.
A Shed has a physical location where tools from several Users can be stored.
Shed creator becomes Coordinator of said shed.
Tool Management – registration
User can register a tool by providing items information. (for example: Picture, Category, Name, Description, Special instructions, etc.)
System will require a unique field to distinguish between similar tools (for example: two laser blasters but mine has “Buzz A 113” edged on its handle)
User must accept default Pickup Arrangement (set during User registration) or select a different arrangement for this tool (for example: “Please knock on my door” vs. “Let's make additional arrangements via email”)
Sharing – from Home
User can set a previously registered tool to be shared from home.
Tool cannot be shared from two places simultaneously
User must physically have possession of tool prior to sharing it.
User can change a previously registered tool
User can set a previously registered tool to be shared from a Community Shed.
Tool cannot be shared from two places simultaneously.
User must physically move the tool to Shed prior to being allowed to share it.
Shed Coordinator can, from time to time, verify and change status of tools in Community Shed (for example: a tool was returned but never marked as present or tool has gone missing)
Sharing – change location of tool
User can change a previously registered tool to be shared elsewhere.
System will prevent relocation when tool has an unresolved future reservation.
Sharing – change availability
User can availability of a tool. (for example: on black out dates when he/she will be using the tool, or be away/unwilling)
System will notify User upon a request to borrow his/her tool.
User owner of tool must approve the borrower when his/her tool is not at a Community Shed.
System will notify borrower of decision by owner and update tools status if necessary.
Tool Listing – availability
User can request from System a list of all tools and their availability. List shall be sorted by System.
Only tools in User's Share Zone will be visible
Borrowing - request
User can select to borrow a tool for specified days provided tool is available. Borrower can add a message to request.
User owner of tool will need to “Approve” or “Reject” the request to borrow unless tools is in a Community Shed were it is always automatically approved.
Upon approval, System will create Reservation with requested dates and update availability of a borrowed tool.
Upon rejection, owner of tool must provide a small reason for “Reject”.
System will send notification email to borrower or lender including reason or message where applicable.
Borrower will return tool pickup location unless otherwise agreed with tool owner.
Borrower will notify the System that tool has been “Returned”
User owner of tool will need to notify/acknowledge to the System that tool has been “Returned” unless request to borrow was made from a Community Shed were it will be acknowledged by Shed Coordinator.
System will update availability of a returned tool.
Tool Management – deactivation and reactivation
User can deactivate a tool they previously added to the System. Neither the tool nor its reservations are shown by default, but the system still retains the information about the tool. A tool may be re-activated at any time.
System will require confirmation in case of possible conflicts.
System will notify borrowers of tool being deregistered and update relevant information to disable availability of tool.
Tool Management – Status
User owner of tool can request from System a list of registered owned tools and their status.
User can request a list of statistics for their specific Share Zone. Upon request System will verify association and display such listing.
Statistics that may be included:
Read the instructions below and fill in the content. Delete all the blue text before adding this to your repository or turning it in to your instructor.
Draw the UML use case context diagram for the system. As you update, make sure the use cases shown in the diagram correspond to the user stories described in the previous section and vice versa. A partial sample breakdown is provided.
Delete all the blue text and fill-in the template before adding this to your repository or turning it in to your instructor.NOTE: In order to avoid confusion, it is STRONGLY encouraged to complete all use cases prior to implementation. Use the template and example provided as a guide.
Use Case Number:
UC-XX (Replace XX with a number)
Use Case Name:
Enter the name of Use Case
Describe the purpose of the Use Case and give a 1-2 line description. This could be the same as the description provided for the user story.
List all actors that participate in this Use Case.
Enter the condition that must be true when the main flow is completed.
Main (success) Flow: Steps should be numbered.
Alternate Flows: Include the post condition for each alternate flow if different from the main flow.
Enter the condition that must be true when the main flow is completed.
Sample Use Case:
Use Case Number:
Use Case Name:
Registrant shall provide personal information and preferences to the System upon registering and becoming a User.