1. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 ECE 355: Software Engineering CHAPTER 4 Unit 3 (Part 1)

2. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2 Course outline Unit 1: Software Engineering Basics Unit 2: Process Models and Software Life Cycles  Unit 3: Software Requirements Unit 4: Unified Modeling Language (UML) Unit 5: Design Basics and Software Architecture Unit 6: OO Analysis and Design Unit 7: Design Patterns Unit 8: Testing and Reliability Unit 9: Software Engineering Management and Economics

3. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3 Course outline Software Engineering Basics Process Models  Software Requirements Unified Modeling Language (UML) Design Process OO Design Design Patterns Testing and Reliability Software Engineering Economics

4. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 Requirements Engineering a systematic approach to eliciting, organizing, and documenting the requirement of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system. (Leffingwell & Widrig 1999)

5. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 Requirements Engineering Requirements specification (the document that describes what has to be built, not how) Requirements development (the process of creating the requirements spec) Idea of a new product (to solve some problem in the real world)

6. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6 Why software projects fail?

7. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7 Communication problems...

8. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 Subareas of Requirements Engineering Requirements Engineering Requirements DevelopmentRequirements Management Elicitation - sources - techniques Analysis - req. types - modeling - negotiation Specification - spec document - templates - quality Validation - reviews - prototyping - acceptance test

9. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 Purposes of a requirements spec documents A requirements spec document is used by many different stakeholder for different purposes: –Customer - part of a formal contract –Manager - basis for the project plan –Developer - basis for the design and implementation –Tester - document to test the system against –Maintainer - starting point for understanding the system

10. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10 What is a good requirement?

11. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 Necessary properties of requirements Unambiguous –the meaning should be clear Consistent –one requirement must not contradict another Complete –E.g.: “The process is terminated if the wrong PIN has been entered more than a certain number of times.” (What is that number?) Verifiable (possible to test) –a requirement that cannot be tested is not a requirement –E.g.: “The system should work in real-time mode.” (What is “real time” here?)

12. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12 A desirable property of requirements Free of implementation bias –What vs. how –Specification vs. solution –E.g., “The system shall accept a password when data is accessed.”  This has a requirement to use password “The system shall ensure that the data can be accessed only by authorized users.”  This gives you an opportunity to search for alternatives

13. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 Content of a requirements specification Purpose of the product Stakeholders Scope of the product Requirements constraints Relevant facts Assumptions Requirements

14. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 The purpose of a product Concise statement of the business problem to be solved An example: –Your client has an electro-mechanical PBX running in his office building to provide telephone service within the building. The client is more or less happy with the system, except that when a line fails due to a fault in the PBX, it goes undetected for a very long time until some user detects the fault and reports it to the management for a fix. The management wants to replace the electro-mechanical PBX with a state-of-the-art telephone switching hardware box from ValuCom. However, ValuCom does not sell the necessary control software, and your client wants you to develop it.

15. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15 Stakeholders People and organizations interested in the product –Customers, users, regulators, developers, architects, domain experts, analysts, marketing people, sales people, management, etc. Accurately determine and describe the stakeholders They are the main sources of requirements

16. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16 Scope of the product Determines the boundaries of the work to be studied Can use a context diagram to define the scope Your work (Control S/W for PBX) PBX Hardware Adjacent system Indicate change in status Produce control signal

17. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17 Requirements constraints Global requirements having an effect on all or most of the requirements Solution Constraints –Describe any mandated design or solution constraint. (E.g.: The system must run on Unix.) –Identify partner applications. (E.g.: The product will interface with an existing module written in C.) Project Constraints –Time constraint: Must release the product at the 2004 Olympics. –Financial constraint: Indicates how elaborate the product can be.

18. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18 Relevant facts Conditions and factors that have an impact on the requirements Look for those when talking to the project stakeholders Example: The current PBX hardware supports 60 phones, whereas a newer version next year will support 200 phones and the client wants to run the same software with the new PBX.

19. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19 Assumptions Assumptions listed here are those being made by the project team If the assumptions are not satisfied, the success of the project may be endangered E.g., assumptions about performance or capacity of the hardware used, interfaces between the new and existing products

20. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20 Requirements Requirements are –the things that the product must do to achieve its purpose  functional requirements –the qualities the product must have  non-functional

21. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21 Functional requirements vs. technical requirements Think of the functional requirements as the business requirements You may introduce technical requirements during designing a solution for the functional requirements because of the technology used by your solution

22. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22 Functional vs. non-functional requirements Example: One of the functional requirements of your control software for the PBX is to automatically detect line faults. Detection of line faults is a functional requirement. Now let us say that a fault must be detected within 20 minutes. This is a performance requirement—a non- functional

23. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23 Some types of non-functional requirements Look and feel Usability Performance –speed, memory and other resources, accuracy, volumes, range of values, reliability, … Operational –e.g., The product will be used by mobile technicians. Maintainability –e.g., Readily portable to Linux. Security Cultural and political –Acceptable solutions, unacceptable solutions, political correctness, spelling, and so on.

24. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24 First Step in Establishing the Requirements: System Identification The development of a system is not just done by taking a snapshot of a scene (domain) Two questions need to be answered: –How can we identify the purpose of a system? –Crucial is the definition of the system boundary: What is inside, what is outside the system? These two questions are answered in the requirements process The requirements process consists of two activities: –Requirements Elicitation: Definition of the system in terms understood by the customer (“Problem Description”) –Requirements Analysis: Technical specification of the system in terms understood by the developer (“Problem Specification”)

25. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25 Products of Requirements Process Requirements Analysis system specification: Model analysis model: Model (Activity Diagram) Problem Statement Generation Requirements Elicitation Problem Statement

26. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26 Requirements Elicitation Very challenging activity Requires collaboration of people with different backgrounds –Users with application domain knowledge –Developer with solution domain knowledge (design knowledge, implementation knowledge) Bridging the gap between user and developer: –Scenarios: Example of the use of the system in terms of a series of interactions with between the user and the system –Use cases: Abstraction that describes a class of scenarios

27. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27 System Specification vs Analysis Model Both models focus on the requirements from the user’s view of the system System specification uses natural language (derived from the problem statement) The analysis model uses formal or semi-formal notation (for example, a graphical language like UML) The starting point is the problem statement

28. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28 Problem Statement The problem statement is developed by the client as a description of the problem addressed by the system Other words for problem statement: –Statement of Work A good problem statement describes –The current situation –The functionality the new system should support –The environment in which the system will be deployed –Deliverables expected by the client –Delivery dates –A set of acceptance criteria

29. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29 Ingredients of a Problem Statement Current situation: The Problem to be solved Scenaria: Description of one or more scenarios Requirements –Functional and Nonfunctional requirements –Constraints (“pseudo requirements”) Project Schedule –Major milestones that involve interaction with the client including deadline for delivery of the system Target environment –The environment in which the delivered system has to perform a specified set of system tests Client Acceptance Criteria –Criteria for the system tests

30. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30 Requirements Validation Requirements validation is a critical step in the development process and at delivery (client acceptance test). Requirements validation criteria: –Correctness: The requirements represent the client’s view. –Completeness: All possible scenarios, in which the system can be used, are described, including exceptional behavior by the user or the system –Consistency: There are functional or nonfunctional requirements that contradict each other –Realism: Requirements can be implemented and delivered –Traceability: Each system function can be traced to a corresponding set of functional requirements

31. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31 Requirements Validation Problem with requirements validation: Requirements change very fast during requirements elicitation. Tool support for managing requirements: –Store requirements in a shared repository –Provide multi-user access –Automatically create a system specification document from the repository –Allow change management –Provide traceability throughout the project lifecycle RequisitPro from Rational –http://www.rational.com/products/reqpro/docs/datasheet.htmlhttp://www.rational.com/products/reqpro/docs/datasheet.html

32. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32 Scenarios “A narrative description of what people do and experience as they try to make use of computer systems and applications” [M. Carrol, Scenario-based Design, Wiley, 1995] A concrete, focused, informal description of a single feature of the system used by a single actor. Scenarios can have many different uses during the software lifecycle –Requirements Elicitation: As-is scenario, visionary scenario –Client Acceptance Test: Evaluation scenario –System Deployment: Training scenario.

33. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33 Types of Scenarios As-is scenario: –Used in describing a current situation. Usually used in re- engineering projects. The user describes the system. Example: Description of Letter-Chess Visionary scenario: –Used to describe a future system. Usually used in greenfield engineering and reengineering projects. –Can often not be done by the user or developer alone Example: Description of an interactive internet-based Tic Tac Toe game tournament. Evaluation scenario: –User tasks against which the system is to be evaluated. Example: Four users (two novice, two experts) play in a TicTac Toe tournament in ARENA. Training scenario: –Step by step instructions that guide a novice user through a system Example: How to play Tic Tac Toe in the ARENA Game Framework.

34. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34 How do we find scenarios? Don’t expect the client to be verbal if the system does not exist (greenfield engineering) Don’t wait for information even if the system exists Engage in a dialectic approach (evolutionary, incremental engineering) –You help the client to formulate the requirements –The client helps you to understand the requirements –The requirements evolve while the scenarios are being developed

35. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35 Heuristics for finding Scenarios Ask yourself or the client the following questions: –What are the primary tasks that the system needs to perform? –What data will the actor create, store, change, remove or add in the system? –What external changes does the system need to know about? –What changes or events will the actor of the system need to be informed about? However, don’t rely on questionnaires alone. Insist on task observation if the system already exists (interface engineering or reengineering) –Ask to speak to the end user, not just to the software contractor –Expect resistance and try to overcome it

36. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36 Scenario Example: Warehouse on Fire Bob, driving down main street in his patrol car notices smoke coming out of a warehouse. His partner, Alice, reports the emergency from her car. Alice enters the address of the building, a brief description of its location (i.e., north west corner), and an emergency level. In addition to a fire unit, she requests several paramedic units on the scene given that area appear to be relatively busy. She confirms her input and waits for an acknowledgment. John, the Dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He allocates a fire unit and two paramedic units to the Incident site and sends their estimated arrival time (ETA) to Alice. Alice received the acknowledgment and the ETA.

37. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37 Observations about Warehouse on Fire Scenario Concrete scenario –Describes a single instance of reporting a fire incident. –Does not describe all possible situations in which a fire can be reported. Participating actors –Bob, Alice and John