1 / 45

Elicitation of Non-Functional Requirements for Software Quality Characteristics Tree

This article proposes taxonomies for eliciting non-functional requirements (NFRs) and provides a guide for the elicitation process, focusing on software quality characteristics. The knowledge base and techniques for knowledge reuse are discussed, as well as the challenges and factors influencing the selection of tools and commercial off-the-shelf (COTS) software products.

Download Presentation

Elicitation of Non-Functional Requirements for Software Quality Characteristics Tree

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related