1. 1 Review of Lectures 1-21 Lecture # 22

2. 2 Introduction Requirements form the basis for all software products Requirements engineering is the process, which enables us to systematically determine the requirements for a software product

3. 3 Software Requirements - 1 Complete specification of the desired external behavior of the software system to be built What is external behavior? Software requirements may be: –Abstract statements of services and/or constraints –Detailed mathematical functions

4. 4 Software Requirements - 2 Software requirements may be: –Part of the bid of contract –The contract itself –Part of the technical document, which describes a product

5. 5 Sources of Requirements Stakeholders –People affected in some way by the system Documents Existing system Domain/business area

6. 6 Kinds of Software Requirements Functional requirements Non-functional requirements Domain requirements Inverse requirements Design and implementation constraints

7. 7 Functional Requirements - 1 Statements describing what the system does, i.e., functionality of the system Statements of services the system should provide –Reaction to particular inputs –Behavior in particular situations Sequencing and parallelism are also captured by functional requirements

8. 8 Examples The system shall solve a quadratic equation using the following formula x = (-b+sqrt(b 2 – 4*a*c))/2*a The user shall be able to search either the entire database of patients or select a subset from it (admitted patients, or patients with asthma, etc.)

9. 9 Non-Functional Requirements - 1 Most non-functional requirements relate to the system as a whole. They include constraints on timing, performance, reliability, security, maintainability, accuracy, the development process, standards, etc., emergent behavior Often more critical than individual functional requirements

10. 10 Non-Functional Requirements - 2 Must be built into the framework of the software product Failure to meet a non-functional system requirement may make the whole system unusable

11. 11 Types of Non-Functional Requirements Non-Functional requirements Product requirements Organizational requirements External requirements

12. 12 Product Requirements - 1 Product requirements Efficiency requirements Reliability requirements Portability requirements Usability requirements Performance requirements Space requirements

13. 13 Product Requirements - 2 The system shall allow one hundred thousand hits per minute on the website The system shall not have down time of more than one second for continuous execution of one thousand hours

14. 14 Organizational Requirements - 1 Implementation requirements Standards requirements Organizational requirements Delivery requirements

15. 15 Organizational Requirements - 2 The system development process and deliverable documents shall conform to the MIL-STD-2167A Any development work sub-contracted by the development organization shall be carried out in accordance with Capability Maturity Model

16. 16 External Requirements - 1 Ethical requirements Interoperability requirements External requirements Legislative requirements Privacy requirements Safety requirements

17. 17 External Requirements - 2 The system shall not disclose any personal information about members of the library system to other members except system administrators The system shall comply with the local and national laws regarding the use of software tools

18. 18 Metrics for Non-Functional Requirements Speed Size Ease of use Reliability Robustness Portability

19. 19 Domain Requirements - 1 Requirements that come from the application domain and reflect fundamental characteristics of that application domain. Can be functional or non-functional These requirements, sometimes, are not explicitly mentioned, as domain experts find it difficult to convey domain requirements

20. 20 Domain Requirements - 2 Their absence can cause significant dissatisfaction Domain requirements can impose strict constraints on solutions. This is particularly true for scientific and engineering domains

21. 21 Inverse Requirements They explain what the system shall not do. Many people find it convenient to describe their needs in this manner These requirements indicate the indecisive nature of customers about certain aspects of a new software product

22. 22 Design and Implementation Constraints They are development guidelines within which the designer must work These requirements can seriously limit design and implementation options Can also have impact on human resources

23. 23 Requirements Problems The requirements don’t reflect the real needs of the customer for the system Requirements are inconsistent and/or incomplete There are misunderstandings between customers, those developing the system requirements, and software engineers developing or maintaining the system

24. 24 Problems with Natural Languages - 1 Lack of clarity Requirements confusion Requirements amalgamation

25. 25 Problems with Natural Languages - 2 Natural language understanding relies on the specification readers and writers using the same words for same concept A natural language requirements specification is over-flexible. You can say the same thing in completely different ways

26. 26 Problems with Natural Languages - 3 It is not possible to modularize natural language requirements. It may be difficult to find all related requirements –To discover the impact of a change, every requirement have to be examined

27. 27 Process - 1 A process is an organized set of activities, which transforms inputs to outputs Synonyms: procedure, method, course of action, etc. Processes are essential for dealing with complexity in real world

28. 28 Process - 2 Processes document the steps in solving a certain problem They allow knowledge to be reused Allows people to apply the process in their peculiar but similar problems

29. 29 Requirements Engineering Process The process(es) involved in developing system requirements

30. 30 RE Process - Inputs and Outputs Requirement engineering process Existing systems information Stakeholder needs Organizational standards Regulations Domain information System specification Agreed requirements System models

31. 31 RE Process Variability RE processes vary radically from one organization to another, and even within an organization Unstructured process rely heavily on the experience of the people, while systematic processes are based on application of some analysis methodology, but still require human judgment

32. 32 Variability Factors - 1 Technical maturity Disciplinary involvement Organizational culture Application domain

33. 33 Requirements Engineering Activities Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation User Needs, Domain Information, Existing System Information, Regulations, Standards, Etc. Requirements Document Agreed Requirements

34. 34 RE Process Maturity Model Ad-hoc requirements engineering Requirements errors are common Standardized requirements engineering Fewer requirements errors Defined process based on best practices Process improvement in place Initial Repeatable Defined

35. 35 Social and Cultural Issues in RE Some aspects of the requirements engineering process deal with social and cultural issues What is the best way to deal with these issues?

36. 36 Six Areas of Social Issues - 1 Within the client organization Within the requirements team Between the client and the requirements team

37. 37 Six Areas of Social Issues - 2 Between the development and requirements teams Within the development team Between the development team and the client

38. 38 Cultural Issues in RE Time zones differences Language and terminology differences Religious and racial differences Ethical issues Political differences Differences in business environment

39. 39 Basics of Knowledge Acquisition Reading Listening Asking Observing

40. 40 Requirements Elicitation Techniques Individual Group Modeling Cognitive

41. 41 Problems in Requirements Elicitation Problems of scope Problems of understanding Problems of volatility

42. 42 Components of Requirements Elicitation Business Context Stakeholder Needs and Constraints Application Domain Problem to be Solved

43. 43 A General Requirements Elicitation Process Establish Objectives Understand Background Organize Knowledge Collect Requirements Business goals Problem to be solved System constraints Organizational structure Application domain Existing systems Stakeholder identification Goal prioritization Domain knowledge filtering Stakeholder requirements Domain requirements Organizational requirements

44. 44 Knowledge Structuring Techniques Partitioning Abstraction Projection

45. 45 Specific Elicitation Techniques Interviews Scenarios Observations and social analysis Requirements reuse

46. 46 Interview Steps Prepare Conduct –Opening –Body –Closing Follow through

47. 47 Listening Steps Hear Interpret Respond Evaluate

48. 48 Iterative Aspects of Elicitation, Analysis, and Negotiation Requirements Elicitation Requirements Analysis Draft Statement of Requirements Problems Requirements Negotiation Requirements Documents

49. 49 Requirements Analysis Process Necessity checking Consistency and completeness checking Feasibility checking Unnecessary requirements Conflicting and incomplete requirements Infeasible requirements Requirements Analysis

50. 50 Analysis Techniques Analysis checklists –A checklist is a list of questions which analysts may use to assess each requirement Interaction matrices –Interaction matrices are used to discover interactions between requirements and to highlight conflicts and overlaps

51. 51 Requirements Negotiation Process Requirements discussion Requirements prioritization Requirements agreement Requirements Negotiation Unnecessary requirements Conflicting and incomplete requirements Infeasible requirements

52. 52 Stages of Negotiation Meetings Information stage Discussion stage Resolution stage

53. 53 Types of Requirements Errors Errors of omission Errors of commission Errors of clarity and ambiguity Errors of speed and capacity

54. 54 Prevention vs. Removal For requirements errors, prevention is usually more effective than removal Joint application development (JAD), quality function deployment (QFD), and prototyping are more effective in defect prevention Requirements inspections and prototyping play an important role in defect removal. Discussed in detail perspective-based reading technique

55. 55 Validation Inputs and Outputs Requirements Validation Requirements document Organizational knowledge Organizational standards List of problems Agreed actions

56. 56 Requirements Review Process Plan review Distribute documents Prepare for review Hold review meeting Follow-up actions Revise documents

57. 57 Pre-review Checking Stages Check document structure Check document completeness Check document against standards Run automatic checkers Requirements document Problems report

58. 58 Hard-to-Test Requirements System requirements Exclusive requirements Some non-functional requirements

59. 59 Requirements Management The process of managing change to the requirements for a system In this lecture, we’ll talk about the reasons for changes in requirements and how to manage them

60. 60 Sources of Change - 1 New business or market conditions dictate changes in product requirements or business rules New customer needs demand modification of data produced by information systems, functionality delivered by products, or services delivered by computer-based system

61. 61 Sources of Change - 2 Reorganization or business growth/downsizing causes changes in project priorities or software engineering team structure Budgetary or scheduling constraints cause a redefinition of the system or product

62. 62 Main Concerns in Requirements Management Managing changes to agreed requirements Managing the relationships between requirements Managing the dependencies between the requirements document and other documents produced in the systems engineering process

63. 63 Change Management Stages Problem analysis and change specification Change analysis and costing Change implementation Identified problem Revised requirements

64. 64 Change Analysis and Costing Process Check request validity Find directly affected requirements Find dependent Propose requirements changes Assess costs of change Assess costs acceptability Requirements change list Change request Rejected request Valid request Req. list Rejected request Rejected request Accepted change Cost info Cost info Requirements changes Customer information Customer information

65. 65 Requirements Traceability Refers to ability to describe and follow the life of a requirement, in both a forwards and backwards direction That is from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases

66. 66 Classifications of Requirements Traceability Backward-from traceability Forward-from traceability Backward-to traceability Forward-to traceability

67. 67 Backwards and Forwards Traceability Business planRequirements document Design specification Forward-to traceabilityForward-from traceability Backward-from traceabilityBackward-to traceability

68. 68 Categories of Traceability Requirements-sources traceability Requirements-rationale traceability Requirements-requirements traceability Requirements-architecture traceability Requirements-design traceability Requirements-interface traceability

69. 69 Types of Prototyping Throw-away prototyping Evolutionary prototyping

70. 70 Approaches to Prototyping Paper prototyping ‘Wizard of Oz’ prototyping Executable prototyping

71. 71 Good Luck on Mid Term Paper