3. Methodology
6.2. Requirements Engineering, First Iteration
Based on the literature and the user interviews, different requirements are created. These requirements are altered, removed or new ones are added after prototype evaluations. In this section, usability heuristics and accessibility requirements are introduced: these are not included in the user requirements, but they are delivered to the developing parties as additional general requirements.
6.2.1. User and Literature Requirements
As described in Section 3.5.2.5., the user requirements are presented in a MoSCoW structure. The division of requirements into the MoSCoW structure is based on the interviews and literature. Some features are mentioned as being absolutely necessary on the webpage: these are translated into ‘Must’ requirements. Statements that are made multiple times and that are deemed relatively important are translated and added as ‘Should’ requirements. Some suggestions are made that can be a nice addition to the website, but that are not essential and are not mentioned multiple times. These are added as ‘could’ requirements and are implemented if time and the design of the website allows. ‘Won’t’ requirements include suggestions made that are not implemented in this version of the website due to wishes of the company, but can be considered for future iterations of the website. As stated before, the homepage is also the landing page of the website and, therefore, has requirements of their own. The different requirements are as follows:
Must:
1. The website must contain contact options 2. The website must contain links to sources 3. The website must contain company information
4. The website must contain information about the organisation (team) 5. The website must contain privacy information
6. The website must contain information about the implementation of Reducept 7. The website must contain information about the dashboard
8. The website must contain experiences of patients with Reducept 9. The website must contain experiences of practitioners with Reducept 10. The website must contain research Reducept is based on
12. The website must include pricing information
13. The website must include reimbursement possibilities
14. The website must mention that Reducept is an addition to treatment, not a replacement of the practitioner
15. The website must contain information about the ease of use of the VR technology
16. The website must contain information about Reducept providing both pain education and management strategies
Should:
17. The website should contain information that is actively updated 18. The website should include multimedia content
19. The website should contain downloadable content for information 20. The homepage should contain information about what Reducept is 21. The homepage should contain information about how Reducept works
22. The homepage should contain information about how Reducept helps patients 23. The homepage should contain information about how Reducept helps practitioners 24. The website should include the educational background of the team
25. The homepage should not contain pricing information
26. The user should be able to request a demonstration through the website 27. Large texts should be expandable to show more details
28. The website should contain visuals
29. The website should contain information about the mental aspect of pain 30. The website should contain information about Reducept for mobile Could:
31. The website could include timestamps
32. The website could include downloadable shareable content 33. The website could contain a movie about how Reducept works
34. The website could contain the pros and cons for patients and practitioners
35. The website could contain information about the content of the educational training 36. The website could contain a section for patients to receive information
37. The website could include a blog 38. The website could include an FAQ page
39. The website could include events where RelieVR BV will be present Won’t:
40. The website won’t adapt to the visitor for specific work domains
Overall, including a professional look and feel with good aesthetics should be included in the website. Moreover, the website should not have too much text. However, since these are subjective statements, they cannot be translated into requirements.
After discussion, it is decided that the website will not adapt to specific professions. If the website would adapt, the information would duplicate over different webpages, leaving less space for distinctive information. The alternative would be that multiple websites would need to be created, which does not fit within the budget. Therefore, it is decided to look creatively at displaying information in such a way that multiple professions would feel as if the website is created for them specifically, without altering the content to fit specific professions. Moreover, you don’t want people to feel excluded if they are not specifically mentioned if you make separate pages.
6.2.2. Usability Heuristics
The usability heuristics by Jakob Nielsen (1994) included in Appendix A are used in order to create a more usable website. Based on the heuristics, the requirements are created that deemed relevant to the content and goal of the webpage:
1. Links are identifiable as links (mentioned, underlined, different colour)* 2. Links are clickable**
3. Link phones automatically to mobile websites** 4. Familiar icons*
5. Menu titles readily have understood meanings*** 6. Menu titles are parallel grammatically***
7. Terminology used in accordance with user’s task domain*** 8. Menu shows location of user on the website**
9. System waits for user response before submitting a form** 10. System asks users to check data before submitting a response**
11. Four colours used within design (additional colours for occasional use only)* 12. Menu items are consistent in title***
13. No use of all uppercase letters*
14. User actions named consistently across screens*** 15. Only vertical scrolling is used**
16. Information does not need to be remembered across screen** 17. Text-areas have breathing space*
18. Colour is not the only indicator of cue*
19. Contrast between colour is sufficient (WCAG 2.1. standards)* 20. Website includes a search bar***
21. Links describe where they lead (which webpage and new tab)** 22. Images are not larger than the screen*
23. Textual description of video provided***
24. Have multiple ways to navigate through the website***
25. User can indicate the level of details by expanding options in large texts** 26. Personal data protection is explained***
* Requirements relevant for (graphical) design of webpages ** Requirements relevant for developers of webpages *** Requirements relevant for content-creators of webpages
6.2.3. Accessibility Requirements: Designers
While designing the wireframes for the website, different accessibility guidelines must be kept in mind in order to comply with the Web Content Accessibility Guidelines (WCAG) 2.1. These guidelines form recommendations in order to make web content more accessible. If these guidelines are implemented, people of a broad range of functional diversity are able to interact with the web content. None of the participants of the design session have previously heard of these guidelines, but they are eager to implement them within the design. Therefore, whenever different aspects are discussed (e.g. multimedia content, footer, menus, etc.), the accessibility guidelines are consulted. As there are 76 different guidelines, it takes an excessive amount of time to check all of them during the design process. Therefore, the relevant accessibility guidelines for the specific design session are selected and presented to the designers as shown in Appendix O.
As explained in Section 3.5.2.4., there are different levels of accessibility guidelines. As complying with level A and level AA of the guidelines leads to a mostly accessible website, and this allows for more freedom in incorporating different functionalities, it is strived to include both these levels within the website. Level AAA is also considered throughout design and development of the website, but these guidelines are not incorporated if they require too much compromise on the development side.