Lecture 5 André van der Hoek Todays Lecture Requirements engineering Requirements specification Recurring Fundamental Principles Rigor and formality Separation of concerns Modularity ID: 431467
Download Presentation The PPT/PDF document "Introduction to Software Engineering" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Introduction to Software EngineeringLecture 5
André
van der
HoekSlide2
Today’s Lecture
Requirements engineering
Requirements specificationSlide3
Recurring, Fundamental Principles
Rigor and formality
Separation of concerns
Modularity
Abstraction
Anticipation of changeGeneralityIncrementality
These principles apply to all aspects of software engineeringSlide4
ICS 52 Life Cycle
Requirements
phase
Verify
Design
phase
Verify
Implementation
phase
Test
Testing
phase
VerifySlide5
Requirements Phase
Terminology
Requirements analysis/engineering
Activity
of unearthing a customer’s needs
Requirements specificationDocument
describing a customer’s needs
Note: requirements address what a customer
needs
, not what a customer wantsA customer often does not know what they want, let alone what they needTime-lag between initial desire and future need
Long and arduous, often educational, processSlide6
Requirements Analysis
System engineering versus software engineering
What role does software play within the full solution?
Trend: software is everywhere
Contract
model versus participatory designContract: carefully specify requirements, then contract out the development
Participatory: customers, users, and software development staff work together throughout the life cycleSlide7
Techniques for Requirements Analysis
Interview customer
Create use cases/scenarios
Prototype solutions
Observe customer
Identify important objects/roles/functionsPerform researchConstruct glossaries
Question yourself
Use the principlesSlide8
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 qualitiesSlide9
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 cheapBetter make them now rather than laterSlide10
Users of a Requirements DocumentSlide11
Non-Functional Requirement TypesSlide12
Structure
Introduction
Executive summary
Application context
Functional requirements
Environmental requirementsSoftware qualitiesOther requirements
Time schedule
Potential risks
Future changes
GlossaryReference documentsSlide13
Introduction
What is this document about?
Who was it created for?
Who created it?
OutlineSlide14
Executive Summary
Short, succinct, concise, to-the-point, description
Usually no more than one page
Identifies main goals
Identifies key features
Identifies key risks/obstaclesSlide15
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 assumptionsSlide16
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 requirementsSlide17
Environmental Requirements
Platforms
Hardware
Operating systems, types of machines, memory size, hard disk space
Software
CORBA, Jini, DCOM, 4GL, …Programming language(s)StandardsSlide18
Software Qualities
Correctness
Reliability
Efficiency
Integrity
UsabilityMaintainability
Testability
Flexibility
Portability
Reusability
InteroperabilitySlide19
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?Slide20
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 completedModule design completed
Implementation completed
Testing completedSlide21
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 risksSlide22
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…Slide23
Glossary
Precise definitions of terms used throughout the requirements documentSlide24
Reference Documents
Pointers to existing processes and tools used within an organization
Pointers to other, existing software that
provides
similar functionality
Pointers to literatureSlide25
Structure
Introduction
Executive summary
Application context
Functional requirements
Environmental requirementsSoftware qualitiesOther requirements
Time schedule
Potential risks
Future changes
GlossaryReference documentsSlide26
Observations
Document is structured to address the fundamental principles
Rigor
Separation of concerns
Modularity
AbstractionAnticipation of changeGenerality
Incrementality
Not every project requires every section of the documentSlide27
Specification Methods
Natural language
Data flow diagrams
Office automation
Finite state machines
Telephone systemsCoin-operated machinesPetri nets
Production plants
Formulas
Matrix inversion package
Objects (in object-oriented methods)Use cases (in UML)Slide28
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?Slide29
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 specificationSlide30
V-Model of Development and Testing
Develop Acceptance Tests
Acceptance Test Review
Requirements Review
Develop Requirements
Execute System Tests
Develop Integration Tests
Integration Tests Review
Design Review
Design
Execute Integration Tests
Develop Unit Tests
Unit Tests Review
Code Review
Code
Execute Unit TestsSlide31
Example
French fries
and mayonnaise
placeSlide32
Your Tasks
Read and study slides of this lecture
Read
Chapter
9 of van
Vliet
Note: discussion starts Friday