1. M ETHODS FOR REQUIREMENTS ENGINEERING 1

2. O BJECTIVES To explain the role of methods and techniques in requirements engineering To introduce data-flow modelling To introduce semantic data modelling To introduce object-oriented methods To explain the role of formal methods in requirements engineering 2

3. R OLE OF METHODS IN RE Process of requirements engineering (RE) is usually guided by a requirements method Requirement methods are systematic ways of producing system models The system models based on computational concepts such as object or functions rather than app domain concept. System models important bridges between the analysis and the design process 3

4. N ECESSARY PROPERTIES FOR A RE METHOD Suitability for agreement with the end-user The precision of definition of its notation Assistance with formulating requirements Definition of the world outside Scope for malleability Scope for integrating other approaches Scope for communication Tool support 4

5. S UITABILITY FOR AGREEMENT WITH THE END - USE The extent to which the notation is understandable by someone without formal training. Formal specification is difficult to be understood by most people Solution: combine both formal and informal descriptions of system requirements 5

6. T HE PRECISION OF DEFINITION OF ITS NOTATION The extent to which the requirements may be checked for consistency and correctness using the notation. Imprecise notation  errors and misunderstanding 6

7. A SSISTANCE WITH FORMULATING REQUIREMENTS To establish the system requirements must be guided by a problem analysis technique that takes all these viewpoints into account (capture, structuring, analysis and resolution of many ideas, perspectives and relationships at varying levels) 7

8. D EFINITION OF THE WORLD OUTSIDE The requirements model shall model the environment with which the component interacts 8

9. S COPE OF MALLEABILITY The approach used and the resultant specification must be tolerant of temporary incompleteness and adaptable changes 9

10. S COPE FOR INTEGRATING OTHER APPROACHES No one requirements approach that adequately articulates all the requirements of a system Eg DFD – inadequately represent control requirements Eg. Formal language – inadequately non-functional requirements 10

11. S COPE FOR COMMUNICATION The requirements method or tool needs to be able to support the need for people to communicate their ideas and obtain feedback 11

12. T OOL SUPPORT System development generates a large amount of information that must be analysed Tool support contributes a lot to improve the management its complexity especially large project 12

13. N O IDEAL RE METHOD There is no ideal requirement method A number of methods use a variety of modelling techniques to formulate system requirements System models can be enriched by modelling different aspects of using modelling techniques 13

14. M ODELING TECHNIQUES Data-flow models Compositional models Classification models Stimulus-response models Process models 14

15. D ATA FLOW MODELLING Based on the notion that systems can be modelled as a set of interacting functions Uses data-flow diagrams (DFDs) to graphically represent the external entities, processes, data-flow, and data stores 15

16. D ATA FLOW NOTATION 16

17. N OTATION VARIABILITY There is little uniformity in industry concerning the DFD notation The notation shown was advanced by DeMarco Gane and Sarson use rounded rectangles for bubbles shadowed rectangles for sources and destinations, and squared off C’s for data stores Orr uses rectangles for bubbles, ellipses for sources and destinations, and ellipses for data stores 17

18. DFD EXAMPLE Consider a simple library system intended to automate the issuing of library items The first data-flow diagram derived by the analyst represents the ‘target’ system at its context level The next level (level 1) of the data-flow diagram is constructed by decomposing the library system bubble into sub-functions 18

19. L IBRARY EXAMPLE - C ONTEXT LEVEL DATA FLOW DIAGRAM 19

20. L IBRARY EXAMPLE - L EVEL 1 DATA FLOW DIAGRAM 20

21. S TRUCTURED ANALYSIS The data-flow approach is typified by the Structured Analysis method (SA) Two major strategies dominate structured analysis ‘Old’ method popularised by DeMarco ‘Modern’ approach by Yourdon 21

22. D E M ARCO A top-down approach The analyst maps the current physical system onto the current logical data-flow model The approach can be summarised in four steps: Analysis of current physical system Derivation of logical model Derivation of proposed logical model Implementation of new physical system 22

23. M ODERN STRUCTURED ANALYSIS Distinguishes between user’s real needs and those requirements that represent the external behaviour satisfying those needs Includes real-time extensions Other structured analysis approaches include: Structured Analysis and Design Technique (SADT) Structured Systems Analysis and Design Methodology (SSADM) 23

24. S EMANTIC DATA MODELING An important aspect of system modeling is to define the logical form of the data processed by the system One way of doing this is to use the relational model. 24

25. R ELATIONAL MODEL Data may be modelled using the relational model Specifies data as a set of tables, with some columns being used as common keys Disadvantages of relational model Implicit data typing – data type associated with relations Inadequate modelling of relations Data model should include information about the semantics of the data 25

26. S EMANTIC MODELS Approaches to semantic data modelling include: Entity-relationship model (Chen, 1976) RM/ T (Codd, 1979) SDM (Hammer and McLeod, 1981) Models identify the entities in a database, their attributes and their relationships Uses graphical notations 26

27. N OTATION FOR SEMANTIC DATA MODELLING 27 An Entity A relation between entitiesAn inheritance relation

28. E XTENSIONS TO ENTITY RELATIONSHIP MODEL The basic ERM has been extended to include sub and super-types to the basic entity and relation primitives Types may have sub-types Types may inherit the attributes of their super- types In addition, sub-types may have private attributes 28

29. ERM EXAMPLE - S OFTWARE REQUIREMENT 29

30. O BJECT - ORIENTED APPROACHES Closest precursor is entity relationship model Requirements methods based on object orientation: Shlaer and Mellor (1988) Colbert (1989) Coad and Yourdon (1989) Wirf-Brock (1990) Rumbaugh (1991) Jacobson (1992) Martin-Odell (1992) Notations for the various methods are semantically similar 30

31. O BJECT Are major actors, agents, and servers in the problem space of the system Identified by analysing the domain Objects include: Devices that the system interacts with Systems that interface with the system under study Organisational units Things that must be remembered over time Physical locations or sites Specific roles played by humans 31

32. B ASIC CONCEPTS Encapsulation Class Inheritance Operations or Services 32

33. O BJECT DEFINITION Something real or abstract about which we store data and those operations that manipulate the data Examples include: An account, a sensor, a software design, a car, an organisation May be composite - composed of other objects 33

34. C LASS DEFINITION An implementation of an object type The object type Bank Customer refers to a class of bank customers Objects that share common attributes and operations An object is an instance of a class For example, if “John Smith” is a bank customer, then bank customer is the class and “John Smith” is an instance of the bank customer 34

35. O PERATIONS AND METHODS Used to read and manipulate the data of an object Reference only the data structures of that object type To access the data structures of another object, objects must send messages to that object Methods specify the way in which operations are encoded in software 35

36. E NCAPSULATION Packaging together of data and operations that manipulate the data Details of how the operation is performed hidden from user Prevents the unauthorised access of an object’s data 36

37. I NHERITANCE Objects at a lower level in class hierarchy inherit the operations and attributes of their parent(s) Objects are able to incorporate data and/or operations specific to themselves Inherits data from more than one parent is called multiple inheritance. 37

38. I LLUSTRATION OF OBJECT CONCEPTS 38

39. M ESSAGES Objects communicate by sending messages Message comprises: Name of receiver object Operation to be invoked Optional set of parameters When an object receives a message it causes an operation to be invoked The operation performs the appropriate method 39

40. M ESSAGE PASSING 40

41. O BJECT MODELLING - L IBRARY EXAMPLE A library system is intended to provide its users with the ability to automate the process of: Acquiring library items Cataloguing library items Browsing library items Loaning library items Library items comprise published and recorded material The system will be administered by a member of the library staff Users must register with the system administrator before they can borrow library items 41

42. L IBRARY EXAMPLE ( CONTD.) Library users are drawn from three primary groups: Students, Members of staff and External users All library users have as part of their registration: Name, Library number, Address, Account In addition the following information also required for registration: Students - Degree programme and admission number. Staff - Staff number External users - Employer details 42

43. S TEPS IN OBJECT - ORIENTED METHOD Most methods based on the object-oriented model share certain common analysis steps: Identify core objects Construct the object structures defining the associations between object classes Define the attributes associated with each object Determine the relevant operations for each object Define the messages that may be passed between objects 43

44. O BJECT - ORIENTED NOTATION USED 44

45. S TEP 1 - I NITIAL CLASSES IDENTIFIED 45

46. S TEP 2 - R ELATIONSHIPS BETWEEN CLASSES We can identify the following relationships from the partial requirements: (i)A library user borrows a library item (ii)A library item is recorded or published (iii)The system administrator registers the library user (iv)Library users are students, staff and external users (v)The system administrator catalogues the library items (vi)The library assistant issues the library items 46

47. S TEP 2 - B ASIC OBJECT MODEL SHOWING ATTRIBUTES AND RELATIONSHIPS 47

48. S TEP 2 - I NHERITANCE FOR L IBRARY USER 48

49. S TEP 2 - I NHERITANCE FOR LIBRARY ITEM 49

50. S TEP 3 - I DENTIFYING THE ATTRIBUTES Attributes can be revealed by the analysis of the system requirements For example, it is a requirement that all library users must be registered before they can use the library This means that we need to keep registration data about library users Library users may also be provided with an account to keep track of the items loaned to them Library item has the attributes; title, description and classmark The library user class has the attributes; name, address and library id 50

51. S TEP 4 - O BJECT OPERATIONS This step is intended to describe operations to be performed on the objects Certain operations are implicit from the object structure These include operations for accessing and modifying the attribute values. These operations are assumed and we need not show them explicitly in the model One way of identifying operations is by modelling the messages that may be passed between the objects 51

52. S TEP 4 - M ESSAGES BETWEEN OBJECTS 52

53. S TEP 4 - O PERATIONS FOR LIBRARY USER AND LIBRARY STAFF 53

54. S TEP 4 - O PERATIONS FOR LIBRARY ITEM 54

55. U SE CASE AND EVENT SCENARIOS Object operations may also be identified by modelling event scenarios for the different functions provided by the system Events are then traced to objects that react to them Typically scenarios model the interactions between the users and the system 55

56. T YPICAL USE - CASE SCENARIO FOR LIBRARY SYSTEM 56

57. E VENT SCENARIO FOR BORROWING ITEM 57

58. F ORMAL METHODS Requirements specification techniques can be categorised on a “formality” spectrum Semi-formal and informal methods Use natural language, diagrams, tables and simple notation Include structured analysis and object-oriented analysis Formal methods include: Based on mathematically formal syntax and semantics Include Z, B, VDM, LOTOS 58

59. F ORMAL METHODS ( CONTD.) Provide a means for achieving a high degree of confidence that a system will conform to its specification Do not absolute guarantee of correctness Have little directly to offer to the problems of managing software projects However, benefits can be gained from gaining a clear understanding of the task at an early stage 59

60. C OMPONENTS OF FORMAL SPECIFICATION LANGUAGE Syntax that defines the specific notation with which the specification is represented Semantics that help to define a “universe of objects” that will be used to describe the system Relations which define the rules that indicate which objects properly satisfy the specification 60

61. F ORMAL METHODS NOT WIDESPREAD Formal methods are not widely used amongst software developers Factors contributing to slow acceptance of formal methods:  Difficulty in understanding the notations  Difficulty in formalising certain aspects of requirements  Payoff is not obvious. 61

62. F ORMAL SPECIFICATION LANGUAGES The number of formal specification languages in use today can be broadly divided into two categories. Model-based notations Z and Vienna Development Method (VDM) Process algebras -based notations Communicating Sequential Processes (CSP), CCS and LOTOS 62

63. A DVANTAGES OF FORMAL METHODS Removes ambiguity Encourages greater rigor in the early stages of software engineering Possible to verify the correctness, incompleteness and inconsistency checking of the specification 63

64. D ISADVANTAGES OF FORMAL METHODS Difficult to represent behavioural aspects of problem Some requirements can only be determined through empirical evaluation and prototyping Do not address the problem of how the requirements are constructed Lack of adequate tool support 64

65. Z - A MODEL BASED FORMAL METHOD A Z specification is presented as a collection of schemas A Schema comprises three main parts: Name, Declarations and Predicates Schema declarations set out the names and types of entities introduced in the schema Schema predicate sets out the relationships between the entities in the declaration 65

66. U SING Z Variable declarations are of the form identifier:type Predicates give properties of, and relationships between the variables A schema may be used to describe either a state or an operation To describe a state, the declared variables form the components of the state and the predicates give the invariant properties of the state For an operation, the declarations consist of the initial state components, the final components, the inputs and the outputs of the operation For an operation, the predicate part describes the relation between the inputs, outputs, and initial and final states 66

67. Z S CHEMA 67

68. L IBRARY EXAMPLE The state space of the lending library can be defined using the following schema: 68

69. S CHEMA FOR BORROW OPERATION 69

70. S CHEMA FOR ‘N EW ’ AND ‘R ETURN ’ OPERATIONS 70

71. K EY POINTS No ideal requirements method System models can be considerably enriched by combining different techniques Data-flow model is based on the notion that systems can be modelled as a set of interacting functions The object-oriented approach is based on the notion that systems can be modelled as a set of interacting objects Formal methods are based on mathematical principles and are intended to achieve a high degree of confidence that a system will conform to its specifications 71

72. 72 R EQUIREMENTS V ALIDATION

73. 73 V ALIDATION OBJECTIVES Certifies that the requirements document is an acceptable description of the system to be implemented Checks a requirements document for Completeness and consistency Conformance to standards Requirements conflicts Technical errors Ambiguous requirements

74. 74 A NALYSIS AND VALIDATION Analysis works with raw requirements as elicited from the system stakeholders “Have we got the right requirements” is the key question to be answered at this stage Validation works with a final draft of the requirements document i.e. with negotiated and agreed requirements “Have we got the requirements right” is the key question to be answered at this stage

75. 75 V ALIDATION INPUTS AND OUTPUTS

76. 76 V ALIDATION INPUTS Requirements document Should be a complete version of the document, not an unfinished draft. Formatted and organised according to organisational standards Organisational knowledge Knowledge, often implicit, of the organisation which may be used to judge the realism of the requirements Organisational standards Local standards e.g. for the organisation of the requirements document

77. 77 V ALIDATION OUTPUTS Problem list List of discovered problems in the requirements document Agreed actions List of agreed actions in response to requirements problems. Some problems may have several corrective actions; some problems may have no associated actions

78. 78 R EQUIREMENTS REVIEWS A group of people read and analyse the requirements, look for problems, meet and discuss the problems and agree on actions to address these problems

79. 79 R EQUIREMENTS REVIEW PROCESS

80. 80 R EVIEW ACTIVITIES Plan review The review team is selected and a time and place for the review meeting is chosen. Distribute documents The requirements document is distributed to the review team members Prepare for review Individual reviewers read the requirements to find conflicts, omissions, inconsistencies, deviations from standards and other problems.

81. 81 R EVIEW ACTIVITIES Hold review meeting Individual comments and problems are discussed and a set of actions to address the problems is agreed. Follow-up actions The chair of the review checks that the agreed actions have been carried out. Revise document The requirements document is revised to reflect the agreed actions. At this stage, it may be accepted or it may be re-reviewed

82. 82 P ROBLEM ACTIONS Requirements clarification The requirement may be badly expressed or may have accidentally omitted information which has been collected during requirements elicitation. Missing information Some information is missing from the requirements document. It is the responsibility of the requirements engineers who are revising the document to discover this information from system stakeholders. Requirements conflict There is a significant conflict between requirements. The stakeholders involved must negotiate to resolve the conflict. Unrealistic requirement The requirement does not appear to be implementable with the technology available or given other constraints on the system. Stakeholders must be consulted to decide how to make the requirement more realistic.

83. 83 P RE - REVIEW CHECKING Reviews are expensive because they involve a number of people spending time reading and checking the requirements document This expense can be reduced by using pre- review checking where one person checks the document and looks for straightforward problems such as missing requirements, lack of conformance to standards, typographical errors, etc. Document may be returned for correction or the list of problems distributed to other reviewers

84. 84 P RE - REVIEW CHECKING

85. 85 R EVIEW TEAM MEMBERSHIP Reviews should involve a number of stakeholders drawn from different backgrounds People from different backgrounds bring different skills and knowledge to the review Stakeholders feel involved in the RE process and develop an understanding of the needs of other stakeholders Review team should always involve at least a domain expert and an end-user

86. 86 R EVIEW CHECKLISTS Understandability Can readers of the document understand what the requirements mean? Redundancy Is information unnecessarily repeated in the requirements document? Completeness Does the checker know of any missing requirements or is there any information missing from individual requirement descriptions? Ambiguity Are the requirements expressed using terms which are clearly defined? Could readers from different backgrounds make different interpretations of the requirements?

87. 87 R EVIEW CHECKLISTS Consistency Do the descriptions of different requirements include contradictions? Are there contradictions between individual requirements and overall system requirements? Organisation Is the document structured in a sensible way? Are the descriptions of requirements organised so that related requirements are grouped? Conformance to standards Does the requirements document and individual requirements conform to defined standards? Are departures from the standards, justified? Traceability Are requirements unambiguously identified, include links to related requirements and to the reasons why these requirements have been included?

88. 88 C HECKLIST QUESTIONS Is each requirement uniquely identified? Are specialised terms defined in the glossary Does a requirement stand on its own or do you have to examine other requirements to understand what it means? Do individual requirements use the terms consistently Is the same service requested in different requirements? Are there any contradictions in these requests? If a requirement makes reference to some other facilities, are these described elsewhere in the document? Are related requirements grouped together? If not, do they refer to each other?

89. 89 R EQUIREMENTS PROBLEM EXAMPLE “4. EDDIS will be configurable so that it will comply with the requirements of all UK and (where relevant) international copyright legislation. Minimally, this means that EDDIS must provide a form for the user to sign the Copyright Declaration statement. It also means that EDDIS must keep track of Copyright Declaration statements which have been signed/not-signed. Under no circumstances must an order be sent to the supplier if the copyright statement has not been signed.”

90. 90 P ROBLEMS Incompleteness What international copyright legislation is relevant? What happens if the copyright declaration is not signed? If a signature is a digital signature, how is it assigned? Ambiguity What does signing an electronic form mean? Is this a physical signature or a digital signature? Standards More than 1 requirement. Maintenance of copyright is one requirement; issue of documents is another

91. 91 P ROTOTYPING Prototypes for requirements validation demonstrate the requirements and help stakeholders discover problems Validation prototypes should be complete, reasonably efficient and robust. It should be possible to use them in the same way as the required system User documentation and training should be provided

92. 92 P ROTOTYPING FOR VALIDATION

93. 93 P ROTOTYPING ACTIVITIES Choose prototype testers The best testers are users who are fairly experienced and who are open-minded about the use of new systems. End-users who do different jobs should be involved so that different areas of system functionality will be covered. Develop test scenarios Careful planning is required to draw up a set of test scenarios which provide broad coverage of the requirements. End-users shouldn’t just play around with the system as this may never exercise critical system features. Execute scenarios The users of the system work, usually on their own, to try the system by executing the planned scenarios. Document problems Its usually best to define some kind of electronic or paper problem report form which users fill in when they encounter a problem.

94. 94 U SER MANUAL DEVELOPMENT Writing a user manual from the requirements forces a detailed requirements analysis and thus can reveal problems with the document Information in the user manual Description of the functionality and how it is implemented Which parts of the system have not been implemented How to get out of trouble How to install and get started with the system

95. 95 M ODEL VALIDATION Validation of system models is an essential part of the validation process Objectives of model validation To demonstrate that each model is self-consistent If there are several models of the system, to demonstrate that these are internally and externally consistent To demonstrate that the models accurately reflect the real requirements of system stakeholders Some checking is possible with automated tools Paraphrasing the model is an effective checking technique

96. 96 D ATA - FLOW DIAGRAM FOR I SSUE

97. 97 P ARAPHRASED DESCRIPTION

98. 98 R EQUIREMENTS TESTING Each requirement should be testable i.e. it should be possible to define tests to check whether or not that requirement has been met. Inventing requirements tests is an effective validation technique as missing or ambiguous information in the requirements description may make it difficult to formulate tests Each functional requirement should have an associated test

99. 99 T EST CASE DEFINITION What usage scenario might be used to check the requirement? Does the requirement, on its own, include enough information to allow a test to be defined? Is it possible to test the requirement using a single test or are multiple test cases required? Could the requirement be re-stated to make the test cases more obvious?

100. 100 T EST RECORD FORM The requirement’s identifier There should be at least one for each requirement. Related requirements These should be referenced as the test may also be relevant to these requirements. Test description A brief description of the test and why this is an objective requirements test. This should include system inputs and corresponding outputs. Requirements problems A description of problems which made test definition difficult or impossible. Comments and recommendations These are advice on how to solve requirements problems which have been discovered.

101. 101 R EQUIREMENTS TEST FORM

102. 102 H ARD - TO - TEST REQUIREMENTS System requirements Requirements which apply to the system as a whole. In general, these are the most difficult requirements to validate irrespective of the method used as they may be influenced by any of the functional requirements. Tests, which are not executed, cannot test for non-functional system-wide characteristics such as usability. Exclusive requirements These are requirements which exclude specific behaviour. For example, a requirement may state that system failures must never corrupt the system database. It is not possible to test such a requirement exhaustively. Some non-functional requirements Some non-functional requirements, such as reliability requirements, can only be tested with a large test set. Designing this test set does not help with requirements validation.

103. 103 K EY POINTS Requirements validation should focus on checking the final draft of the requirements document for conflicts, omissions and deviations from standards. Inputs to the validation process are the requirements document, organisational standards and implicit organisational knowledge. The outputs are a list of requirements problems and agreed actions to address these problems. Reviews involve a group of people making a detailed analysis of the requirements. Review costs can be reduced by checking the requirements before the review for deviations from organisational standards. These may result from more serious requirements problems.

104. 104 K EY POINTS Checklists of what to look for may be used to drive a requirements review process. Prototyping is effective for requirements validation if a prototype has been developed during the requirements elicitation stage. Systems models may be validated by paraphrasing them. This means that they are systematically translated into a natural language description. Designing tests for requirements can reveal problems with the requirements. If the requirement is unclear, it may be impossible to define a test for it.

105. M ASTER THESIS http://www.bth.se/fou/cuppsats.nsf/all/03a48c377 2d5b49ac12574ff002e6fd4/$file/Requirements%2 0Validation%20Techniques%20(RVTs)%20Practi ced%20in%20Industry%20- %20Studies%20of%20Six%20Companies.pdf