1. CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases

2. 2Objectives n This lecture introduces Requirements Determination: Concept of system requirements Techniques to solicit requirements Elaboration of use case diagrams Organization and documentation of system requirements in the form of Use Cases Stakeholders (customers and end users) have goals (also known as needs) and want computer systems to help them meet them. There are several ways to capture these goals and system requirements, the better ones are simple and familiar because they make it easier – especially for users and customers – to contribute to their definition or evaluation.

3. 3 Context of requirements analysis ‘What’

4. 4 What is a requirement? A requirement may range from a high-level abstract statement of a service or of a system constraint to a detailed functional specification

5. 5 Types of requirements n Functional requirements Statements of functionality or services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. n Non-functional requirements Constraints on the services or functions offered by the system such as performance constraints, standards, reliability, availability (e.g. 24x7, short Transaction Time)

6. 6 Techniques to solicit requirements n The task of the requirements determination phase is to determine, analyze and negotiate requirements with the stakeholders n The task involves various techniques of gathering information from the customers. It is concept exploration through structured and unstructured interviews of users, questionnaires, study of documents and forms, etc.

7. 7 Traditional techniques n Traditional methods of requirements elicitation include: Interviews Questionnaires Observation Study of business documents

8. 8Interviews n Primary technique of fact finding and information gathering. n Interviews with domain experts are frequently a simple knowledge transfer, but may be done with different levels of granularity (i.e. management vs. operational staff – different roles). Interviews with customers are more complex. n There are two kinds of interviews, structured and unstructured. A structured interview is prepared in advance, has a clear agenda and many questions are pre-determined. n Consider multiple interviews or meetings (i.e. clarifications once more is understood re: domain). n Listening and documenting are key. n Allow diagram drawing to understand the interviewee’s view of the relationships and dependencies in a problem domain. n Recognize different personality types may contribute information willingly at different levels

9. 9Questionnaires Efficient way of gathering information from many customers. Less productive since we cannot get clarification (unless collecting personal/private information – not always allowed) Types of Questions –Multiple-choice Questions –Rating Questions –Ranking Questions

10. 10 Requirements determination n Requirements analysis includes negotiations between developers and customers. This step is necessary to avoid and eliminate contradicting and overlapping requirements and also to conform to the project budget and timeline n The product of the requirements determination phase is a requirements document. This is mostly a narrative text document, normally in the format of use cases

11. 11 Requirements Document Template n Project Preliminaries Purpose and Scope Business Context Stakeholders Ideas for Solutions Document Overview n System Services Scope of the System Functional Requirements Data Requirements n System Constraints Interface Requirements Performance Requirements Security Requirements Operational Requirements Political and Legal Requirements Other Constraints n Project Matters Open Issues Preliminary Schedule Preliminary Budget n Appendices Glossary Business Documents and Forms References

12. 12 Use Case Diagrams n Use Case specification includes representation of actors, use cases and four kinds of relationships: Association Include Extend Use Case generalization

13. 13 Association relationship n The association relationship establishes the communication path between an actor and a use case

14. 14<<Includes>> The includes relationship allows the factoring out of common behaviour in the included Use Case(s) the included use case is necessary for the completion of the use case (“HAS TO BE COMPLETED”)

15. 15<<Extends>> The extends relationship provides a controlled form of extending the behaviour of a use case by activating another use case at specific extension points the extended use case is optional for the completion of the use case (“COULD BE COMPLETED”)

16. 16<<Generalization>> The generalization relationship provides a form of specialization to a base use case the specialized use case is a replacement for the generalized use case

17. 17 Use case formality Use cases really are requirements and need a basic structure, and also. n a use case describes an actor trying to achieve a goal by using the system