1. Requirements Engineering Copyright, 1999 © Jerzy R. Nawrocki Jerzy Nawrocki Jerzy.Nawrocki@put.poznan.pl Personal Software Process Lecture 2

2. J. Nawrocki, PSP, Lecture 2 Introduction System engineering: information engineering (a business enterprise)information engineering (a business enterprise) product engineering (a production process)product engineering (a production process) Software engineering vs. system engineering

3. J. Nawrocki, PSP, Lecture 2 Computer-based systems SoftwareSoftware HardwareHardware PeoplePeople DatabaseDatabase DocumentationDocumentation ProceduresProcedures

4. J. Nawrocki, PSP, Lecture 2 Restraining factors AssumptionsAssumptions SimplificationsSimplifications LimitationsLimitations ConstraintsConstraints PreferencesPreferences

5. J. Nawrocki, PSP, Lecture 2 A good SRS Unambiguous (one interpretation)Unambiguous (one interpretation) Verifiable (one can check that req. are met)Verifiable (one can check that req. are met) Complete (responses to invalid input)Complete (responses to invalid input) Consistent (no conflicts between req.)Consistent (no conflicts between req.) Modifiable (changes are not a big problem)Modifiable (changes are not a big problem) Traceable (origin of each req. is clear)Traceable (origin of each req. is clear) Usable during the Operation and Maintenance PhaseUsable during the Operation and Maintenance Phase

6. J. Nawrocki, PSP, Lecture 2 Source Documents for Requirements.doc Manual SRS SRS Ver. n Ver. n+1

7. J. Nawrocki, PSP, Lecture 2 Source Documents for Requirements SD4R: Source document for requirements Types of SD4R: Email Video File Audio Hard(copy)... Advice: Try to keep all the SD4Rs as text files Advice: Try to keep all the SD4Rs as text files

8. J. Nawrocki, PSP, Lecture 2 Requirements document (1) 1. Introduction 1.1 Purpose of the document 1.1 Purpose of the document 1.2 Scope of the product 1.2 Scope of the product 1.3 Definitions, acronyms and 1.3 Definitions, acronyms and abbreviations abbreviations 1.4 References 1.4 References 1.5 Overview of the document 1.5 Overview of the document

9. J. Nawrocki, PSP, Lecture 2 Requirements document (2) 2. General description 2.1 Product perspective 2.1 Product perspective 2.2 Viewpoints 2.2 Viewpoints 2.2.1 Stakeholders 2.2.1 Stakeholders 2.2.2 Users 2.2.2 Users 2.2.3 Domain 2.2.3 Domain 2.2.4 Components 2.2.4 Components 2.3 System architecture and use cases in UML 2.3 System architecture and use cases in UML 2.4 General constraints 2.4 General constraints 2.5 Assumptions and dependencies 2.5 Assumptions and dependencies

10. J. Nawrocki, PSP, Lecture 2 Requirements document (3) 3. Technical requirements 3.1 Functional requirements 3.1 Functional requirements 3.1.1 Requirement 1 3.1.1 Requirement 1 3.1.1.1 Introduction 3.1.1.1 Introduction Viewpoint and source(s) Viewpoint and source(s) Firmness and importance Firmness and importance Verifiability and clarity Verifiability and clarity 3.1.1.2 Inputs 3.1.1.2 Inputs 3.1.1.3 Processing 3.1.1.3 Processing 3.1.1.4 Outputs 3.1.1.4 Outputs

11. J. Nawrocki, PSP, Lecture 2 Requirements document (4) 3.1.2 Requirement 2 3.1.2 Requirement 2.... 3.2 External interface requirements 3.2 External interface requirements 3.2.1 User interfaces 3.2.1 User interfaces 3.2.2 Hardware interfaces 3.2.2 Hardware interfaces 3.2.3 Software interfaces 3.2.3 Software interfaces 3.2.4 Communication interfaces 3.2.4 Communication interfaces 3.3 Performance requirements 3.3 Performance requirements

12. J. Nawrocki, PSP, Lecture 2 Requirements document (5) 3.4 Design constraints 3.4 Design constraints 3.4.1 Standards compliance 3.4.1 Standards compliance 3.4.2 Hardware limitations 3.4.2 Hardware limitations...... 3.5 Attributes 3.5 Attributes 3.5.1 Security 3.5.1 Security 3.5.2 Maintainability 3.5.2 Maintainability......

13. J. Nawrocki, PSP, Lecture 2 Requirements document (6) 3.6 Other requirements 3.6.1 Database 3.6.1 Database 3.6.2 Operations 3.6.2 Operations 3.6.3 Site adaptation 3.6.3 Site adaptation 3.6.4 Training 3.6.4 Training...... 3.7 Non-technical requirements AppendixesIndex

14. J. Nawrocki, PSP, Lecture 2 Developers Customers FAST FAST = Facilitated Application Specification Technique JAD (Joint Application Development) is another approach to FAST Facilitator Recorder

15. J. Nawrocki, PSP, Lecture 2 FAST for SDS Persons involved Facilitator (5th year student) - runs the meeting(s) Recorder (another 5th year student) - takes notes, serves tape recorder or video recorder (  Piotr Giera) Developers (4th year students of MSE) and customer representatives (1 for each view) - work on requirements Supervisor and Adam Wojciechowski - know about the meeting date & time

16. J. Nawrocki, PSP, Lecture 2 FAST for SDS Input documents (1) Product request (  Project Proposal, in the customer’s language, HTML 3.0) Information about FAST place (Polish- German Centre?, 9:00 - 15:00) and time (2 - 4 hours by 29.10.99) - should be agreed by 22.10.99 (customer, 5th year students, and the bar manager)

17. J. Nawrocki, PSP, Lecture 2 FAST for SDS The list of stakeholders and views should be ready before the project leaders start to organise the FAST meeting. Get from the customer the initial list of requirements sources (manuals, organisation charts, technical data,..) and read it before the FAST meeting. If not feasible, the meeting can be conducted via phone or e-mail.

18. J. Nawrocki, PSP, Lecture 2 FAST for SDS Input documents (2) Worksheet to fill in: Missing stakeholders Missing requirements sources Objects (devices, documents, etc.): external to the system produced by the system internal - used by the system Services that manipulate the objects Constraints (cost, size, time, accuracy,..)

19. J. Nawrocki, PSP, Lecture 2 FAST for SDS A FAST meeting Product justification (every one should agree) ~ n x 1’ Presentation of the worksheets (one by one, no critique) ~ n x 15’ Deciding (discussion) about: Stakeholders ~ n x 1’ System architecture (objects) ~ n x 5’ Services ~ n x 10’ Constraints ~ n x 5’ Validation criteria ~ n x 5’

20. J. Nawrocki, PSP, Lecture 2 FAST for SDS Meeting outcomes Direct: Meeting minutes Indirect: Software Requirements Specification (validation criteria!)

21. J. Nawrocki, PSP, Lecture 2 Quality Function Deployment A quality management techniqueA quality management technique Japan, Kobe Shipyard, 1970sJapan, Kobe Shipyard, 1970s QFD aim is to maximise customer satisfactionQFD aim is to maximise customer satisfaction Three types of requirements: normal, expected, and exciting requirementsThree types of requirements: normal, expected, and exciting requirements QFD spans the entire engineering processQFD spans the entire engineering process

22. J. Nawrocki, PSP, Lecture 2 Davis’ Principles for RE Understand the problem before you begin to create the analysis modelUnderstand the problem before you begin to create the analysis model Develop prototypes showing how the human- machine interaction will occurDevelop prototypes showing how the human- machine interaction will occur Record the origin of and the reason for every requirementRecord the origin of and the reason for every requirement Use multiple views of requirements (data, functional, and behavioural)Use multiple views of requirements (data, functional, and behavioural) Prioritise requirementsPrioritise requirements Work to eliminate ambiguityWork to eliminate ambiguity

23. J. Nawrocki, PSP, Lecture 2 Viewpoints negotiation A viewpoint represents partial information

24. J. Nawrocki, PSP, Lecture 2 An example of viewpoints An example: traffic lights Prospective stakeholders (viewpoints): driversdrivers cyclistscyclists pedestrianspedestrians emergency servicesemergency services the highway authoritythe highway authority Viewpoint = perspective on a system

25. J. Nawrocki, PSP, Lecture 2 Viewpoints in RE Viewpoints: early stages of requirements elicitation Viewpoint-oriented methods: CORE (G. Mullery, 1979)CORE (G. Mullery, 1979) SADTSADT PREview (I. Sommerville, P. Sawyer, 1997)PREview (I. Sommerville, P. Sawyer, 1997)

26. J. Nawrocki, PSP, Lecture 2 Typical viewpoints The system’s stakeholders (a human, role, or organisation) The system’s operating environment (other system/component) The system’s domain (phenomena inherent in the application domain; constraints on the system)

27. J. Nawrocki, PSP, Lecture 2 Basic RE activities Requirements elicitation <= 50 zł

28. J. Nawrocki, PSP, Lecture 2 Basic RE activities for 50 zł ? Requirements analysis

29. J. Nawrocki, PSP, Lecture 2 Basic RE activities There is a conflict between your requirements.. Requirements negotiation

30. J. Nawrocki, PSP, Lecture 2 The PREview process Requirements elicitation Requirements analysis Requirements negotiation RequirementsdefinitionRequirementsdefinition

31. J. Nawrocki, PSP, Lecture 2 Local vs. global requirements Types of requirements Local requirements (specific to a particular viewpoint) Local requirements (specific to a particular viewpoint) Global requirements (likely to be most expensive to change) Global requirements (likely to be most expensive to change) Global requirements = external requirements

32. J. Nawrocki, PSP, Lecture 2 Concerns Concerns: crucial to the success non-negotiable vaguely defined concepts rather than concrete properties serve as constraints converted into external requirements A concern = a top-level, overriding goal

33. J. Nawrocki, PSP, Lecture 2 TCS: Train Control System A human driver Aim: to monitor & to intervene when safety is in danger If a train goes too fast or crosses a stopping point, TCS will apply the emergency breaks Hardware System Interface (HSI)

34. J. Nawrocki, PSP, Lecture 2 TCS: Train Control System TCS’ concerns: Safety (contribution to train safety)Safety (contribution to train safety) Compatibility with the HSI interfaceCompatibility with the HSI interface Concern question for compatibility: Is the requirement consistent with the interface provided by the HSI module ?

35. J. Nawrocki, PSP, Lecture 2 TCS: Train Control System A request: calculate a minimum breaking distance Required parameters: speed,speed, mass,mass, line gradient,line gradient, track surface conditionstrack surface conditions Question: are those values available through the HSI interface ?

36. J. Nawrocki, PSP, Lecture 2 Compatibility requirements External requirements for the ‘compatibility’ concern: ER4: The TCS software shall be executed in the Ada environment ER5: The TCS software shall execute within the application cycle of the existing on-board software ER6: The TCS software shall react to the change of state within 280 ms ER7: The real-time performance of the existing on-board software shall be maintained

37. J. Nawrocki, PSP, Lecture 2 The safety concern Hazards identification: hazard analysis techniques (fault-tree analysis, cause- consequence analysis,..) TCS’ hazards: excess speed,excess speed, overshooting a stopping pointovershooting a stopping point

38. J. Nawrocki, PSP, Lecture 2 Safety requirements ER1: The system shall detect the occurrence of excess speed ER2: The system shall detect the occurrence of overshoot ER3: The system shall apply emergency breaking when either excess speed or overshoot are detected

39. J. Nawrocki, PSP, Lecture 2 Viewpoint identification Model of organisational environment environment Model of operational environment environment DomainexpertiseDomainexpertise UserviewpointsUserviewpointsComponentviewpointsComponentviewpoints DomainviewpointsDomainviewpoints StakeholderviewpointsStakeholderviewpoints

40. J. Nawrocki, PSP, Lecture 2 TCS viewpoints Stakeholders: driverdriver maintenance technicianmaintenance technician regulator (indirect)regulator (indirect) normal operation (indirect)normal operation (indirect) safe state assurance (indirect)safe state assurance (indirect) erroneous state recovery (ind)erroneous state recovery (ind) Domain: braking characteristics Operating environment: HSI

41. J. Nawrocki, PSP, Lecture 2 Viewpoint structure NameName FocusFocus Concerns applicable to the viewpointConcerns applicable to the viewpoint Viewpoint sourcesViewpoint sources RequirementsRequirements HistoryHistory

42. J. Nawrocki, PSP, Lecture 2 Safe state assurance viewpoint Name: Safe state assurance Focus: Detection of dangerous conditions and application of emergency braking Concerns: safety, compatibility Source: customer procurement executive; TCS preliminary hazard analysis Requirements: SS1: detection of excess speed SS1: detection of excess speed SS2: detection of overshooting SS2: detection of overshooting SS3: frequency of invocation SS3: frequency of invocation

43. J. Nawrocki, PSP, Lecture 2 Requirements discovery Identifier: SS1 - detection of excess speed Description: If the speed of the train is excessive, emergency breaking shall be applied Rationale: The train must be forced to comply with the speed limits in force on the track Change history: -

44. J. Nawrocki, PSP, Lecture 2 Requirements elicitation Concern identification Concern elaboration Viewpoint identification Requirements discovery

45. J. Nawrocki, PSP, Lecture 2 Requirements analysis Safe state assurance Safe state assurance SS1 SS2 SS3 SS1 SS2 SS3 ER1: 1 0 0 ER2: 0 1 0 ER3: 1 1 0 ER4: 0 0 0 ER5: 0 0 1000 ER6: 0 0 1000 ER7: 0 0 1000 Safety Compatibility Do not effect each other Mutually reinforcing Conflict

46. J. Nawrocki, PSP, Lecture 2 Requirements definition activities 1. Identify the structure of the requirements document. Divide it into sections. 2. Identify quality standards and prepare a checklist. 3. Allocate each external requirement into one of the sections. 4. Repeat activity 3 for each viewpoint requirement. 5. Apply the checklist from activity 2 to each requirement. 6. Review each section and eliminate redundancy.

47. J. Nawrocki, PSP, Lecture 2 Further readings IEEE Guide to Software Requirements specification, ANSI/IEEE Standard 830-1984 I. Sommerville, P. Sawyer, Requirements Engineering, John Wiley & Sons, Chichester, 1997

48. J. Nawrocki, PSP, Lecture 2 Summary Requirements document The FAST method The PREview process: elicitation, analysis, negotiation At last!

49. J. Nawrocki, PSP, Lecture 2 Quality assessment What is your general impression ? (1 - 6) Was it too slow or too fast ? Did you learn something important to you ? What to improve and how ?