Introduction to Software Engineering Lecture 5 André van der Hoek

Today’s Lecture Requirements engineering Requirements specification

Recurring, Fundamental Principles Rigor and formality Separation of concerns Modularity Abstraction Anticipation of change Generality Incrementality These principles apply to all aspects of software engineering

ICS 52 Life Cycle Requirements phase Verify Design phase Verify Implementation phase Test Testing phase Verify

Requirements Phase Terminology Requirements analysis/engineering Activity of unearthing a customer’s needs Requirements specification Document describing a customer’s needs Note: requirements address what a customer needs, not what a customer wants A customer often does not know what they want, let alone what they need Time-lag between initial desire and future need Long and arduous, often educational, process

Requirements Analysis System engineering versus software engineering What role does software play within the full solution? Trend: software is everywhere Contract model versus participatory design Contract: carefully specify requirements, then contract out the development Participatory: customers, users, and software development staff work together throughout the life cycle

Techniques for Requirements Analysis Interview customer Create use cases/scenarios Prototype solutions Observe customer Identify important objects/roles/functions Perform research Construct glossaries Question yourself Use the principles

Requirements Specification Serves as the fundamental reference point between customer and software producer Defines capabilities to be provided without saying how they should be provided Defines the “what” Does not define the “how” Defines environmental requirements on the software to guide the implementers Platforms, implementation language(s), … Defines constraints on the software Performance, usability, … Defines software qualities

Why Spend a Lot of Time? A requirements specification is the source for all future steps in the software life cycle Lays the basis for a mutual understanding Consumer (what they get) Software producer (what they build) Identifies fundamental assumptions Potential basis for future contracts Better get it right Upon delivery, some software is actually rejected by customers Changes are cheap Better make them now rather than later

Users of a Requirements Document

Non-Functional Requirement Types

Structure Introduction Executive summary Application context Functional requirements Environmental requirements Software qualities Other requirements Time schedule Potential risks Future changes Glossary Reference documents

Introduction What is this document about? Who was it created for? Who created it? Outline

Executive Summary Short, succinct, concise, to-the-point, description Usually no more than one page Identifies main goals Identifies key features Identifies key risks/obstacles

Application Context Describes the situation in which the software will be used How will the situation change as a result of introducing the software? “World Model” Identifies all things that the system affects Objects, processes, other software, hardware, and people Provides an abstraction for each of those, characterizing the properties and behaviors that are relevant to the software system Identifies fundamental assumptions

Functional Requirements Identifies all concepts, functions, features, and information that the system provides to its users Provides an abstraction for each of those, characterizing the properties and functions that are relevant to the user What is the system supposed to do? What information does the system need? What is supposed to happen when something goes wrong? An approximate user interface is part of functional requirements

Environmental Requirements Platforms Hardware Operating systems, types of machines, memory size, hard disk space Software CORBA, Jini, DCOM, 4GL, … Programming language(s) Standards

Software Qualities Correctness Reliability Efficiency Integrity Usability Maintainability Testability Flexibility Portability Reusability Interoperability

Other Requirements What about cost? What about documentation? What about manuals? What about tutorials? What about on-the-job training? What about requirements that do not fit in any of the previous categories?

Time Schedule By when should all of this be done? Initial delivery date Acceptance period Final delivery date What are some important milestones to be reached? Architectural design completed Module design completed Implementation completed Testing completed

Potential Risks Any project faces risks Boehm’s top ten risks (see lecture 3) It is important to identify those risks up-front so the customer and you (!) are aware of them One of the requirements could be to explicitly address the risks

Future Changes Any project faces changes over time It is important to identify those changes up-front so the customer and you (!) are aware of them These changes could simply pertain to potential future enhancements to the product One of the requirements could be to build the product such that it can accommodate future changes Note: structure the requirements document in such a way that it easily absorbs changes Define concepts once Partition separate concerns …

Glossary Precise definitions of terms used throughout the requirements document

Reference Documents Pointers to existing processes and tools used within an organization Pointers to other, existing software that provides similar functionality Pointers to literature

Structure Introduction Executive summary Application context Functional requirements Environmental requirements Software qualities Other requirements Time schedule Potential risks Future changes Glossary Reference documents

Observations Document is structured to address the fundamental principles Rigor Separation of concerns Modularity Abstraction Anticipation of change Generality Incrementality Not every project requires every section of the document

Specification Methods Natural language Data flow diagrams Office automation Finite state machines Telephone systems Coin-operated machines Petri nets Production plants Formulas Matrix inversion package Objects (in object-oriented methods) Use cases (in UML)

Verification Is the requirements specification complete? Is each of the requirements understandable? Is each of the requirements unambiguous? Are any of the requirements in conflict? Can each of the requirements be verified? Are are all terms and concepts defined? Is the requirements specification unbiased?

Acceptance Test Plan Accompanies a requirements specification Specifies, in an operational way, consistency between the requirements specification and the system that will be delivered Binds a customer to accept the delivered system if it passes all the tests Covers all aspects of the requirements specification

V-Model of Development and Testing Develop Acceptance Tests Acceptance Test ReviewRequirements Review Develop RequirementsExecute System TestsDevelop Integration Tests Integration Tests ReviewDesign Review DesignExecute Integration TestsDevelop Unit Tests Unit Tests ReviewCode Review CodeExecute Unit Tests

Example French fries and mayonnaise place

Your Tasks 1. Read and study slides of this lecture 2. Read Chapter 9 of van Vliet 3. Note: discussion starts Friday