Requirements gathering

1. Requirements gathering Requirements gathering = System analysis This is the process of finding out what a client (or customer) requires from a software system. It has the purpose to find out about the client’s needs and to find out about inappropriate requirements, ambiguities etc.

2. Requirements gathering continued Techniques: Interviewing, observation, document analysis, cognitive and other task analysis techniques (e.g. how much memorising does a particular task require from a user). Examples: what problems do people experience with the present system, what do they recommend to improve the work process.

3. Requirements gathering continued Requirements gathering also helps the designer to analyse situations via the analytical process it involves. Its result is a representation of the problems with the current system and a representations of the requirements of the new system.

4. Requirements gathering continued Gathering requirements demands various analyses to be undertaken. Analysts should be aware that there are a number of techniques available for this purpose, e.g. paper-based checklists, interviews, prototyping, meetings, etc.

5. Requirements gathering continued These techniques closely resemble the ones that are used in evaluation. Requirements gathering and evaluation are closely related, because it is very important that designers understand the requirements.

6. Requirements gathering continued Requirements of a system: 3 Categories 1. Functional Requirements 2. Data Requirements 3. Usability Requirements

7. Requirements gathering continued 1. Functional Requirements Functional Requirements specify what the system should be able to do (when summarised in a formal document this is also called Functional Specification)

8. Requirements gathering continued 1. Functional Requirements continued This formal document is usually organised in a hierarchical manner and its display often consists of a chart such as a dataflow diagram. The dataflow diagram typically shows the process (circles) and the data flowing in and out of these processes.

9. Requirements gathering continued 1. Functional Requirements continued The data flowing in and out are represented as named lines. The sources of destinations of these data are represented as boxes.

10. Requirements gathering continued 2. Data Requirements Data requirements specify the structure of the system and the data that must be available for processing. Data requirements place weight on the structure as opposed to processing.

11. Requirements gathering continued 2. Data Requirements continued Moreover, data requirements aim to represent the entities and relationships that are required in an application and the constraints that apply to the data. In order to find out about this, data analysis is applied.

12. Requirements gathering continued 2. Data Requirements continued Data analysis tries to find out what data in particular are required by the system, how the data are structured and logically stored. In order to display the results of this data analysis, diagrams are used (such as data structure diagrams, entity relationship diagrams etc.).

13. Requirements gathering continued 2. Data Requirements continued In the context of requirements gathering, these diagrams provide conceptual models of the existing system, i.e. they tell what data are required.

14. Requirements gathering continued 2. Data Requirements continued However, there has been a considerable amount of criticism in terms of Entity Relationship Modelling, Dataflow Diagrams etc. It was argued that these forms focus too much on the system and too little on its users.

15. Requirements gathering continued 3. Usability Requirements …focus explicitly on the usability of the system. Usability dimensions should be captured in a way so that they can be translated into meaningful quantitative statements.

16. Requirements gathering continued 3. Usability Requirements continued e.g. the 4 dimensions of Shackel (1991) Effectiveness Learnability Flexibility Positive User Attitude

17. Requirements gathering continued 3. Usability Requirements continued In order to find out about usability requirements, techniques such as interviews and observation are applied. The activity of finding out about usability requirements is often known as usability study. This kind of study is closely related to system evaluation.

18. Requirements gathering continued 3. Usability Requirements continued Examples of usability requirements: User satisfaction Overall performance of the system

19. Requirements gathering continued 3. Usability Requirements continued 3 types of analysis are needed to find out about usability requirements: Task analysis User analysis Environment analysis

20. Requirements gathering continued 3. Usability Requirements continued How can we express usability requirements? Solution: through usability metrics, e.g. completion time for task, help manual etc., number of errors, percentage of task completed etc.

21. Requirements gathering continued 3. Usability Requirements continued It typically depends on the type of system that is being tested which measurement criteria apply. It also depends on the weight that individual errors, longer time spent on task, etc. would have in certain tasks.

22. Task Analysis The term Task Analysis stands for a range of techniques. Some tasks describe difficulties that may arise out of system implementation. Other tasks evaluate systems in terms of their usability etc.

23. Task Analysis continued Before talking more about tasks analysis, it is probably important to define the meaning of a task and how it differs from the meaning of a function. Function = activity that is performed by a person or machine. Task = A task is not the activity itself, but the perception of what needs to be done.

24. Task Analysis continued One could also say Tasks are meaningful assignments to the user, because they give the user an idea what needs to be done in order to complete this assignment, e.g. your different options of coursework could be described as different tasks.

25. Task Analysis continued On the other hand, the process when you engage to design and implement the user interface would be a function, because this would be an activity you perform, whilst the assignment is not an activity itself.

26. Task Analysis continued Alternatively, some task analysis techniques predict performance, measure learnability etc. Task analysis is based on approaches from psychology, software engineering and ergonomics.

27. Task Analysis continued Task analysis explains what people do to accomplish certain things or goals. To take a trivial example, it could describe what is necessary to get high marks in the coursework you have chosen, e.g. the understanding that this task may consist of several refinements until you hand in the coursework.