Professional Documents
Culture Documents
Chapter 7
Pragmatic Programmer
SE Fall 2002 1
The Requirements Pit
• Tip 51: Don’t Gather Requirements – Dig
for Them
• Tip 52: Work with a User to Think Like a
User
• Tip 53: Abstractions Live Longer than
Details
• Tip 54: Use a Project Glossary
SE Fall 2002 2
Overspecifying
• Don’t be too specific. Good requirement
documents remain abstract.
• Requirements
– Are NOT architecture
– Are NOT design, NOR user interface
– Are need
SE Fall 2002 3
The Specification Trap
• Tip 57: Some Things Are Better Done than
Described
• Seamless approach:specification and
implementation are different aspects of the
same process: each should flow directly into
the next, with no artificial boundaries.
SE Fall 2002 4
Requirements Engineering
Bernd Bruegge
SE Fall 2002 5
System Identification
SE Fall 2002 6
Requirements Engineering
SE Fall 2002 7
Requirements Validation
•Traceability:
•Each system function can be traced to a corresponding set of
functional requirements
SE Fall 2002 9
Types of Requirements Engineering
•Greenfield Engineering
•Development starts from scratch, no prior system exists,
the requirements are extracted from the end users and the
client
•Triggered by user needs
•Re-engineering
•Re-design and/or re-implementation of an existing system
using newer technology
•Triggered by technology enabler
•Interface Engineering
•Provide the services of an existing system in a new
environment Example: Eclipse as new technology enabler
•Triggered by technology enabler or new market needs
SE Fall 2002 10
Actors
SE Fall 2002 11
Scenarios
SE Fall 2002 12
Types of Scenarios
•As-is scenario:
•Used in describing a current situation. Usually used during re-
engineering. The user describes the system.
•Visionary scenario:
•Used to describe a future system. Usually described in
greenfield engineering or reengineering.
•Can often not be done by the user or developer alone.
•Evaluation scenario:
•User tasks against which the system is to be evaluated
•Training scenario:
•Step by step instructions designed to guide a novice user
through a system
SE Fall 2002 13
Heuristics: How do I find Scenarios?
SE Fall 2002 14
Example: Accident Management System
SE Fall 2002 15
Scenario Example: Warehouse on Fire
•Bob, driving down main street in his patrol car notices smoke
coming out of a warehouse. His partner, Alice, activates the
“Report Emergency” function from her FRIEND laptop.
•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, he requests several paramedic units on the
scene given that area appear to be relatively busy. He confirms his
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 creates 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.
SE Fall 2002 16
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
•Next goal, after the scenarios are formulated:
•Find the use case that specifies all possible instances of how to
report a fire
•What roles are the played by the participating actors?
SE Fall 2002 17
Use Case Example: ReportEmergency
SE Fall 2002 18
Use Case Example: ReportEmergency ctd
SE Fall 2002 19
Use Cases
SE Fall 2002 20
Use Case Associations
•Relationship between use cases
•Important types:
•Consists of
•Extends
•Uses
SE Fall 2002 21
“Consists of” Association for Use Cases
•Not explicitly named in UML
•Problem: A function in the original problem statement is too
complex to be solvable
•Solution: Describe the function as the aggregation of a set of
simpler functions. The associated use case is refined into
smaller use cases
ManageIncident
CreateIncident
HandleIncident
CloseIncident
SE Fall 2002 22
“Extends” Association for Use Cases
SE Fall 2002 23
“Uses” Association for Use Cases
SE Fall 2002 24
How to Specify a Use Case
SE Fall 2002 25
Use Case Example: Allocate a Resource
•Entry Condition
•The use case starts after the Resource Allocator has selected an
available Resource.
•The Resource is currently not allocated
•Flow of Events
•The Resource Allocator selects an Emergency Incident.
•The Resource is committed to the Emergency Incident.
•Exit Condition
•The use case terminates when the resource is committed.
•The selected Resource is now unavailable to any other Emergency
Incidents or Resource Requests.
•Special Requirements
•The Field Supervisor is responsible for managing the Resources
SE Fall 2002 26
Heuristics: How do I find use cases?
SE Fall 2002 27
Is there Life after Scenarios and Use Cases?
SE Fall 2002 28
Problems with Functional Decomposition
SE Fall 2002 29
Modeling a Briefcase
BriefCase
Capacity: Integer
Weight: Integer
Open()
Close()
Carry()
SE Fall 2002 30
A new Use Case for a Briefcase
BriefCase
Capacity: Integer
Weight: Integer
Open()
Close()
Carry()
SitOnIt()
SE Fall 2002 31
Questions
•Why did we model the thing as “Briefcase”?
•Why did we not model it as a chair?
•What do we do if the SitOnIt() operation is the most
frequently used operation?
•The briefcase is only used for sitting on it during video
conferences. It is never opened nor closed. Is it a “Chair”or a
“Briefcase”?
•How can we live with our mistake?
SE Fall 2002 32
Summary
•Requirements Engineering:
•Greenfield Engineering, Reengineering, Interface Engineering
•Scenarios:
•Great way to establish communication with client
•As-Is Scenarios, Visionary scenarios, Evaluation scenarios,
Training scenarios
•Use cases: Abstraction of scenarios
•Pure functional decomposition is bad:
•Leads to unmaintainable code
•Starting with object identification is bad:
•May lead to wrong objects, wrong attributes, wrong methods
•The key to successful analysis:
•Start with use cases and then find the participating objects
•If somebody asks “What is this?”, do not answer right away.
Return the question or observe: “What is it used for?”
SE Fall 2002 33
From Bernd Bruegge
• CMU/Munich
• Notes on Software Lifecycle
SE Fall 2002 34
Engineering Complex Systems
SE Fall 2002 35
Hierarchy
SE Fall 2002 36
Other ways to deal with complexity
SE Fall 2002 37
Categories of software development methodologies
•Object-oriented methodology
Systems are modeled as a collection of cooperating objects
•Structured Methodology
Based on functional (algorithmic) decomposition
•Data-driven Methodology
Structure of system is derived by mapping system inputs to outputs.
E,g, Jackson System Development
•Aspect-oriented Methodology
Support for crosscutting abstractions
E.g. Demeter, AspectJ, HyperJ
SE Fall 2002 38
Models to Describe Systems
SE Fall 2002 39
Software Development Methodologies
SE Fall 2002 40
UML
SE Fall 2002 41
CASE (Computer Aided Software Engineering)
SE Fall 2002 42
Methodology Definition
SE Fall 2002 43
Software Life Cycle
•Software development goes through a progression of states
(software development activities)
Conception
Childhood
Adulthood
Retirement
SE Fall 2002 44
Examples of Software Development Activities (Pfleeger)
Requirements Analysis: What is the problem? Problem
System Design:What is the solution? domain
Program Design: What are the mechanisms that best implement the
solution.
Program Implementation: How is the solution constructed?
Testing: Is the problem solved?
Delivery: Can the customer use the solution? Implementation
Maintenance: Are enhancements needed? domain
SE Fall 2002 45
Software Lifecycle
•Definition:
•Set of activities that constitute a software project
•Typical Lifecycle questions:
•Which activities should I select for the software project?
•What are the dependencies between activities?
•How should I schedule the activities?
SE Fall 2002 46
Inherent Problems with Software Development
SE Fall 2002 47
Life-Cycle Model: Variations on a Theme
•Many models have been proposed to deal with the problems
of defining activities and associating them with each other
•The waterfall model
•First described by Royce in 1970
•There seem to be at least as many versions as there are
authorities - perhaps more
SE Fall 2002 48
The Waterfall Model of the Software Life Cycle
System Testing
SE Fall 2002 49
Problems with Waterfall Model
•Managers love waterfall models:
•Nice milestones
•No need to look back (linear system)
•Always one activity at a time
•Easy to check progress during development: 90% coded, 20%
tested
•However, software development is iterative
•While a design is being developed, problems with requirements
are identified
•While a program is being coded, design and requirement
problems are found
•While a program is tested, coding errors, design errors and
requirement errors are found
SE Fall 2002 50
Alternative
• Allow iteration
SE Fall 2002 51
Alternative Lifecycle Model: Allow Iteration
Revise, Review -> List of revisions for each phase
Phases:
Requirements Elicitation
Analysis
Design
Implementation
Testing
Delivered System
SE Fall 2002 52
Spiral Model (Boehm)
•Identify risks
•Assign priorities to risks
•Develop a series of prototypes for the identified risks
starting with the highest risk.
•Use a waterfall model for each development (round or
cycle)
•If a risk has successfully been resolved, evaluate the results
of the round and plan the next round
•If a certain risk cannot be resolved, terminate the project
immediately
SE Fall 2002 53
Activities (“Rounds”) in Boehm’s Spiral Model
•Concept of Operations
•Software Requirements
•Software Product Design
•Detailed Design
•Code
•Unit Test
•Integration and Test
•Acceptance Test
•Implementation
•For each round go through these steps
•Define objectives, alternatives, constraints
•Evaluate alternative, identify and resolve risks
•Develop, verify next level product
•Plan next activity (“round”, “phase”)
SE Fall 2002 54
Different Types of Prototypes
•Illustrative Prototype
•Develop the user interface with a set of storyboards
•Implement them on a napkin or with a user interface
builder (Visual C++, ....)
•Good for first dialog with client
•Functional Prototype
•Implement and deliver an operational system with
minimum functionality
•Then add more functionality
•Order identified by risk
•Exploratory Prototype ("Hacking")
•Implement part of the system to learn more about the
requirements.
•Good for paradigm breaks SE Fall 2002 55
Types of Prototyping cont’
•Revolutionary Prototyping
•Also called specification prototyping
•Get user experience with a throwaway version to get the requirements right,
then build the whole system
•Disadvantage: Users may have to accept that features in the prototype are
expensive to implement
•User may be disappointed when some of the functionality and user interface
evaporates because it can not be made available in the implementation
environment
•Evolutionary Prototyping
•The prototype is used as the basis for the implementation of the final system
•Advantage: Short time to market
•Disadvantage: Can be used only if target system can be constructed in
prototyping language
SE Fall 2002 56
Prototyping vs Rapid Development
SE Fall 2002 57
Class vs Project
•In class, we will introduce software development activities in a
certain order constrained by the lectures schedule
•In the project, we must be able to deal with iteration, out of
order activities, revisions and refinements (based on new
information obtained during the project)
•Your goal:
•Learn about the software development activities
•Gain a better understanding of the difficulties of the software
development
•Combine the current state of the art knowledge with tools and
techniques to produce a quality software system delivered in time
and within budget.
SE Fall 2002 58
Standards for Software Development
SE Fall 2002 59
IEEE Software Engineering Standards
•Other important standards
•IEEE 610 Glossary of Software Engineering Terminology
•IEEE 830 Guide for Software Requirements Specification
•IEEE 1002 Standard Taxonomy for Software Engineering
Standards
•Standards are rapidly changing and are revised every
couple of years
•Revisited every 5 years
•Standards older than 5 years: Reasonable to assume that the
present state is not wholly reflected
SE Fall 2002 60
Other Standards
•ISO (International Standard Organization)
•OSI Hierarchy (Open System Interconnection)
•EDI standard (for electronic data interchange)
•ISO 9001 (Standard for Software Development)
•CCITT (International Consultative Committee on
Telephony and Telegraphy)
•A group composed of the world's telecommunication
companies
•X.25 Standard for packet-switched network layer services
•X.400 Message Handling
•X. 500: Directory Standard
•ANSI (American National Standards Institute)
•Official Representative of the US to ISO and CCITT
•ASCII
SE Fall 2002 61
Processes, Activities and Tasks IEEE 1074
•Processes consists of Activities which in turn consist of tasks
•Example:
•The Design Process consists of the following Activities
•Perform Architectural Design
•Design Database (If Applicable)
•Design Interfaces
•Select or Develop Algorithm (If Applicable)
•Perform Detailed Design (= Object Design)
•The Design Database Activity has the following Tasks
•Review Relational Databases
•Review Object-Oriented Databases
•Make a Purchase recommendation
•....
SE Fall 2002 62
Software Development Activities in COM 3205
Focus on Development
•Planning
•Requirements Analysis
•Design
•System Design
•Object Design
•Implementation
•Coding
•Unit Testing
•Integration Testing
•System Testing
•System Delivery
SE Fall 2002 63
Software Process Model used in COM 3205
SE Fall 2002 64
Roles in COM 3205
SE Fall 2002 65
Requirements Analysis
SE Fall 2002 66
Design
•Create a solution that meets the specifications outlined in
the requirements analysis phase
•Design is a complex process and highly iterative
•Parts of the design
•User interface design : Design of the system as it will be seen
by the users (end user, maintainer, client)
•System design: Define the structure of the system, that is, its
modular components and the relationship among the
components
•Object design: Make decisions about implementation of each of
the components (signature: type of parameters and return
results)
SE Fall 2002 67
Boundary between Analysis and Design
SE Fall 2002 68
Implementation
•Major product of this phase is the source code
•3 activities: Coding, unit testing and integration testing
•Coding: Write the source code for some component of the
system
•Unit testing: Subject component to a number of tests for
reliability and validity
•Integration testing: Test groups of unit-tested components
according to an integration strategy.
SE Fall 2002 69
System Testing
SE Fall 2002 70
Delivery
•Time during development when we help the users to
understand and feel comfortable with the product
•Question to ask: Can the customer use the solution?
•Documentation:
•Developer Documentation
•User Documentation
•Administrator Documentation
•Operator Documentation
SE Fall 2002 71
Maintenance
SE Fall 2002 72
Summary
•Software life cycle
•The development process is broken into individual pieces called
software development activities
•No good model for modeling the process (black art)
•Existing models are an inexact representation of reality
•Nothing really convincing is available
•Software development standards
•IEEE
•MIL
•Standards help, but must be taken with a grain of salt
•What are we using in COM 3205: Agile Software Development
SE Fall 2002 73
SE Fall 2002 74
Communication
Bernd Bruegge
SE Fall 2002 75
Communication is important
• A Communication Example
• "Two missile electrical boxes
manufactured by different contractors
were joined together by a pair of wires.
• Pair of Wires
• Box 1
• Box 2
SE Fall 2002 76
A Communication Example ctd
Box 1
Box 2
SE Fall 2002 77
After the Crash...
SE Fall 2002 78
Communication is Important
•Communication Mode:
•Type of information exchange that has defined objectives and
scope
SE Fall 2002 79