Elicitation II

1. Elicitation II

2. Non-Functional Requirements Knowledge Base • Taxonomies proposed in the literature • Guide the Elicitation Process Elicitation NFRs KB

3. Software Quality Characteristics Tree [Boehm 76] Device-independence Portability Self-containedness Accuracy Reliability Completeness As-is utility Efficiency Robustness/integrity Consistency Human engineering Accountability General utility Device efficiency Testability Acessibility maintenability Understandability Communicativiness Modifiability Self-descriptiveness Structuredness Conciseness Legibility Augmentability

4. Non-Functional Requirements Process Requirements External Requirements Product Requirements Usability Requirements Efficiency Requirements Reliability Requirements Portability Requirements Legislative Requirements Cost Requirements Interoperability Requirements Delivery Requirements Implementation Requirements Standards Requirements Space Requirements Performance Requirements Types of Non-Functional Requirements [Sommerville 92]

5. + • Knowledge Reuse • Antecipate implementation aspects • Conflict Identification • - • Cost for building the KB • Gives the wrong impression it is complete NFR KB

6. Active Participation of Actors • Actors and Developers working together on determining requirements for the system • + • Join clients and users • Validation • - • Training • Appears to be efficient

7. Reverse Engineering • From existing code figure out requirements for the system • + • Information availability (Code) • Reuse • - • Information discontinuity • Many old requirements may not be needed any more • Many new requirements may not be present in current version of the software • Very detailed Information

8. Reusing • Define what will be reused • Define where to search for the object to reuse • Is the object stored using reusing principles ? • Shall have efficient ways to recover the reusing component • Developers shall be motivated to produce reusable objects and components • Selection of tools and COTS

9. Reuse • We may Reuse either code or existing Requirements/Models when they exist • + • productivity • quality • - • Level of abstraction (requirements) • Possibility of a real reuse • May not integrate quite well

10. Tools Selection • Requirements for Selecting • Functional Requirements (FRs) • Non-Functional Requirements (NFRs) • Supplier • Availability • Supported Methodologies • Training • Integration • Cost, cost, cost

11. Selecting Tools • Build a Matrix • Identify functions (FRs) • Identify Characteristics (NFR) • Process for eliciting matrix elements • Suppliers Documentation • Eliciting with clients (interviews etc)

12. Tool Selection Evaluation • Evaluate Functions • Grading • 0,1,2 (ternary scale) • Other scales - Ex: bad enough, good • To each function evaluate usability, integration, understandability documentation and reliability

13. Evaluation • Manual verification or use a tool • Evaluate to each package • portability • evolution • platform • Compliance with standards • Number of allowed users

14. grading • Final marks ( 1 .. * participants) • Compare results • Function Total • Property Total

15. COTS Output Input Black Box

16. COTS • Ready to use Software • “off the shelf” • Find it at stores • Instead of adapting the software to the company, the company has to adapt itself to the software

17. COTS • + • Cost • Fast • Technical Support (not necessarily) • User Groups • Training (Be careful on costs here) • - • Inflexible (requirements can rarely change) • May not solve all your problems • Does not provide space to process improvement

18. COTS Selection Process • Study the Market (What is available) • Select • Adapt • Integrate • Update

19. Requirements for Selection • Supplier’s Reputation and maturity • Guaranties given by the suppliers for support • Supplier’s stability • Possibility of changing the product in future versions

20. Factors Influencing Selection • Time to get to a final selection of products • Number of possible COTS • Availability of a User Group • Resources available for evaluation and selection activities • Has this product been used before ?

21. Challenges • How to estimate quality of support on a long term basis? • How to evaluate costs associated with the acquisition of certain COTS? • What about Maintenance?

22. Challenges • How to verify if the product complies with other standards? • How to describe and qualify qualit aspects (NFRs) in COTS?

23. Which technique to use? • Depends on the situation • Analyse the context • Respect limitations

24. Example • Health Care Domain • Questionnaires • Less than 10% returned • Vast majority just partially filled • Nurses and Physicians usually work in a 12 hour shift • Enterviews • Lack of trustworthiness • Formality • Open-ended/semi-structured may get better response • List of topics

25. Example • Health Care domain • Protocol Analysis • Almost impossible (privacy, inconvineit) • Imagine a Heart Attack !!!! • JAD • Usually to solve conflicts • Etical questions a concern • competitivity

26. Exemple • Health Care domain • Vídeo and Audio (transcriptions) • Legal questions make it hard to be used • Use Case and Scenarios (Future Classes - Modelling) • Well accepted • Scenarios are more wellcomed • Observation • Confirm results

27. Comunicating • Presentation • Understanding • Languages • Level of Abstraction • Feedback

28. Sales Distribution Product D Product B Product A Product C Presentation The way the information is shown. Different ways may help or prejudice one to understand the information Sales Distribution

29. Language The language is the reflection of a society’s culture. To understand something that is important to a certain society we have to understand its language. We must understand the language before we elicit the needs Examples Zip a file, Review Patient’s Report, ILS

30. Level of abstraction The communication can be noisy if the participants are talking using different levels of abstraction. Typical conflict when you place generalist and specialists together Example We should conquer new Markets (VP Sales) X We should distribute Salesmen (Sales Manager)

31. Feedback We should demand the receiver of an information to return the information back to the source until the source answers positvly. Summarize, rephrase, confirm a ? a

32. Communication • Precision Models • Reference Standards • Results ( What are the goals of this meeting?) • Retrocession ( Summarize what has been discussed up to now) • If (If you were the user, how should you do?) • Procedures • Evidence (How the result was obtained?) • Relevance (Thanks, the question seems to be interesting, but how is it related to the problem at hand?) • Pointers • Could you be more specific? • To what are you referring?

33. Precision Models(neuro linguistic programming) What is the order for the following sequence? 8,5,4,9,1,7,6,10,3,2

34. Precision Models(neuro linguistic programming) Context Dependent Almost empty Almost full Something to drink Can you give me this information untill Friday? What should we do to have this information before Saturday?

35. Precision Models Determination / Establishing the Context: • If: • The policy doesn’t allow…, but suppose… What would we do? (On the edge) • If in six months …. (time) • Could you act as a user? What the user would answer? (Actor)

36. Precision Models • Determination / Establishing the Context: • If: • Imagine the main user/stakeholder enters your room and ask for one more alternative. What would you say? (environment) • Suppose you have the information how would you use it? (Information)

37. Heuristics for communication • A good figure is worth 1000 words • Communication should flow in both directions • Avoid Noise • Avoid metaphors with your area of communication • Identify different viewpoints • Learn with humility

38. General Heuristics • Ask what? How ? Why? • Who should we talk to? Why? • What to study? Why? • Where to begin? • How to represent? To Whom? How? • Always Review !

39. Social Aspects • Ecology of the system: • Metaphor of the phisical industrial plant – Before choosing a place and a operational procedure we must evaluate the disturbances this industrial plant could bring to the envirnment once it is operational

40. Social Aspects • London Ambulance Service: System developed almost without consulting the Users • The proposed system would significantly impact the way the staff carried out their tasks, however regarding the several ambulance teams there was only a few questions about the “new proposed way of doing things”

41. Social Perspective • London Ambulance Service : • “The general attitude towards the information system was incredibly positive. Everyone recognized that computers in this area is primordial to enhance efficience. However, there is a feeling, also unanime, that the actual system and the way it was introduced was the future way. There is no TRUST in the system which resulted in an expectitave of failure instead of success from the staff viewpoint”

42. Social Aspects • London Ambulance Service : Use the sytem to change job practices • “The new system would eliminate these practices, the management used to think” • “The result is that the staff saw the changes/ New procedures as a “Straitjacket” in which they were trying to find some flexibility

43. Social Aspects • London Ambulance Service: Conclusion from the investigation: The upper management was naive to believe a system could, by its own power, bring changes to human traditional practices. Experiments in many different environments prove that information systems are not capable to influence changes this way. They can only help on the process and any attempt to force these changes is likely to fail.

44. Social Aspects • Broader View: • sociology • Groups with the same concerns • Groups of power • Policies and Politics

45. Social Aspects • Ortogonal to everything we saw for elicitation • Focus is on the social aspects not technology • Demands more resources • Contrary to the common thinking from commertial packages such as ERP • Important because is long term focused

46. Requirements Sentences • The system must + [verb + object | verbal phrase ] + [agent complement| null] + [conditions | null] • Three classes of sentences: (Input, Output, State change} • Verb is a simple verb which express the requirements functionality • Verbal phrase is a phrase which expresses the requirements functionality • Agent Complement is the identification for an agent related with the requirement. Sometimes this complement may be described by the direct object. An agent can be a person, an organization, a group or a device external to the software • Sentences can be : Functional, non-functional and reverse

47. Requirements Sentences • 1 - The system must produce a receipt for the client • 2 - The system must produce a receipt in less than 2 seconds • 3 - The system must register the client if the client has a photo id • 4 - The system must change an available tape into a rented tape when a client rent a tape • 5 - The system must register library clerks • 6 - The system must not allow a book to be reserved for more than 2 weeks