Informatics 43
October 1, 2015
Lecture 1-2
Emily Navarro
Duplication of course material for any commercial purpose without the explicit written
permission of the professor is prohibited.
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 1
Today’s Lecture
• Software failures
• Why requirements?
• Requirements engineering
– Requirements phase
– Requirements analysis
– Requirements specification (documentation)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 2
Today’s Lecture
• Software failures
• Why requirements?
• Requirements engineering
– Requirements phase
– Requirements analysis
– Requirements specification (documentation)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 3
Why did the CA payroll system and DWP
billing system upgrades fail?
A. The task was too large and complex.
B. State/city gov’t is less efficient than the private
sector.
C. State/city rules require inadequate programming
languages to be used.
D. The contractor, SAP Public
Services/PricewaterhouseCoopers, has a flawed
management structure.
E. No one on the software team took Info 43.
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 4
Why did the CA payroll system and DWP
billing system upgrades fail?
A. The task was too large and complex.
B. State/city gov’t is less efficient than the private
sector.
C. State/city rules require inadequate programming
languages to be used.
D. The software contractor, SAP Public
Services/PricewaterhouseCoopers, has a flawed
management structure.
E. No one on the software team took Info 43.
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 5
What is the real problem?
• The task is incredibly complex:
• Payroll system: 160 state departments,
40+ medical/dental plans, $100 millions
in costs.
• DWP: 3.8 million customers
• Software must conform to the reality of
payroll contracts, laws,
billing policies.
• Progress is hard to measure.
• Part of the goal is to update
systems in place since
the 1970s.
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 6
Today’s Lecture
• Software failures
• Why requirements?
• Requirements engineering
– Requirements phase
– Requirements analysis
– Requirements specification (documentation)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 7
Shopa Failure
“The company, in a lot of ways, is still trying to figure out what product to build.
This leads to massive amount of anxiety and ambiguity as no one knows inside
the company what they are building. - There is a lot of unspoken strife between
the technical implementation and sales teams - Engineers and Sales team running
around as headless chickens.”
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 8
Reminder: Top Software Failure Causes
•
•
•
•
•
•
SDCL
Lack of user input/involvement
Incomplete requirements and specifications
Changing requirements and specifications
Lack of discipline in development processes
Lack of methodical usage of metrics
Lack of resources
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 9
Reminder: Top Software Failure Causes
•
•
•
•
•
•
Lack of user input/involvement
Incomplete requirements and specifications
Changing requirements and specifications
Lack of discipline in development processes
Lack of methodical usage of metrics
Lack of resources
Lack of rigor/formality
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 10
Reminder: Top Software Failure Causes
•
•
•
•
•
•
SDCL
Lack of user input/involvement
Incomplete requirements and specifications
Changing requirements and specifications
Lack of discipline in development processes
Lack of methodical usage of metrics
Requirements issues
Lack of resources
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 11
Definition
Requirements =
what the software should do (without saying
how it should do it)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 12
Why Requirements?
• “[We] have grown to care about requirements because we
have seen more projects stumble or fail as a result of poor
requirements than for any other reason”
– (Kulak and Guiney, in “Use Cases: Requirements in Context”)
• Studies show that many of the key contributors to project
failures originate or relate to requirements
– (The Standish Group CHAOS reports)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 13
Some stats…
• From those CHAOS reports
• 31% of projects cancelled before they are even completed
– Many others not delivered or not used (“shelfware”) even if completed
– Many billions wasted per year on cancelled, unused or unusable
projects
– 52.7% of projects were more than 189% over budget when delivered
• Requirements defects are expensive
– They represent more than 70% of rework costs
– Rework consumes about 30-50% of total project budget
– Lack of user input/user involvement listed as most frequent problem
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 14
More Stats: Software Life Cycle Costs
Analysis
2%
Specification
5%
Design
6%
Maintenance
67%
Module Coding
5%
Module Testing
7%
Integration
8%
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 15
More Stats: Cost of Change Progressively Higher
200
180
160
140
120
100
80
60
40
20
0
Analysis
SDCL
Software Design and
Collaboration Laboratory
Specification
Design
Implementation
Department of Informatics, UC Irvine
Integration
Maintenance
sdcl.ics.uci.edu 16
Today’s Lecture
• Software failures
• Why requirements?
• Requirements engineering
– Requirements phase
– Requirements analysis
– Requirements specification (documentation)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 17
Waterfall
Req analysis
phase
Verify
Changed
requirements
Verify
Req specification
phase
Verify
Design
phase
Verify
Implementation
phase
Test
Development
Maintenance
Integration
phase
Test
Operations mode
Retirement
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 18
Waterfall
Req analysis
phase
Verify
Changed
requirements
Verify
Req specification
phase
Verify
Design
phase
Verify
Implementation
phase
Test
Development
Maintenance
Integration
phase
Test
Operations mode
Retirement
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 19
The RUP Model
Phases
Process Workflows
Inception
Elaboration
Construction
Business Modeling
In an iteration,
you walk
Transition all
through
workflows
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Workflows
group
activities
logically
SDCL
Software Design and
Collaboration Laboratory
Environment
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1
Iterations
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 20
Requirements Phase
• Terminology
– Requirements analysis/engineering
• Activity of discovering/observing/gathering customer’s needs
– Requirements specification
• Activity of describing/documenting 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 actually need…
– Long and arduous, often educational, process
• And things change “under our feet” during the requirements process...
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 21
Today’s Lecture
• Software failures
• Why requirements?
• Requirements engineering
– Requirements phase
– Requirements analysis
– Requirements specification (documentation)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 22
Techniques for Requirements Analysis
•
•
•
•
•
•
•
•
•
SDCL
Interview customer
Create use cases/scenarios
Prototype solutions
Observe customer
Identify important objects/roles/functions
Perform research
Construct glossaries
…
(Data)
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 23
Today’s Lecture
• Software failures
• Why requirements?
• Requirements engineering
– Requirements phase
– Requirements analysis
– Requirements specification (documentation)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 24
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
– Standards, hardware limitations, …
• Defines software qualities
– maintainability, usability, verifiability
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 25
Non-Functional Requirement Types
Non-functional
requir ements
Product
requir ements
Ef ficiency
requir ements
Reliability
requir ements
Usability
requirements
Performance
requirements
SDCL
Or ganizational
requir ements
Portability
requirements
Delivery
requirements
Interoperability
requirements
Implementation
requir ements
Space
requir ements
Software Design and
Collaboration Laboratory
External
requirements
Department of Informatics, UC Irvine
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements
sdcl.ics.uci.edu 26
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
• Better get it right
– Upon delivery, some software is actually rejected by customers
• Changes are cheap
– Better make them now rather than later
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 27
Users of a Requirements Document
SDCL
System customers
Specify the requirements and
read them to check that they
meet their needs. They
specify changes to the
requirements
Managers
Use the requirements
document to plan a bid for
the system and to plan the
system development process
System engineers
Use the requirements to
understand what system is to
be developed
System test
engineers
Use the requirements to
develop validation tests for
the system
System
maintenance
engineers
Use the requirements to help
understand the system and
the relationships between its
parts
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 28
Document Structure
•
•
•
•
•
•
•
•
•
•
•
•
•
SDCL
Introduction
Executive summary
Application context
Environmental requirements
Functional requirements
Software qualities
Other requirements
Time schedule
Potential risks
Assumptions
Future changes
Glossary
Reference documents
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 29
Introduction
•
•
•
•
SDCL
What is this document about?
Who was it created for?
Who created it?
Outline
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 30
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
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 31
Application Context
• Describes the situation in which the software will be used
– Home, office, inside, outside, …
• Identifies all things that the system affects
– Objects, processes, other software, hardware, and people
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 32
Environmental Requirements
• Platforms
– Hardware
• Operating systems, types of machines, memory size, hard disk space
– Software
• Is it a Web app? Mobile app? Desktop app?
• Is it open source? Linux? Apache? PHP/MySQL?
• Is it enterprise software? .Net? Enterprise Java, J2EE?
• Programming language(s)
• Standards
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 33
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?
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 34
Desired Software “ilities” (Qualities)
•
•
•
•
•
•
Correctness
Reliability
Efficiency
Integrity
Usability
Maintainability
•
•
•
•
•
•
Portability
Reusability
Interoperability
Robustness
Security
…
This section helps developers assess tradeoffs
in the system’s implementation
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 35
Other Requirements
•
•
•
•
•
•
SDCL
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?
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 36
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?
–
–
–
–
SDCL
Architectural design completed
Module design completed
Implementation completed
Testing completed
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 37
Potential Risks
• Risks: “future uncertain events with a probability of
occurrence and a potential for loss”
(softwaretestinghelp.com)
• Any project faces risks
–
–
–
–
–
new methodology
requirements new to the group
special skills and resource shortage
aggressive schedule
tight funding
• 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
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 38
Assumptions
• Factors that are believed to be true during the life cycle of the
project
• If changed, they may affect the project outcomes negatively
• Examples
–
–
–
–
SDCL
end-user characteristics
known technology infrastructure
resource availability
funding availability
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 39
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
–
–
–
–
SDCL
Define concepts once
Partition separate concerns
Avoid redundancy
…
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 40
Glossary
• Precise definitions of terms used throughout the
requirements document
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 41
Reference Documents
• Pointers to existing processes and tools used within an
organization
• Pointers to other, existing software that provides similar
functionality
• Pointers to literature
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 42
Observations
• Document is structured to address the fundamental
principles
– Rigor
– Separation of concerns
• Modularity
• Abstraction
– Anticipation of change
– Generality
– Incrementality
These principles apply to all
aspects of software
engineering
• Not every project requires every section of the document
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 43
Specification Methods
• Natural language
• Data flow diagrams
– Office automation
• Finite state machines
– Telephone systems
– Coin-operated machines
• Petri nets
– Production plants
• Formulas
• Objects (in object-oriented methods)
• Use cases (in UML)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 44
Verification
•
•
•
•
•
•
•
SDCL
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?
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 45
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
• May include:
– some specific test cases
– the number of test cases that must pass
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 46
Videos
• Requirements gathering 1:
https://www.youtube.com/watch?v=l_GTTyE9i9Y
• Requirements gathering 2:
https://www.youtube.com/watch?v=lXNu0VBVCUc
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 47
Quiz – Tuesday, October 6
•
•
•
•
Closed book, no notes, calculators, phones…
Covers all readings and lectures through Thursday 10/1 (today)
No scantrons, no blue books
How to study:
– Different from other CS courses
• Software engineering as much about people as it is about software
• Shifts away from technical thinking of a CS student
• Many ways to analyze topics, especially definitions, links between different
concepts
– Attend lecture, take notes, spend time going over them carefully,
analyzing, discussing
– Do readings carefully, take notes, analyze, and discuss
– Focus more on high-level understanding of main points than details of
concepts
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 48
Quiz – Tuesday, October 6 - Topics
• Memorize one definition of software engineering (word for word)
• 3 essential ingredients of software engineering
• Know and understand the 3 perspectives on software engineering
we talked about
• Know and understand the “Inf43 Recurring, Fundamental
Principles” of software engineering, and the overall ideas behind
the other principles
• No Silver Bullet
– Know and understand the essential difficulties of software engineering
– Know and understand the “potential silver bullets” on the essential
difficulties
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 49
Quiz – Tuesday, October 6 - Topics
• Know and understand software failure causes and how they
relate to requirements issues
• Know and understand the main ideas of the online failure
readings
• Make sure you have watched the videos I show in class
• Textbook: High-level understanding of the readings
• The quiz will focus on these topics, but I reserve the right to
ask about any other lecture/reading information as well
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 50