CS 386 – Software Engineering Team Project – D.2 Requirements Grading: 30 points In this deliverable, you will report the results for the requirements engineering for your product. Structure your deliverable using the following sections.
Positioning Problem statement Provide a statement to summarize the problem solved by your project according to the following structure (which is based on the OpenUP Vision Template):
The problem of Finding time to accurately track work hours affects Hourly workers who lack a reliable shift the impact of which is Potential shorted paychecks, or unpaid hours
Example of a problem statement: “The problem of inefficient prioritization of homework assignments affects college students; the impact of which is delivering assignments past due and receiving low grades.” The problem should read as a problem (must be something bad that makes people spend time or money in an inefficient way.
The problem of finding time to accurately track all work hours affects hourly workers; the impact of which is the potential of shorted paychecks or unpaid hours.
Product Position Statement A product position statement communicates the intent of the application and the importance of the project to all concerned personnel. The product should mitigate the aforementioned problem. Provide a statement according to the following structure: For young adults / college students Who have trouble keeping track of their gross hourly income and overtime The (product name) Money Monkey is a money tracking app That that keeps track of any potential errors that might occur on a paycheck and ensures that the user is always being paid the correct amount Unlike ADP Our product has an aesthetic UI, which make the user feel trendy while keeping track of their income.
Example of a product position statement: “For college students who have many parallel homework assignments, MyPrioritizationApp is a planning app that crowdsources the identification of complexity and time necessary to accomplish assignments, supporting the informed prioritization; unlike myHomework Student Planner, our product does not rely on the judgment of a student who hasn’t started the homework yet.” Make sure your product position statement is related to your problem.
Product Proposition: For young adults and college students who have trouble keeping track of their gross hourly income and overtime, Money Monkey is a payroll tracking app that keeps track of any potential errors that might occur on a paycheck and ensures that the user is always being paid the correct amount; unlike ADP, Money Monkeyhas an aesthetic UI, which make the user feel trendy while keeping track of their income.
Value proposition and customer segment Report the value propositions and customer segments of your product. Make sure that your value proposition is coherent with the product position statement and contains the following elements: i) what your product is; ii) the target customer; iii) the value your product provides; and iv) why your product is unique.
Example: Value proposition: Money Monkey is a payroll tracking app that allows hourly wage workers to track the amount of money they have made on their shift, to ensure that the worker is being paid the correct amount and to mitigate any potential error with their paycheck. Consumer segment: College student who works on campus and needs to track their wages for a timesheet.
Grading criteria (3 points, 1 for each section): The content of the subsections should contain all the required elements, follow the provided template, and be consistent with each other. The text should not contain typos or grammar issues.
Stakeholders Make a list of all stakeholders of the project with a brief description of each one of them, emphasizing any responsibilities with the project. Examples of stakeholders include users, clients, competitors, detractors, developers, etc.
Grading criteria (1 point): The stakeholders can’t be too generic or specific. The list should reflect what was described in Section 1.
College students/highschool students working part time jobs Employees who work without a clock-in clock-out system Employers who could cut the wage of employees short
Functional requirements (features) Make a numbered list of requirements for your software. Just self-explanatory titles are enough at this point. Remember that requirements should deliver the value proposition and they must be consistent with the interviews you performed for the previous deliverable. You can talk again to your clients to help define the requirements. While writing the requirements, focus on capabilities needed and not on how they should be implemented.
Grading criteria (2 points): The list should be comprehensive (remember that you are not expected to implement all the requirements by the end of the course but you should list them). Follow the same pattern to describe all the requirements. The list of requirements should be coherent with the previous sections.
Non-functional requirements
Make a numbered list of non-functional requirements that are important for your software. Explain their importance. Follow the terminology of ISO/IEC 25010:2011. For each non-functional requirement, give an objective goal/measurement in order to provide verifiability for the requirement. You can find more details at the following URL: https://www.dropbox.com/s/o7jekzuxojc2ywo/ISO-IEC-IEEE-29148.pdf?dl=0
Grading criteria (2 points): Follow the ISO-IEC terminology, explain why they are important, provide verifiability criteria for each requirement.
Portability is really important so that the customers can log their hours from whatever they have access to at the beginning and end of their shifts. The goal should be to access the website from a mobile device and a PC. The software also needs good usability so that young users tracking hours for the first time are able to use it without challenges. This could be measured by having users test the software and rate the usability on a scale of 1 to 10.
MVP What will be your MVP? Which features are you going to validate? How?
Grading criteria (2 points): Describe what would be considered the Minimal Viable Product and how it will be tested (e.g., via implementation, prototyping, Wizard of Woz, etc.). Make clear what you are going to validate. The MVP should be coherent with the previous sections.
Use cases Use case diagram Include a UML use case diagram for your project. There are many drawing tools that you can use, such as https://app.diagrams.net/ and https://creately.com/
Grading criteria (5 points): Follow correctly the UML specification. The actors should be coherent with what was listed in sections 1 and 2. The use case diagram should be coherent with the list of requirements (section 3). The level of granularity of each use case should be adequate. The use cases should be adequately named.
Use case descriptions and interface sketch Present one complete use case description for each member of the group. Therefore, if the group has 4 members, 4 use case descriptions are necessary. As the grading will not be individual, the group is responsible for keeping the quality and consistency of the whole document – avoid just splitting the work. Choose the most important use cases to describe. Follow the template provided by OpenUP to describe the use cases (see also the example): https://people.cs.clemson.edu/~johnmc/courses/Publish/openup/guidances/templates/resources/uc_specification_tpl.dot
After each use case description, add a sketch of the corresponding user interface. This will be a good opportunity to start thinking about usability.
Grading criteria (8 points): Follow the template to describe the use cases. Present an interface sketch for each use case. Describe the use case as a dialog between the user and the system. Do not use UI language in the description of the use case.
User stories Write two user stories for each member of the group. They can be related to the same features described in the use cases or to different ones. Adopt the following format: "As a , I want so that ."
Establish a priority level for each user story and estimate how many hours each one will demand using the planning poker approach.
Grading criteria (6 points): Use the provided format. The user stories should be in an adequate level of granularity (not too broad nor too specific). Provide the priority and estimation for each user story.
Issue Tracker The user stories should be registered in your GitHub issue tracker. Include here the link for your issue tracker and a screenshot of what you did.
Grading criteria (1 point): Provide the URL and screenshot of the issue tracker. The user stories should be registered there.
Format You can find on BBLearn instructions for the format and submission of the deliverables.
Example from the previous semester (not necessarily perfect or complete) https://github.com/ChrisKeefe/DontPanic/blob/master/project_documentation/Requirements.md
See also several commented examples from previous years on BB Learn, in which I describe the most common mistakes in the sections above: https://docs.google.com/document/d/1HLrFTRupUPinqJviA6oOcDzRNZy2n4lSl8Mg7nLIMcQ/edit?usp=sharing
Additional grading criteria Your deliverable should have all the aforementioned sections and follow the instructions. The deliverable must be available on the GitHub repository and written in an md format. All headers should be larger text and bolded to stand out. The deliverable should be updated via pull requests, which should be reviewed and approved by the Quality Assurance person. The document should be written in an appropriate language.
Acknowledgment: Parts of this document were adapted from OpenUP Templates
Feedback Didn’t like this assignment? Do you have suggestions? Please, let me know. https://bit.ly/3vXiBCM