1. 1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100 College Dr., North Bay, ON P1B 8L7, Canada, haibinz@nipissingu.ca, http://www.nipissingu.ca/faculty/haibinz haibinz@nipissingu.ca

2. 2 Lecture 5 Requirement Engineering Ref. Chap. 7

3. What are requirements? Requirements are defined during the early stages of a system development as a specification of what should be implemented or as a constraint of some kind on the system. Requirements are defined during the early stages of a system development as a specification of what should be implemented or as a constraint of some kind on the system. They may be: They may be: a user-level facility description, a user-level facility description, a detailed specification of expected system behaviour, a detailed specification of expected system behaviour, a general system property, a general system property, a specific constraint on the system, a specific constraint on the system, information on how to carry out some computation, information on how to carry out some computation, a constraint on the development of the system. a constraint on the development of the system. 3

4. What is requirements engineering? Requirements engineering covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer- based system. Requirements engineering covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer- based system. The use of the term ‘engineering’ implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent, relevant, etc. The use of the term ‘engineering’ implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent, relevant, etc. 4

5. What happens if the requirements are wrong? The system may be delivered late and cost more than originally expected. The system may be delivered late and cost more than originally expected. The customer and end-users are not satisfied with the system. They may not use its facilities or may even decide to scrap it altogether. The customer and end-users are not satisfied with the system. They may not use its facilities or may even decide to scrap it altogether. The system may be unreliable in use with regular system errors and crashes disrupting normal operation. The system may be unreliable in use with regular system errors and crashes disrupting normal operation. If the system continues in use, the costs of maintaining and evolving the system are very high. If the system continues in use, the costs of maintaining and evolving the system are very high. 5

6. Why is requirements engineering difficult? Businesses operate in a rapidly changing environment so their requirements for system support are constantly changing. Businesses operate in a rapidly changing environment so their requirements for system support are constantly changing. Multiple stakeholders with different goals and priorities are involved in the requirements engineering process. Multiple stakeholders with different goals and priorities are involved in the requirements engineering process. System stakeholders do not have clear ideas about the system support that they need. System stakeholders do not have clear ideas about the system support that they need. Requirements are often influenced by political and organisational factors that stakeholders will not admit to publicly. Requirements are often influenced by political and organisational factors that stakeholders will not admit to publicly. 6

7. 7 Requirements Engineering-I Inception—ask a set of questions that establish … Inception—ask a set of questions that establish … basic understanding of the problem basic understanding of the problem the people who want a solution the people who want a solution the nature of the solution that is desired, and the nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration between the customer and the developer the effectiveness of preliminary communication and collaboration between the customer and the developer Elicitation—elicit requirements from all stakeholders Elicitation—elicit requirements from all stakeholders Problem of Scope: ill-defined system boundary Problem of Scope: ill-defined system boundary Problem of understanding: misunderstanding Problem of understanding: misunderstanding Problem of volatility: changing Problem of volatility: changing Elaboration—create an analysis model that identifies data, function and behavioral requirements Elaboration—create an analysis model that identifies data, function and behavioral requirements Negotiation—agree on a deliverable system that is realistic for developers and customers Negotiation—agree on a deliverable system that is realistic for developers and customers

8. 8 Requirements Engineering-II Specification—can be any one (or more) of the following: Specification—can be any one (or more) of the following: A written document A written document A set of models A set of models A formal mathematical A formal mathematical A collection of user scenarios (use-cases) A collection of user scenarios (use-cases) A prototype A prototype Validation—a review mechanism that looks for Validation—a review mechanism that looks for errors in content or interpretation errors in content or interpretation areas where clarification may be required areas where clarification may be required missing information missing information inconsistencies (a major problem when large products or systems are engineered) inconsistencies (a major problem when large products or systems are engineered) conflicting or unrealistic (unachievable) requirements. conflicting or unrealistic (unachievable) requirements. Requirements management Requirements management A set of activities that help the project team identify, control, and track requirements and changes to the requirements. A set of activities that help the project team identify, control, and track requirements and changes to the requirements. Traceability tables: source, dependency, subsystem, interface Traceability tables: source, dependency, subsystem, interface

9. 9 Inception Identify stakeholders: anyone who benefits in a direct or indirect way from the system which is being developed. Identify stakeholders: anyone who benefits in a direct or indirect way from the system which is being developed. “who else do you think I should talk to?” “who else do you think I should talk to?” Recognize multiple points of view Recognize multiple points of view Work toward collaboration Work toward collaboration The first questions The first questions Who is behind the request for this work? Who is behind the request for this work? Who will use the solution? Who will use the solution? What will be the economic benefit of a successful solution? What will be the economic benefit of a successful solution? Is there another source for the solution that you need? Is there another source for the solution that you need?

10. 10 Eliciting Requirements meetings are conducted and attended by both software engineers and customers meetings are conducted and attended by both software engineers and customers rules for preparation and participation are established rules for preparation and participation are established an agenda is suggested an agenda is suggested a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used the goal is the goal is to identify the problem to identify the problem propose elements of the solution propose elements of the solution negotiate different approaches, and negotiate different approaches, and specify a preliminary set of solution requirements specify a preliminary set of solution requirements

11. 11 Eliciting Requirements QFD: Quality Function Deployment

12. 12 Quality Function Deployment QFD translates the needs of the customers into technical requirements for software. It concentrates on maximizing customer satisfaction from the software engineering process. QFD translates the needs of the customers into technical requirements for software. It concentrates on maximizing customer satisfaction from the software engineering process. 3 types of requirements 3 types of requirements Normal Normal Expected Expected Exciting Exciting 4 types of deployments 4 types of deployments Function deployment determines the “value” (as perceived by the customer) of each function required of the system Function deployment determines the “value” (as perceived by the customer) of each function required of the system Information deployment identifies data objects and events Information deployment identifies data objects and events Task deployment examines the behavior of the system Task deployment examines the behavior of the system Value analysis determines the relative priority of requirements Value analysis determines the relative priority of requirements

13. 13 Elicitation Work Products a statement of need and feasibility. a statement of need and feasibility. a bounded statement of scope for the system or product. a bounded statement of scope for the system or product. a list of customers, users, and other stakeholders who participated in requirements elicitation a list of customers, users, and other stakeholders who participated in requirements elicitation a description of the system’s technical environment. a description of the system’s technical environment. a list of requirements (preferably organized by function) and the domain constraints that apply to each. a list of requirements (preferably organized by function) and the domain constraints that apply to each. a set of usage scenarios that provide insight into the use of the system or product under different operating conditions. a set of usage scenarios that provide insight into the use of the system or product under different operating conditions. any prototypesdeveloped to better define requirements any prototypes developed to better define requirements.

14. Requirements change System requirements reflect the world outside of the system. As this is constantly changing then the requirements will inevitably also change System requirements reflect the world outside of the system. As this is constantly changing then the requirements will inevitably also change Technology changes Technology changes Organisational changes Organisational changes Market changes Market changes Economic changes Economic changes Political and legal changes Political and legal changes It is often difficult to understand the implications of changes for the requirements as a whole It is often difficult to understand the implications of changes for the requirements as a whole 14

15. 15Use-Cases A collection of user scenarios that describe the thread of usage of a system A collection of user scenarios that describe the thread of usage of a system Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way Scenarios are descriptions of typical ways that a particular end user task might be carried out. By understanding what is done then requirements for computer support can be developed Scenarios are descriptions of typical ways that a particular end user task might be carried out. By understanding what is done then requirements for computer support can be developed Applicability Applicability They are primarily useful during requirements elicitation They are primarily useful during requirements elicitation Maturity Maturity This approach to requirements elicitation is becoming increasingly widely used. Use-cases in the UML process are closely related to scenarios This approach to requirements elicitation is becoming increasingly widely used. Use-cases in the UML process are closely related to scenarios Problems Problems Time consuming to develop scenarios Time consuming to develop scenarios Focused on end-user stakeholders Focused on end-user stakeholders

16. Questions for A Scenario Who is the primary actor, the secondary actor (s)? Who is the primary actor, the secondary actor (s)? What are the actor’s goals? What are the actor’s goals? What preconditions should exist before the story begins? What preconditions should exist before the story begins? What main tasks or functions are performed by the actor? What main tasks or functions are performed by the actor? What extensions might be considered as the story is described? What extensions might be considered as the story is described? What variations in the actor’s interaction are possible? What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external environment? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes? Does the actor wish to be informed about unexpected changes? 16

17. 17 Use-Case template Use-case: Use-case: Primary actor: Primary actor: Goal in context: Goal in context: Preconditions: Preconditions: Trigger: Trigger: Scenario: Scenario: Exceptions: Exceptions: Priority: Priority: When available: When available: Frequency of use: Frequency of use: Channel to actor: Channel to actor: Secondary actors: Secondary actors: Open issues: Open issues:

18. 18 Use-Case Diagram http://www.math- cs.gordon.edu/courses/cs211/AT MExample/UseCases.html#Start up http://www.andrew.cmu.edu/cou rse/90-754/umlucdfaq.html

19. 19 Building the Analysis Model Elements of the analysis model Elements of the analysis model Scenario-based elements Scenario-based elements Functional—processing narratives for software functions Functional—processing narratives for software functions Use-case—descriptions of the interaction between an “actor” and the system Use-case—descriptions of the interaction between an “actor” and the system Class-based elements Class-based elements Implied by scenarios Implied by scenarios Behavioral elements Behavioral elements State diagram State diagram Flow-oriented elements Flow-oriented elements Data flow diagram Data flow diagram

20. 20 Class Diagram From the SafeHome system …

21. 21 State Diagram

22. 22 Analysis Patterns Pattern name: A descriptor that captures the essence of the pattern.Pattern name: A descriptor that captures the essence of the pattern. Intent: Describes what the pattern accomplishes or representsIntent: Describes what the pattern accomplishes or represents Motivation: A scenario that illustrates how the pattern can be used to address the problem.Motivation: A scenario that illustrates how the pattern can be used to address the problem. Forces and context: A description of external issues (forces) that can affect how the pattern is used and also the external issues that will be resolved when the pattern is applied.Forces and context: A description of external issues (forces) that can affect how the pattern is used and also the external issues that will be resolved when the pattern is applied. Solution: A description of how the pattern is applied to solve the problem with an emphasis on structural and behavioral issues.Solution: A description of how the pattern is applied to solve the problem with an emphasis on structural and behavioral issues. Consequences: Addresses what happens when the pattern is applied and what trade-offs exist during its application.Consequences: Addresses what happens when the pattern is applied and what trade-offs exist during its application. Design: Discusses how the analysis pattern can be achieved through the use of known design patterns.Design: Discusses how the analysis pattern can be achieved through the use of known design patterns. Known uses: Examples of uses within actual systems.Known uses: Examples of uses within actual systems. Related patterns: On e or more analysis patterns that are related to the named pattern because (1) it is commonly used with the named pattern; (2) it is structurally similar to the named pattern; (3) it is a variation of the named pattern.Related patterns: On e or more analysis patterns that are related to the named pattern because (1) it is commonly used with the named pattern; (2) it is structurally similar to the named pattern; (3) it is a variation of the named pattern.

23. 23 Negotiating Requirements Identify the key stakeholders Identify the key stakeholders These are the people who will be involved in the negotiation These are the people who will be involved in the negotiation Determine each of the stakeholders “win conditions” Determine each of the stakeholders “win conditions” Win conditions are not always obvious Win conditions are not always obvious Negotiate Negotiate Work toward a set of requirements that lead to “win-win” Work toward a set of requirements that lead to “win-win”

24. 24 Requirement Specification: C- vs D-Requirements SRS (IEEE) 1. Introduction 2. Overall description 3. Specific requirements 4. Supporting information C- requirements D- requirements

25. 25 To Be Performed With Each Requirement Each requirement must be …  expressed properly,  made easily accessible,  numbered,  accompanied by tests that verify it,  provided for in the design,  accounted for by code,  tested in isolation,  tested in concert with other requirements, and  validated by testing after the application has been built.

26. 26 Typical RoadMap for Customer (“C-”) Requirements 1. Identify “the customer” 2. Interview customer representatives identify wants and needs exploit tools for expression sketch GUI’s identify hardware 3. Write C-requirements in standard document form Review with customer

27. 27 For all stages,track metrics, e.g., time spent quantity accomplished pages of C-requirements mins. of customer interaction per pg. self-assessed quality (1-10 scale) defect rates from inspections Typical RoadMap for Customer (“C-”) Requirements 1. Identify “the customer” 2. Interview customer representatives identify wants and needs exploit tools for expression sketch GUI’s identify hardware 3. Write C-requirements in standard document form 4. Inspect C-requirements 5. Build D-requirements On customer approval... Review with customer

28. 28 IEEE 830-1993 SRS Table of Contents 1. Introduction 1.1.Purpose 1.2.Scope 1.3.Definitions, acronyms & abbreviations 1.4.References 1.5.Overview 2. Overall description 2.1.Product perspective 2.1.1. System interfaces 2.1.2. User interfaces 2.1.3. Hardware interfaces 2.1.4. Software interfaces 2.1.5. Communications interfaces SRS: Software Requirements Specification

29. 29 IEEE 830-1993 SRS Table of Contents 1. Introduction 1.1.Purpose 1.2.Scope 1.3.Definitions, acronyms & abbreviations 1.4.References 1.5.Overview 2. Overall description 2.1.Product perspective 2.1.1. System interfaces 2.1.2. User interfaces 2.1.3. Hardware interfaces 2.1.4. Software interfaces 2.1.5. Communications interfaces 2.1.6. Memory constraints 2.1.7. Operations 2.1.8. Site adaptation requirements 2.2.Product functions 2.3.User characteristics 2.4.Constraints 2.5.Assumptions and dependencies 2.6.Apportioning of requirements 3. Specific requirements 4. Supporting information

30. 30 Validating Requirements-I Is each requirement consistent with the overall objective for the system/product? Is each requirement consistent with the overall objective for the system/product? Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? Is each requirement bounded and unambiguous? Is each requirement bounded and unambiguous? Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? Do any requirements conflict with other requirements? Do any requirements conflict with other requirements?

31. 31 Validating Requirements-II Is each requirement achievable in the technical environment that will house the system or product? Is each requirement achievable in the technical environment that will house the system or product? Is each requirement testable, once implemented? Is each requirement testable, once implemented? Does the requirements model properly reflect the information, function and behavior of the system to be built. Does the requirements model properly reflect the information, function and behavior of the system to be built. Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system. Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system. Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements? Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements?

32. Requirement Management Features traceability table Features traceability table Source traceability table Source traceability table Dependency traceability table Dependency traceability table Subsystem traceability table Subsystem traceability table Interface traceability table Interface traceability table 32

33. 33 Summary The tasks of requirement engineering The tasks of requirement engineering Inception Inception Elicitation Elicitation Developing use-cases Developing use-cases Elaboration Elaboration Building analysis model Building analysis model Negotiation Negotiation Specification Specification IEEE SRS (C-requirements and D-requirements) IEEE SRS (C-requirements and D-requirements) Validation Validation Management Management