ECE 355 Software Engineering CHAPTER 4 Unit 3

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

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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) Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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

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

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

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

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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

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? ) Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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

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 Valu. Com. However, Valu. Com does not sell the necessary control software, and your client wants you to develop it. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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) Indicate change in status Produce control signal PBX Hardware Adjacent system Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 nonfunctional Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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”) Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 • Requisit. Pro from Rational – http: //www. rational. com/products/reqpro/docs/datasheet. html Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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. Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

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 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java