Closed AdrienPoupa closed 6 years ago
Goal: To create a subsystem, integrated in a SIS (Student Information System) in order to be used to collect statistics about students grades. The subsystem is named "Descriptive Statistics". The subsystem must be accessible by the SIS and usable by the students, the administration and the professors. Descriptive Statistics should always be available and not compromised in any way. The subsystem should compute the values in a timely manner. The data produced by Descriptive Statistics must be accurate.
=> only one non functional req
Question: How to ensure that the Descriptive Statistics is accessible by the SIS? Metric: Create integration tests to evaluate the connection between Descriptive Statistics and the SIS. This is an objective metric, based on the viewpoint on the subsystem.
Question: How to ensure the system is usable by the students, the administration and the professors? Metric: Conduct a survey using the Subjective Happiness Scale. This is a subjective metric, based on the viewpoint of the users.
Question: How to ensure the availability of Descriptive Statistics? Metric: Measure up time. This is an objective metric, based on the viewpoint of an external system.
Question: How to ensure the subsystem is reliable? Metric: Set a target of 100% code testing coverage. This is an objective metric, based on the viewpoint on the subsystem.
Question: How to ensure that Descriptive Statistics remains secure? Metric: Log connection attempts block the user from entering the system after a certain amount of failed logins. This is an objective metric, based on the viewpoint on the subsystem.
Question: How to ensure that the subsystem is efficient? Metric: Log execution time for all tasks and take actions if this monitoring reveals abnormal response time. This is an objective metric, based on the viewpoint on the subsystem.
Question: How to ensure that the statistics are accurate? Metric: Create unit tests using an oracle to make sure that the computation results are correct. This is an objective metric, based on the viewpoint on the subsystem.
=> Only one non functional requirement (eg: usability => easy to use, to operate, recover from errors etc), and go granular over it
Goal: explain in detail what is usability for each actor
Hint: find metrics, and ask questions from them (find a question from the metric)
We don't have to have a metric for each question
=> Add mechanism part, useful for alternate scenarios
New draft taking the following advices into consideration:
Goal: To create a subsystem, integrated in a SIS (Student Information System) in order to be used to collect statistics about students grades. The subsystem is named "Descriptive Statistics". The subsystem must be accessible by the SIS and usable by the students, the administration and the professors. Descriptive Statistics has to provide students statistics of their grades in an easy manner. Professors must be able to enter the grades and see the students' statistics quickly. The administrators must be able to oversee the system without any hassle. Descriptive Statistics must be able to recover from errors.
Note: in this document, "users" designate the actors of Descriptive Statistics; professors, students and the department to be more specific.
Question: How to ensure that the Descriptive Statistics is connected to the SIS? Metric: Create integration tests and assess their success to evaluate the connection between Descriptive Statistics and the SIS. This is an objective metric, based on the viewpoint on the subsystem. Mechanism:
Owner = Lead Developer Frequency Collected = Following Each Major Software Release Frequency Reported = Quarterly
Question: How to ensure the system is easy to use by the students? Metric: Conduct a survey using the System Usability Scale. This is a subjective metric, based on the viewpoint of the users. Mechanism:
Owner = Product Manager Frequency Collected = Following The End of the First Session Frequency Reported = Quarterly
Question: How to ensure the system is easy to use by the professors? Metric: Conduct a survey using the Computer System Usability. This is a subjective metric, based on the viewpoint of the users. Mechanism:
Owner = Product Manager Frequency Collected = Following The End of the First Session Frequency Reported = Quarterly
Question: How to ensure the system is easy to use by the department? Metric: Conduct a survey using the Computer System Usability at the end of the first session. This is a subjective metric, based on the viewpoint of the users. Mechanism:
Owner = Product Manager Frequency Collected = Following The End of the First Session Frequency Reported = Quarterly
Question: How to ensure that a professor can enter a grade in Descriptive Statistics in no more than 5 seconds? Metric: Calculate the Time-Based Efficiency. This is an objective metric, based on the viewpoint on the subsystem. Mechanism:
Owner = Lead Developer Frequency Collected = Every Day Frequency Reported = Quarterly
Question: How to ensure that professors, students and department does not give up on using Descriptive Statistics? Metric: Calculate the Completion Rate. This is an objective metric, based on the viewpoint on the subsystem. Mechanism:
Owner = Product Manager Frequency Collected = Every Day Frequency Reported = Quarterly
How to prevent errors in Descriptive Statistics? Metric: Record every error encountered by users in Descriptive Statistics. This is an objective metric, based on the viewpoint on the subsystem. Mechanism:
Owner = Lead Developer Frequency Collected = Every Day Frequency Reported = Quarterly
Question: How to ensure that Descriptive Statistics meet students', professors' and department's expectations? Metric: Use the Single Ease Question metric before and after a task to see the difference. in terms of expectations. This is a subjective metric, based on the viewpoint of the users. Mechanism:
Owner = Product Manager Frequency Collected = Before and After Every Task Frequency Reported = Quarterly
Question: How to ensure that Descriptive Statistics does not take more than one second for a calculation to complete? Metric: Log Load Time. This is an objective metric, based on the viewpoint on the subsystem. Mechanism:
Owner = Lead Developer Frequency Collected = Every Day Frequency Reported = Quarterly
Question: How to make sure that users are able to use the system autonomously? Metric: Record the Frequency of help and documentation use. This is an objective metric, based on the viewpoint on the subsystem and the support staff. Mechanism:
Owner = Product Manager Frequency Collected = Every Day Frequency Reported = Quarterly
Question: How many clicks does Descriptive Statistics require to complete the tasks? Metric: Record the Number of Clicks. This is an objective metric, based on the viewpoint on the subsystem. Mechanism:
Owner = Product Manager Frequency Collected = Every Day Frequency Reported = Quarterly
Question: How to make sure that the learning curve of Descriptive Statistics is smooth? Metric: Compare the Time-Based Efficiency for a first time user and a returning user. This is an objective metric, based on the viewpoint on the subsystem. Mechanism:
Owner = Product Manager Frequency Collected = Every Day Frequency Reported = Quarterly
Sources: https://usabilitygeek.com/usability-metrics-a-guide-to-quantify-system-usability/ https://measuringu.com/essential-metrics/ https://measuringu.com/predicted-usability/ https://designandresearch.wordpress.com/2010/03/15/usability-testing-metrics-jeff-seeley/ https://www.userzoom.com/user-experience-research/top-ux-measurements-key-performance-indicators-usability-metrics/
Review by TA: 1. available=> metric for tests UC name: Verb + noun No 2ndary actor Students should see more Actor inheritance Add Priority
Using the Goal-Question-Metric (GQM) approach (or one of its extensions), present one goal specific to DESCRIPTIVE-STATISTICS and articulate 2N questions related to that goal, where N is the team size. Discuss whether any metrics help answer those questions
=> We should create 2 * 6 = 12 questions, 2 for each team member
The Goal should exhibit non functional requirements