1. Lecture 4/2/16

2. Learning Objective Establishing requirements Define requirements Requirements discovery vs requirements gathering Classifying Requirements Techniques for eliciting requirements Sources of Requirements Managing Requirements

3. What are requirements? Features of a product or service that enable its users to achieve specific objectives Example: ATM must allow customers to withdraw cash Online registration system must allow the student to register for a course Requirements help us to define objectives and constraints of a system Example : A customer must be allowed to change the pin on his/her ATM card (objective) The password must be between 6 and 15 characters in length (constraint)

4. Requirements Discovery Phase that takes place at the start if the project Supports the definition of the scope of the systems Aim is to elicit objectives from a broad group of stakeholders Typically more chaotic than requirements gathering (which is an on-going and ordered process as we know what we are searching for)

5. Classifying Requirements Functional requirements specify the behaviour of the system and the constraints on that behaviour Example Functional Requirements - Deposit a Check using an ATM machine Customer inserts bank card Systems asks for password Customer enters password If password is correct the system displays a menu of options from which a customer can pick one. (If the password is incorrect the system requests the password again) …….

6. Continued… Non-functional requirements specify non-behavioural properties of the system and the constraints on those properties Usability Reliability Performance Maintainability Security

7. Data Gathering Techniques Questionnaires: Series of questions designed to elicit specific information from us. The questions may require different kinds of answers: some require a simple Yes/No, others ask us to choose from a set of pre-supplied answers. Interviews: Interviews involve asking someone a set of questions. Often interviews are face-to- face, but they don ’ t have to be (more on next page).

8. Data Gathering Techniques (continued) Interviews: Forum for talking to people Structured, unstructured or semi-structured Props, e.g. sample scenarios of use, prototypes, can be used in interviews Good for exploring issues But are time consuming and may be infeasible to visit everyone

9. Data-gathering techniques Focus groups and workshops: Interviews tend to be one on one, and elicit only one person ’ s perspective. It can be very revealing to get a group of stakeholders together to discuss issues and requirements. Naturalistic Observation: It can be very difficult for humans to explain what they do or to even describe accurately how they achieve a task. (more on next page)

10. Data-gathering Techniques (continued) Naturalistic observation: Spend time with stakeholders in their day-to-day tasks, observing work as it happens Gain insights into stakeholders ’ tasks Good for understanding the nature and context of the tasks But, it requires time and commitment from a member of the design team, and it can result in a huge amount of data Ethnography is one form : entire class devoted to this.

11. Data-gathering Studying documentation: Procedures and rules are often written down in a manual and these are a good source of data about the steps involved in an activity and any regulations governing a task. Use All of the above In Combination : Constraints of Time and Money

12. Sources of Authority Sponsors Domain Experts Stakeholders Users

13. Data Gathering Guidelines Focus on identifying the stakeholders Involve all the stakeholder groups Need more than on person from stakeholder group(s) Use a combination of data gathering techniques For example: use observation to understand the context, interviews to target specific user groups, questionnaires to reach a wider population, and focus groups to build a consensus view

14. Data Gathering Guidelines Cont. Support the data-gathering sessions with suitable props, such as prototypes if available. Run a pilot session if possible to ensure that your data-gathering session is likely to go as planned In an ideal world, you would understand what you are looking for and what kinds of analysis you want to do, and design the data-capture exercise to collect the data you want. However, data gathering is expensive and often a tightly constrained resource.

15. Managing Requirements To manage requirements effectively, certain tasks must be performed conscientiously: Document and update requirements Document sources Separate requirements into distinct units Uniquely identify each requirement Verify requirements and document these Prioritise requirements

16. Data interpretation and analysis What: structure and record description of requirement When: Start soon after data gathering session

17. Data interpretation and analysis Main Requirement analysis models in object-oriented systems Use cases diagrams: consists of actors and user cases, discussed later Class diagrams More … How to develop those diagrams? UML tools( useful in practice)

18. Unified Approach The unified approach (UA) is a conceptual model, based on methodologies by Booch, Rumbaugh, and Jacobson Tries to combine best practices, processes, and guidelines along with the Object Management Group’s unified modeling language (UML)

19. UML UA utilizes the Unified Modeling Language which is a set of notations and conventions used to describe and model an application UML doesn’t specify a methodology or what steps to follow to develop an application, that is the task of UA

20. Processes of the Unified Approach (UA) Use-case driven development Object-oriented analysis Object-oriented design Incremental development and prototyping Continuous testing

21. We begin by working with the users to produce a conceptual model Then we expand that into a logical model by adding all the features that were not apparent to the users Finally we make all our design decisions and document them on the physical model Conceptual, Logical & Physical Models

22. It is essential that you are user-driven in your modeling Use OO techniques to understand their business People skills and listening skills Deliverables: the documents and other products generated at each stage Models as Communication Tools

23. UML Unified modelling language is a language for specifying, constructing, visualizing and documenting the artefacts of software intensive systems Focus on a standard modelling language not a standard process Promotes a development process that is use-case driven, architecture centric, iterative and incremental

24. UML UML provides several types of diagrams to represent applications under development. class diagram sequence diagram statechart diagram component diagram deployment diagram. activity diagram

25. Activity Example – Car Insurance Prospective customers fill out an insurance application, which provides information about the customer and his or her vehicles. This information is sent to an agent, who sends it to various insurance companies to get quotes for insurance. When the responses return, the agent then determines the best policy for the type and level of coverage desired and gives the customer a copy of the insurance policy proposal and quote.

26. Complete Application Process Application Create Quote Determine Best Policy Generate Policy Proposal and Quote Determine Best Coverage