Lecture 04

1. Lecture 04 ITEC 4040 – Requirements Management Prof. DawidKasperowicz http://www.yorku.ca/dkasper

2. Tips about the Interview Process • Asking the stakeholder to use Reply All? • “it makes it difficult for me to be the channel between you and my design team” • Interviews should be scheduled in advance not the day before • Taping should be asked also in advance and not in the same day • Always show respect to your stakeholders ITEC 4040 – Requirements Management

3. Tips about the Interview Process • You don’t need to ask if you can take notes • Allowing the stakeholder to choose the date and time is great but give some options • Sign just your name and not the whole team • Everyone shouldn’t talk • All enter together • Don’t as for: • Volume of data • How do you want data stored • Web mining techniques • Etc. ITEC 4040 – Requirements Management

4. Tips about the Interview Process • Example of meeting request: • “Good morning Mr. Kasperowicz • CEO of Meals on Wheels • We are very excited to be a part of developing your new system. We would like to request 25 minutes of your time to conduct an interview on October 22nd anytime between 7pm and 10pm. We appreciate your time and understand that you have a busy schedule. The purpose of our interview is to establish the requirements for the preparation of your new system.” ITEC 4040 – Requirements Management

5. What are Non-Functional Requirements? • NFRs are also known as quality requirements • Unlike function requirements, non-functional requirements state constraints on the system as well as particular behaviour that the system must have • Non-functional requirements are always together with a functional requirement ITEC 4040 – Requirements Management

6. Non-Functional Requirement Examples? • Adaptability • Architectural integrity • Cost • Configurability • Efficiency • Maintainability • Flexibility • Profitability • Performance • Usability • Understandability • Risk • Resilience • Reusability • Time to market • Reliability • Security • Modularity • Portability • Size • Safety • Testability • Mobility • Standards compliant • Robustness • Complexity • Learnability NFRs are important for the success of the system ITEC 4040 – Requirements Management

7. Why Bother with NFRs? • WASHINGTON (AP, Jan 17th 2002) – Microsoft chairman, Bill Gates, is steering his software empire onto new strategic headings, putting security and privacy ahead of new capabilities[new functionality] in the company’s products • In an email to employees obtained by The Associated Press, Gates refers to the new philosophy as “Trustworthy computing” and says his highest priority is to ensure that computer users continued to venture safety across an increasingly Internet-connected world ITEC 4040 – Requirements Management

8. Why Bother with NFRs? Case Study • The London Ambulance System was deactivated just after its deployment because, among other reasons, many non-functional requirements were neglected during the system development • Reliability – vehicles location • Cost – emphasis on the best price • Usabilty – poor control of information on the screen • Performance – the system did what it was supposed to do but the performance was unacceptable ITEC 4040 – Requirements Management

9. Why Bother with NFRs? • Todays market demands more non-functional aspects to be implemented in information systems than ever before • Studies [Mylopoulos ‘92] [Dardene ‘93] [Chung ‘95] have shown that complex conceptual models must deal with non-functional aspects • Non-functional aspects should be dealt within the process of non-functional requirements definition • Errors due to omission of NFRs or not properly dealing with them are among the most expensive type and most difficult to correct [Mylopoulos ‘92][Ebert ‘97][Cysneiros ‘99] ITEC 4040 – Requirements Management

10. Why Bother with NFRs? • Interdependencies between NFRs must be identified and dealt with • A Clinical Analysis Lab information system has the following functional requirement: • The system must have a file containing all the clients to be used by the marketing division • Together with this functional requirement, we have the following NFR: • The file must be complete enough to allow the marketing division to prospect new clients • But an NFR associated with the clients attendance states: • Patients admission must last less than 4 minutes ITEC 4040 – Requirements Management

11. Overview of a System • Every system is a sub-system that is part of a larger system • Interconnected parts aiming for a common goal • Hierarchy – Tree structure • Divide and Conquer ITEC 4040 – Requirements Management

12. Abstraction • The process of separating ideas from specific instances of those ideas at work • Most used tool for rationalized software • Why? • Allows to ignore inconvenient details • Allows different entities to be treated equally • Simplify many types of analysis • On coding • Abstraction is the process of naming composite objects and deal with them as unique entities • Don’t solve problems • But simplifies them ITEC 4040 – Requirements Management

13. Models • Model – An abstraction of a system that deliberately focuses on some aspects of a system to the exclusion of others • One single model is not enough to represent all the characteristics a system must have • Advantage is that smaller amount of related information can be collected, processed, organized and analyzed, applying various specific techniques pertinent to the aspects under study • Models are useful to organize information and to specify requirements • Providing a means of zooming in, collecting together subsets of data for a particular purpose and zooming out once more to appreciate the whole • Models can guide elicitation • Helps to find new questions ITEC 4040 – Requirements Management

14. Models – Main Objectives • Represent a viewpoint of the environment before the system is implemented • Shows alternative solutions • Shows future needs • Represent parts of the system • Allows to incrementally deal with complexity – from the more abstract level to the detailed level • Provides quantitative information about the scope and complexity of the problem • Allows to communicate with developers and stakeholders ITEC 4040 – Requirements Management

15. Types of Models • Usage models such as “stakeholder scenarios” are used to derive the first statement of stakeholder requirements • Natural Language • Easy to understand and to communicate with stakeholders • Good for elicitation not that much for modelling • Ambiguity is always a problem ITEC 4040 – Requirements Management

16. Types of Models • Functional models used to derive system requirements from the stakeholder requirements • For software, such models include UML class diagrams, message sequence charts and state charts • For architecture aspects, the concerns become focused on various aspects of performance and multiple models may be used to give confidence that the selected architecture can deliver against both functional and non-functional requirements ITEC 4040 – Requirements Management

17. Types of Models • For architecture aspects… • Models used vary from application to application • Examples • Communication systems use message sequence charts • Data-rich applications use entity-relationship diagrams • Railway system use timetable modelling • Aircrafts may use aerodynamic models ITEC 4040 – Requirements Management

18. Formalism Vs. Quality • Two types of Formal modelling • Broad View • Applications of discrete mathematics to software engineering • Involves modeling and analysis with an underlying mathematically-precise notation • Narrow View • Use of formal language • Using a well-defined alphabet to create words, that are guided by a set of rules • In terms of requirements modelling, a notation can be considered formal if it comes with formal rules that define the syntax and semantics, or the rules can be used to analyze expressions to see if they are syntactically well-formed or to provide properties about them • E.g.: Proper way to write requirement sentences seen in lecture 3 ITEC 4040 – Requirements Management

19. Formalism Vs. Quality • Formalism benefits: • Remove ambiguity • Improve precision and reduce inconsistency • Requirement verification • Reason about the requirements • Consistency checking • Exploring consequences • Visualize requirements • Need to formalize eventually anyway as we will need to bridge from the informal world to a formal machine domain ITEC 4040 – Requirements Management

20. Formalism Vs. Quality • Formalism drawbacks: • Tend to be lower level of abstraction than other techniques • Include too much detail • People get confused •  e  exemplar  ( b  library  belongs(b.code,e.n_item)) • If for each element e that is an element of exemplar is true, than there exists an element b that is an element of library, such that the code of element b belongs to the item number of element e is also true • Requires more effort • Concentrates on consistent, correct models and most of the time your models are inconsistent, incorrect, incomplete ITEC 4040 – Requirements Management

21. Formalism Vs. Quality • Possible alternatives • You don’t need to build complete formal models so use a semiformal specification during development • Apply to the most critical pieces • Apply where exisitng analysis techniques are weak • Don’t formally analyze every system propery • Don’t apply formal methods in every phase of development • E.g.: Might be good for modeling requirements, but not necessarly for system design • Choose what level of abstraction to model is appropriate for the given context ITEC 4040 – Requirements Management

22. Divide and Conquer • Specify the parts individually • Satisfied? The problem is solved? • If one part is still complex: Subdivide it • Top down approach • Disadvantages • Choosing is a risk • The big decision is about what division should I make • Decision is made too early • Lack of knowledge • Lack of understanding about the problem • Real world is not always organized in a hierarchical form • Parallel and concurrent structures ITEC 4040 – Requirements Management

23. Decomposition • Decompose the problem until: • Every sub-problem is in the same level of detail • Every sub-problem can be solved in an independent way • Solutions for each sub-problem can be combined to solve the original problem • Advantages • Different people can work different sub-problems • Facilitates parallelism • Maintenance gets easier • Disadvantages • Solutions for sub-problems may not combine in such a way that would solve the problem • Real world structure is not hierarchical ITEC 4040 – Requirements Management

24. Objects • The world is composed by Objects • Objects are independent, have memory and behaviour • Objects communicate through messages • Objects are organized in class (Generalizations) • Disadvantages • The object idea comes from programming languages and can not be mapped to most of the individuals in the real world • What was the last time you sent a message to your car? • When the sun rises, does it send a message to birds to sing? ITEC 4040 – Requirements Management

25. Objects • “The world outside the machine is very rich, full of whim and recalcitrantly multifaceted to be captured in the form of objects” – M. Jackson ITEC 4040 – Requirements Management

26. Goals • Knowledge Acquisition in Automated Specification(KAOS) • Made by the University of Oregon and University of Louvain (Belgium) in 1990 and continues to evolve today through research by the University of Louvain • Key idea is to build a model for the requirements that describe the problem to be solved and the goals that must be fulfilled ITEC 4040 – Requirements Management

27. KAOS • Helps justifying requirements by linking them to higher-level goals • Each goal in the model (except roots) is typically justified by at least another goal that explains why the goal was introduced in the model • Each goal (except the leaves) is refined as a collection of sub-goals describing how the refined goal can be reached ITEC 4040 – Requirements Management

28. KAOS • Allows building a model of the whole system, not just the software • Software systems are used within a specific environment and it is very important to identify, record and take into account all the requirements and assumptions about the environment that interacts with the software system • Agents are also part of the whole system and are responsible for achieving requirements and expectations ITEC 4040 – Requirements Management

29. Example – Goals (KAOS) ITEC 4040 – Requirements Management

30. Basic Example – Elevator with KAOS ITEC 4040 – Requirements Management

31. Basic Example – Elevator with KAOS ITEC 4040 – Requirements Management

32. Basic Example – Elevator with KAOS ITEC 4040 – Requirements Management

33. Basic Example – Elevator with KAOS ITEC 4040 – Requirements Management

34. Basic Example – Elevator with KAOS ITEC 4040 – Requirements Management

35. Agents • Actors and devices are very important • They are responsible for carrying out the tasks • Agent-oriented models • New properties • Pro-active • Autonomous • Distributed • Intelligent • Etc. ITEC 4040 – Requirements Management

36. Modelling • Representation • Organization • Storage • Perspective about the Product ITEC 4040 – Requirements Management

37. Representation • Lexicon • Scenarios • Sentences • Requirements Document • Glossary ITEC 4040 – Requirements Management

38. Language Extended Lexicon (LEL) • Technique that aims to describe the symbols a certain language usages. • Main idea is the existence of an application language. This idea departs from the notation that is in the UofD there is one (or more) cultures (social group) and each has its own language • This, the main objective to be followed by Res is the identification of words or sentences that are peculiar to the social environment under study. Only after these words and sentences are identified the RE will search for their meaning ITEC 4040 – Requirements Management

39. Language Extended Lexicon (LEL) ITEC 4040 – Requirements Management

40. Language Extended Lexicon (LEL) • Use one or more technique for fact gathering (interviews, observation, document reading) • Target: Words or sentences that seem to have a special/relevant meaning in the application • Words or sentences that are frequently used or that brings doubts or that seem to be out of context • List of words and sentences • Big difference: Elicit functions vs Elicit symbols ITEC 4040 – Requirements Management

41. Language Extended Lexicon (LEL) • Each symbol is describe with Notations and Behavioural Responses. Notion represents what the symbol means (denotation). Behavioural responses describe the effects from the use of this symbol. Characterize constraints imposed to the symbol or imposed by the symbol ITEC 4040 – Requirements Management

42. Language Extended Lexicon (LEL) • Circularity and Minimum vocabulary principles • Minimal vocabulary: Refers to the sole use of frequent words with clear meaning and that are part of a restricted vocabulary • Circularity: Refers to the use of symbols from the langauge (LEL symbols) to describe notations and behavioural responses • Studies show that while explaining a symbol actors (stakeholders/users) use symbols from their language ITEC 4040 – Requirements Management

43. Language Extended Lexicon (LEL) ITEC 4040 – Requirements Management

44. Language Extended Lexicon (LEL) • Renew book • Notations • A library userborrows a book exemplar • User wants to keep the book exemplar longer • Behavioural Responses: • Library Employee changes return datefor the book exemplar ITEC 4040 – Requirements Management

45. Language Extended Lexicon (LEL) • Return Date • Notation • Established date to return lended book • Behavioural Response: • If return date is prior to current date the book exemplar is overdue ITEC 4040 – Requirements Management

46. Language Extended Lexicon (LEL) ITEC 4040 – Requirements Management

47. Specification-Oriented Modelling Techniques • For some time they were seen as elicitation techniques (Analysis) • Range from the more formal to the most used by developers • Some of them will be covered here: • DFD, Decision Table, State Chart, External Events, ER, Data Dictionaries ITEC 4040 – Requirements Management

48. What to Model • Information structure • Entity relationship diagram • Class diagram • Process and Information Flow • Dataflow diagrams • UML activity diagram • System behaviour • Statecharts • Sequence diagrams ITEC 4040 – Requirements Management

49. Dataflow Diagram (DFD) EE1 i X y • Process (task, action, activity) • Data storage • External entities • Data flow ITEC 4040 – Requirements Management

50. Dataflow Diagram (DFD) X X1 X2 X3 • Functional Decomposition • Context diagram • Level 0, 1, 2, … • Every information that is inputted has to be somehow used • Stop condition for decomposition – When I can describe the process within one page using pseudo-code a b a1 xa1 a2 b xa2 ITEC 4040 – Requirements Management