1. GATHERING DATA Supplementary Note

2. What are requirements? A requirement is a statement about an intended product that specifies what it should do or how it should perform. One of the aims of the requirements activity is to make the requirements as specific, unambiguous, and clear as possible. For example, a requirement for a website might be that the time to download any complete page is less than 5 seconds.

3. Different kinds of requirements In software engineering, two different kinds of requirements have traditionally been identified: functional requirements, which say what the system should do, and non-functional requirements, which say what constraints there are on the system and its development. For example, a functional requirement for a word processor may be that it should support a variety of formatting styles. A non-functional requirement for a word processor might be that it must be able to run on a variety of platforms such as PCs, Macs and Unix machines.

4. Different kinds of requirements Functional requirements capture what the product should do. Data requirements capture the type, volatility, size/amount, persistence, accuracy, and value of the amounts of the required data. Environmental requirements or context of use refer to the circumstances in which the interactive product will be expected to operate. Four aspects of the environment must be considered when establishing requirements. Physical environment. Social environment. Organizational environment. Technical environment.

5. Different kinds of requirements User requirements capture the characteristics of the intended user group. Usability requirements capture the usability goals and associated measures for a particular product.

6. Scenario 1 Consider a system being designed for use in a university's self-service cafeteria that allows users to pay for their food using a credit system. Suggest one key functional, data, environmental, user and usability requirement for each this scenario.

7. Scenario 1 Answer Functional: The system will calculate the total cost of purchases. Data: The system must have access to the price of products in the cafeteria. Environmental: Cafeteria users will be carrying a tray and will most likely be in a reasonable rush. The physical environment will be noisy and busy, and users may be talking with friends and colleagues while using the system. User: The majority of users are likely to be under 25 and comfortable dealing with technology. Usability: The system needs to be simple so that new users can use the system immediately, and memorable for more frequent users. Users won't want to wait around for the system to finish processing, so it needs to be efficient and to be able to deal easily with user errors.

8. Other Scenario to try out Consider a system to control the functioning of a nuclear power plant. Consider a system to support distributed design teams, e.g., for car design. Suggest one key functional, data, environmental, user and usability requirement for each this scenarios:

9. DATA GATHERING The purpose of data gathering is to collect sufficient, relevant, and appropriate data so that a set of stable requirements can be produced. There is essentially a small number of basic techniques for data gathering, but they are flexible and can be combined and extended in many ways; These techniques are questionnaires, interviews, focus groups and workshops, naturalistic observation, and studying documentation.

10. DATA GATHERING TECHNIQUES Questionnaires: They are a series of questions designed to elicit specific information from user. Interviews: Interviews involve asking someone a set of questions. Often interviews are face-to-face, but they don't have to be. Focus groups and workshops: In the requirements activity, focus groups and workshops are good at gaining a consensus view and/or highlighting areas of conflict and disagreement. Naturalistic observation: Observation involves spending some time with the stakeholders as they go about their day-to-day tasks, observing work as it happens, in its natural setting. Studying documentation. Procedures and rules are often written down in manuals and these are a good source of data about the steps involved in an activity and any regulations governing a task.

11. Table 1: Overview of data- gathering techniques used in the requirements activity

12. Scenario 1: Data gathering techniques For the situations below, consider what kinds of data gathering would be appropriate and how you might use the different techniques introduced above. Assume that you are at the beginning of the development and that you have sufficient time and resources to use any of the techniques. You are developing a new software system to support a small accountant's office. There is a system running already with which the users are reasonably happy, but it is outdated and needs upgrading.

13. Scenario 1: Answer As this is a small office, there are likely to be few stakeholders. Some period of observation is always important to understand the context of the new and the old system. Interviewing the staff rather than giving them questionnaires is likely to be appropriate because there aren't very many of them, and this will yield richer data and give the developers a chance to meet the users. Accountancy is regulated by a variety of laws and it would also pay to look at documentation to understand some of the constraints from this direction. So we would suggest a series of interviews with the main users to understand the positive and negative features of the existing system, a short observation session to understand the context of the system, and a study of documentation surrounding the regulations.

14. Other Scenario to try out You are looking to develop an innovative device for diabetes sufferers to help them record and monitor their blood sugar levels. There are some products already on the market, but they tend to be large and unwieldy. Many diabetes sufferers rely on manual recording and monitoring methods involving a ritual with a needle, some chemicals, and a written scale. You are developing a website for a young person's fashion e- commerce site.

15. Task Description Descriptions of business tasks have been used within software development for many years. There are different flavors of task descriptions, and we shall introduce three of them here: scenarios, use cases, and essential use cases. Each of these may be used to describe either existing tasks or envisioned tasks with a new device. They are not mutually exclusive and are often used in combination to capture different perspectives or to document different stages during the development lifecycle.

16. Task Description Scenario: A scenario is an "informal narrative description". It describes human activities or tasks in a story that allows exploration and discussion of contexts, needs, and requirements. It does not explicitly describe the use of software or other technological support to achieve a task. Use cases: Use cases focus on user goals, but the emphasis here is on a user-system interaction rather than the user's task itself. Although their focus is specifically on the interaction between the user (called an "actor'') and a software system, the stress is still very much on the user's perspective, not the system's. A use case is associated with an actor, and it is the actor's goal in using the system that the use case wants to capture.

17. Use Case contd… To develop a use case, first identify the actors, i.e., the people or other systems that will be interacting with the system under development. Then examine these actors and identify their goal or goals in using the system. Each of these will be a use case. Figure 2: Use case diagram for the library catalog service

18. Practice example on Use case Consider the example of the library catalog service again. One use case is "Locate book,“. Write out the use case for "Locate book" including the normal and some alternative courses. You may assume that the normal course is for users to go to the catalog to find the location, and that the most common path to find this is through a search by author.

19. Solution The use case for "Locate book" might be something like this: 1.The system prompts for user name and password. 2.The user enters his or her user name and password into the catalog system. 3.The system verifies the user's password. 4.The system displays a menu of choices. 5.The user chooses the search option. Alternative courses: 4. If user password is not valid 4.1 The system displays error message. 4.2 The system returns to step 1.