Elicitation of Non-Functional Requirements for Software Quality Characteristics Tree

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 • + • Join clients and users • Validation • - • Training • Appears to be efficient

7. Reverse Engineering • + • Information availability (Code) • Reuse • - • Information discontinuity • 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. Tools Selection • Requirements for Selecting • Functional Requirements (FRs) • Non-Functional Requirements (NFRs) • Supplier • Availability • Supported Methodologies • Training • Integration • Cost, cost, cost

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

11. 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

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

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

14. COTS Output Input Black Box

15. 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

16. COTS • + • Cost • Fast • Technical Support (not necessarily) • User Groups • Training (Be careful on costs here)

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

18. 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

19. 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 ?

20. 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?

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

22. Reuse • + • productivity • quality • - • Level of abstraction (requirements) • Possibility of a real reuse

23. Which technique to use? • Depends on the situation • Análise 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 turtworthiness • Formality • Open-ended 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 • 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 ok, 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) Alphabethic 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 Noisy • 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 withou consulting the Users • The proposd 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, the 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 • Broder View: • sociology • Gorups with the same concerns • grupos 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