1. Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

2. Basic objectives of the chapter 2 Define requirement and related concepts? Understand requirement identification and collection techniques using traditional method essential use case modeling CRC modeling essential user interfaces modeling Supplementary specifications Being familiar with validating, organizing and documenting requirements

3. What is a Requirement ? 9/13/2015 3 It is a statement describing either 1) an aspect of what the proposed system must do, or 2) a constraint on the system’s development. In either case it must contribute in some way towards adequately solving the customer’s problem; the set of requirements as a whole represents a negotiated agreement among the stakeholders. A collection of requirements is a requirements document.

4. Types of Requirements 9/13/2015 4 Functional requirements Describe what the system should do Non-functional requirements Quality requirements Constraints on the design to meet specified levels of quality such as availability, performance, usability, etc Pseudo requirements Platform requirements Constraints on the environment and technology of the system Process requirements Constraints on the project plan and development methods

5. Functional Requirements 9/13/2015 5 What inputs the system should accept What outputs the system should produce What data the system should store that other systems might use What computations the system should perform The timing and synchronization of the above

6. Quality Requirements All must be verifiable Examples: Constraints on ◦ Response time ◦ Throughput ◦ Resource usage ◦ Reliability ◦ Availability ◦ Recovery from failure ◦ Allowances for maintainability and enhancement ◦ Allowances for reusability 9/13/2015 6

7. Cont.. 9/13/2015 7 Requirement elicitation Is about a communication b/n developers and user in defining a new system Failure to do so will lead to “unwanted” system Focus on describing the purpose of the system Results in system specification

8. Cont.. 9/13/2015 8 System specification Vs Analysis model Represent same information Difference only on the language and notation they use Both describe more of external aspect of the system visible to users (users' view) They occur concurrently and iteratively

9. How to conduct? 9/13/2015 9 Through techniques like Traditional methods like interview Essential use case CRC model Identifying initial analysis objects Essential user interface Identification of non-functional requirement All the above techniques will help us in making domain analysis

10. Domain Analysis 9/13/2015 10 The process by which a software engineer learns about the domain to better understand the problem: The domain is the general field of business or technology in which the clients will use the software, e.g. Finance, personnel, marketing, etc A domain expert is a person who has a deep knowledge of the domain e.g. accountant for finance system Benefits of performing domain analysis: Faster development Better system Anticipation of extensions

11. Defining the Problem and the Scope 9/13/2015 11 A problem can be expressed as: A difficulty the users or customers are facing, Or as an opportunity that will result in some benefit such as improved productivity or sales. The solution to the problem normally will entail developing software/system A good problem statement is short and concise

12. Defining the Scope 9/13/2015 12 Narrow the scope by defining a more precise problem List all the things you might imagine the system doing Exclude some of these things if too broad Determine high-level goals if too narrow Example: A university registration system

13. Cont… 9/13/2015 13

14. Example: Library System 9/13/2015 14 Idea: A Library Management System should be designed. Information on books, CDs, DVDs, Journals, etc. can be stored and retrieved Possible Requirements Searching by Title, Author, and/or ISDN should be possible User Interface should be web-based (accessible via WWW Browser) At least 20 transactions per seconds should be possible All services should be available within 10 minutes Users have no access to personal data of other users

15. Member of Elicitation team? Identify stakeholders (any one who could be affected by the implementation of the system)- customers, end-users. Choose best Subject matter expert (SME) (who knows the business, think logically, communicate well, willing to invest time on the software development) Choose good facilitator or scriber (with good communication skill) 9/13/2015 15

16. Remarks on the process 9/13/2015 16 Result in the specification of the system that the client and user can understand (natural language) It should be validated for correctness (according to the user) completeness (all requirements) Consistency (No contradiction) Unambiguousness (clear) realistic (that can be implemented)

17. Reviewing Requirements 9/13/2015 17 Each individual requirement should Have benefits that outweigh the costs of development Be important for the solution of the current problem Be expressed using a clear and consistent notation Be unambiguous Be logically consistent Lead to a system of sufficient quality Be realistic with available resources Be verifiable Be uniquely identifiable Does not over-constrain the design of the system

18. Requirements documents... 9/13/2015 18 The document should be: sufficiently complete well organized clear agreed to by all the stakeholders Traceability:

19. Difficulties and Risks in Domain and Requirements Analysis guides 9/13/2015 19 Lack of understanding of the domain or the real problem Do domain analysis and prototyping Requirements change rapidly Perform incremental development, build flexibility into the design, do regular reviews Attempting to do too much Document the problem boundaries at an early stage, carefully estimate the time It may be hard to reconcile conflicting sets of requirements Brainstorming, JAD sessions, competing prototypes It is hard to state requirements precisely Break requirements down into simple sentences and review them carefully, look for potential ambiguity, make early prototypes

20. How to Elicit (collect) Requirement) 9/13/2015 20 Research/Document Analysis The document Analysis is a method by which the system analyst go through each documents used and relevant to all the processes covered by the system. The documents will give information about the data to be captured and the presentation of the data to the users of the system.

21. Cont… 9/13/2015 21 Direct Observation Direct observation is a method used to verify the already gathered information and to add on to requirement. The method will help to see how users behave and do things in their day to day activity. Questionnaires and Surveys The Survey Method is an electronic or paper based method of soliciting needs or requirements from stakeholders. The survey method is a list of questions, directed at identifying stakeholder needs or requirements.

22. Cont… 9/13/2015 22 Interviews An interview is a conversation with stakeholders to elicit or validate needs and requirements. An interview may include one or more stakeholders. The interview may also involve a question and answer session used to discover other potential stakeholders and any discrepancies between needs; the high-level requirements derived from those needs; and the resulting detailed requirements. Interviews facilitate obtaining approval from stakeholders on their needs, requirements, and any changes to them.

23. Gathering and Analysing Requirements 9/13/2015 23 On Observation Read documents and discuss requirements with users Shadowing important potential users as they do their work ask the user to explain everything he or she is doing Session videotaping On Interviewing Conduct a series of interviews Ask about specific details Ask about the stakeholder’s vision for the future Ask if they have alternative ideas Ask for other sources of information Ask them to draw diagrams

24. Cont… 9/13/2015 24 Joint Application Design (JAD): The Joint Application Development (JAD) technique is an extended, facilitated workshop. It involves collaboration between users, managers and systems analysts and system designers to identify needs or requirements in a concentrated and focused group discussion.

25. Cont... On Brainstorming Appoint an experienced moderator Arrange the attendees around a table Decide on a ‘trigger question’ Ask each participant to write an answer and pass the paper to its neighbour Joint Application Development (JAD) is a technique based on intensive brainstorming sessions 9/13/2015 25

26. Elicitation – Essential use case Use Cases are used to capture the intended behaviour of the system under development (requirements of a system) In terms of Use case, actors and relationships (use case diagram) and use case documentation 9/13/2015 26

27. Requirement Elicitation tasks (using use case) Identify actors: Hints Actors are external to the system- human or another system Represent roles Question you should ask Which user group are supported by the syetm to perform their task? Which user groups execute the systems major function? Will the system interact with any external hardware or software? 9/13/2015 27

28. Cont… Identify use cases First identify scenarios or examples of system usage and compile or represent some similar scenarios with one case. Question to be asked What are the tasks that the actor wants the system to perform? 9/13/2015 28

29. Cont… 9/13/2015 29 Identify relationships To reduce complexity and increase understandability Communication(association), include (use), extend, and generalization Questions to be asked Is there any relationship that needs to be factored out among use cases? If yes ‘include’ will solve it Is there any exceptional or optional cases? If yes “extend” will solve it Is there two or more possibilities for accomplishing a case? If yes “generalization” will solve it

30. So… 9/13/2015 30 Now at this stage you have some understanding about the system/software to be developed from functional point of view What is next should be Again collecting requirements from structural point of view

31. System Modeling will continue 9/13/2015 31