1. Requirements specification Why is this the first major stage of software development? –Need to understand what customer wants first Goal of requirements gathering is to understand the customer’s problem –Though customer may not fully understand it! Requirements specification should: Describe explicitly how we will know when the job is done and the customer is satisfied. Why is this a non-trivial task?

2. "Editor with undo" Editor with undoEditor with undo A very simple, initial requirements spec –Why might a small and concise initial spec be a good idea? –Fosters initial buy-in and agreement by everyone on the team –Real-world specs are usually much longer, though Real-world specsReal-world specs What’s the purpose of a purpose statement? Why is scope important? Why definitions? Other possible general requirements: –Business context: organization sponsoring the development of the product –User characteristics: profile of user community, expected expertise with system & domain –User objectives: “wish list” from user’s perspective, in line with business objectives –Interface requirements: GUI, API, communication interfaces, software interfaces

3. Use cases A "use case" is a set of cases or scenarios for using a system, tied together by a common user goal –Essentially descriptive answers to questions that start with “What does the system do if …” –E.g., “What does the auto-teller do if a customer has just deposited a check within 24 hours and there’s not enough in the account without the check to provide the desired withdrawal?” –Use case describes what the auto-teller does in that situation Why are use cases good for brainstorming requirements?

4. Example use case (from Fowler and Scott, UML Distilled) Use Case: Buy a Product (Have we described this behavior is a user’s language?) Actors: Customer, System (Why might it a be a good idea to define actors in a case?) 1. Customer browsers through catalog and selects items to buy 2. Customer goes to check out 3. Customer fills in shipping information (address; next-day or 3-day delivery) 4. System presents full pricing information, including shipping 5. Customer fills in credit card information 6. System authorizes purchase 7. System confirms sale immediately 8. System sends confirming email to customer (Did we get the main scenario right?) Alternative: Authorization Failure (When might this happen? I.e., at what step?) 6a.At step 6, system fails to authorize credit purchase Allow customer to re-enter credit card information and re-try Alternative: Regular customer (At what step might this happen?) 3a. System displays current shipping information, pricing information, and last four digits of credit card information 3b. Customer may accept or override these defaults Return to primary scenario at step 6

5. Heuristics for writing use case text Avoid implementation specific language in use cases, such as IF-THEN-ELSE or GUI elements or even specific people or departments –Which is better: “The clerk pushes the OK button.” or: “The clerk signifies the transaction is done.” –The latter defers a UI consideration until design. Write use cases with the user’s vocabulary, the way a users would describe performing the task Use cases never initiate actions; actors do. –Actors can be people, computer systems or any external entity that initiate an action. A use case interaction produces something of value to an actor. Create use cases and requirements incrementally and iteratively –Start with an outline or high-level description –Work from a problem statement and statement of work (scope) –Then broaden and deepen, then narrow and prune

6. Use Case exercise Write a use case for withdrawing cash from an ATM machine –Assume customer has already logged into the ATM with PIN and sees menu Use Case: Withdraw cash Actors: Customer, ATM 1. Customer selects Withdraw from menu 2. ATM lists customer’s accounts to choose from 3. Customer chooses an account 4. ATM ask customer for an amount to withdraw 5. Customer specifies an amount 6. ATM subtracts this amount from the specified account 7. ATM tells machine to disburse requested amount of cash Alternative: Unit not $20s 5a.At step 5, customer specifies an amount not divisible by 20.00 Allow customer to re-enter amount and repeat step 5 Alternative: Insufficient funds 6a.At step 6, amount requested is greater than amount in specified account Inform customer and go to step 5 Now, how would you model ATM deposits?

7. Advantages of use cases What do you think? Systematic and intuitive way to capture functional requirements? Facilitates communication between user and analyst? –That’s why it’s important to write use cases in the user’s languages Drives the whole development process? –Analysis starts with use cases –Design and implementation realizes them –How can use cases set up test plans? –How can use cases help with writing a user manual? How can use cases help with user interface prototype? Can implementation details or language be added to use cases later in the life cycle?

8. So, how will you do requirements analysis for your multimedia e-learning project?