1. Requirements Elicitation

3. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that the clients can understand – Focus on describing the purpose of the system – Errors in the elicitation phase are expensive to fix Requirements Analysis: analysis model that the developers can understand 3

4. Requirements Elicitation Developers observe users in their environment and interview them They use Scenarios and Use cases, easy to understand by clients They also use prototypes for validation They produce Requirements Specification, it will be used as a contract 4

5. Part of requirements System functionality Interaction between users and system Environmental conditions Errors the system can detect and handle 5

6. Functional requirements Describes the interaction between the system and users The user could be anyone or anything that interacts with our future system Remember, nothing is left over, every aspect should be well defined. We are defining what the system should do, not how the system will do it. Both, the actor and system behaviour should be well defined 6

7. Non-functional requirements Describes the system overall attributes – Usability – Reliability – Performance – Supportability and maintainability – Implementation requirements – Interface requirements-legacy system – Operational requirements-administration – Legal requirements-licensing 7

8. Requirements Elicitation Activities 1.Identify Actors 2.Identify Scenarios 3.Identify Use cases 4.Identify Relationships between actors and use cases 5.Identify initial analysis objects (conceptual class diagram) 6.Identify non-functional requirements 8

9. Requirements Elicitation activities Identifying Actors They are external to the system Anyone or anything that interacts with our system We can ask the following questions: – Which user groups are supported by the system to perform their work? – Which user groups execute system main functions? – Which user groups perform secondary functions? – With what external hardware or software will the system interact? 9

10. Identify Scenarios and Use Cases High level piece of functionality that the system will provide Scenarios are instances of use cases. Real events, real actors. We can ask the following questions: – What are the tasks that the actor wants the system to perform? – What information does the actor access? Who creates that data? Can it be modified and removed? by whom? – Which external changes does the actor need to inform the system? – Which events does the system need to inform the actor? 10

11. FRIEND System Case Study

12. Refine Use cases The focus of this activity is on completeness and correctness – Elements manipulated by the system are detailed – Low-level sequence of interaction are specified – Alternative scenarios Many use case are rewritten many times Others are refined Others are dropped U may use GUI mokups 12

13. Identify relationships among actors and use cases Actors and use cases – Initiate – Participate Between Use case: – Include – Extend 13

14. How do we represent the include relationship? In the base use case – If the included use case can be invoked at any point of the flow of event, we indicate the inclusion in the quality requirements – If it is invoked during an event, we specify which event in the flow of event How do we represent the extend relationship? – In the extending use case’s entry requirement 14

15. Use case writing guidelines Use cases should be named with verb phrases Actors should be named with noun phrases The boundary of the system should be clear The casual relationships between successive steps should be clear A use case should be a complete user transaction Exceptions should be described separately Do not get into technical stuff, such as design Should not exceed 2-3 pages. 15

16. Identify initial analysis objects Use cases are main source Look for noun and noun phrases to identify entities Look for verbs and verb phrases to identify relationships between entities

17. Use Case Example 17 Use Case Name: Check Campaign Budget Brief Intro: Checks whether the budget for a campaign is likely to be exceeded by the total cost of all the adverts that make it up. Actors: Campaign Manager Main Flow: 1. The campaign manager enters the client name. [Exception: Known campaign name] 2. The system lists all campaigns for that client (include Use Case: Find Campaign) 3. The campaign manager selects the relevant campaign 4. The system calculates the total cost of all adverts in the campaign, deducts this from the campaign budget and displays the balance. (Extension Points: Print Campaign Summary, Print Campaign Invoice) Alternative Flow: Known campaign name -The campaign manager knows the campaign name and enters it directly. The use case continues from step 4.

18. Use Case ( with nouns identified) 18 Use Case Name: Check Campaign Budget Summary: Checks whether the budget for a campaign is likely to be exceeded by the total cost of all the adverts that make it up. Actors: Campaign Manager Description: 1. The campaign manager enters the client name. 2. The system lists all campaigns for that client (Include Use Case: Find Campaign) 3. The campaign manager selects the relevant campaign 4. The system calculates the total cost of all adverts in the campaign, deducts this from the campaign budget and displays the balance. Alternative Flow: Known campaign name -The campaign manager knows the campaign name and enters it directly. The use case continues from step 4. Underline nouns and noun-phrases to identify possible objects

19. Candidate Classes (1) 19 Categorise on basis of confidence, but don’t lose objects

20. Candidate Classes (2) 20

21. Candidate Classes (3) 21 Candidates may move from one list to another as knowledge gained

22. Candidate Classes (4) 22 Candidate classes and attributes begin the Class Diagram

23. Candidate Classes (5) 23 What about ‘total advert cost’? total advert cost Probably a derived attribute of Campaign

24. Identify non-functional requirements - Usability What is the level of experience for the user? What user interface standards are familiar to the user? What documentation should be provided to the user? 24

25. Reliability: robustness, safety and security How reliable, robust, and available the system should be? How much data the system can loose? How much time the system can remain offline? How the system should handle exceptions? Are there any safety or security requirements for the system?

26. Performance How responsive should the system be? Are any user tasks time critical? How many concurrent users there will be? How large is the data store? What is the worst latency acceptable?

27. Supportability: maintainability and portability What are the foreseen extensions to the system? Who maintains the system ? Are there plans to port the system to different software or hardware environments?

28. Implementation Are there constraints on hardware platform? Are there constraints imposed by maintenance team?

29. Interface Should the system interact with existing systems? How are the data imported/exported to the system?

30. Packaging How installs the system? How it will be installed?

31. Legal Should the system be licensed? Are any liability issues associated with system failure? Should other used components/software be licensed?