A term project: Please review attachment is details of the assignment # 2 – Requirement Document, and Design Document (assignment # 3). In this discussion thread, you will ask me questions about the term project as if I am your client (teacher).
For the project in this course I will act as the `client`.
This is the start:
I would like a computer system to manage my small zoo. I would like for it to keep track of all the animals and their needs and the staff and volunteers. There is no need to keep track of financial data. I have a system for that, but this system would need to interface with that one eventually. If I like the final version enough, I might want to market this to other small zoos.
Here is an initial list of functional requirements:
The program must be able to:
• Mange the needs of the animals, such as feeding, medications, care, etc.
• Keep track of my workers and volunteers, such as availability, work schedule, etc.
• Contain a web interface for easy access to the application.
The first project deliverable is a requirements document (assignment # 2) that must be approved by the client. I have given you very little to work with, so start by considering what the client might require from such a product.
The program must be developed using an OO approach and must be able to run on typical MS Windows computers.
Please read an attachment is a “Proj-Discuss” file for the conversation of students & client (teacher)
A) Requirements Document - Due June 26
The goal of this assignment is to create a requirements document for a software
project we will discuss in class over the forums. This document should address the
system requirements and should not include design issues. At a minimum your
requirements document must contain:
• Document Title
• User Requirements Definition
Fully-elaborated Use Cases and Scenarios
• User Interaction
• Risk Analysis
Please see the attachment is Requirement Document (part A).
The key to design is a good understanding of the requirements of the system. The requirements document captures the functional and non--functional requirements of the system we will eventually develop. When I read your document I am looking to get an understanding of how the system will work. For example, how will the system look on startup. How will the user create a new album? How will the user add a photo to an album? And so on.
The Requirements Document should address the system requirements and should not include design issues. At a minimum your requirements document must contain:
• Document Title
• User Requirements Definition o Functional Requirements
o Fully--elaborated Use Cases and Scenarios o Non--functional Requirements
• Requirements prototyping o Screen Layout/Screenshots
• Risk Analysis
Use--cases are a great way to address requirements. The use--case diagram (stick-men and bubbles) is only the starting point for your UML diagrams. Fully elaborated use--cases are a very powerful way to analyze requirements. For example, suppose we have a use--case called "Add photo to album". What is the purpose of this use-case? What are the pre--conditions? Must the album already be selected or is this part of the use--case? What happens during the use--case? What are the post-conditions? Is their exception flow in addition to normal flow?
Requirement prototyping can help refine and further elaborate your requirements. Creating screenshots of the use cases or requirements can help user visualize the system and helps identify underlying requirements. You can include screenshots within the body of the use case or you can place all screenshots in an appendix and refer to them from the use--cases. You will normally have at least one use case for each functional requirement ---- this is just a general notion ---- but it`s a good place to start.
There are many Requirements Document Templates available online. If you already
have a template that you have used in the past, please feel free to use it in this course as long as it covers the areas listed above.
• Introduction, including title and date – 10 points
• Glossary – 10 points (based on completeness of terms)
• User Requirements Definition -- 45 points (based on accuracy and completeness of elaboration)
• User Interaction – 25 points (based on completeness and reflection of requirements)
• Risk Analysis – 10 points