CSCE 492 Software Engineering
Lecture 2
Software Process Models /
Requirements Analysis
Topics




Mythical Man Month
Waterfall model
Spiral Method
Requirements Analysis
Readings: Chapter 3
May 31, 2006
Overview
Last Time


Overview
Quality Software
Today’s Lecture

Pragmatics
 UML references, Teams

Models for the process of software development
 Waterfall model, Spiral model, Agile,

Requirements
References:


Chapters 2 and 3 of the text
Boehm paper “Spiral Model”
Next Time:
–2–
CSCE 492 Summer 2006
UML – Unified Modeling Language
UML reference

http://www.holub.com/goodies/uml/
Website of Quickreference Cards

–3–
http://www.digilife.be/quickreferences/quickrefs.htm
CSCE 492 Summer 2006
Teams
 Hal Hubbard, Jeremy Lane, Yoni Rayburn, Marvin
Million
 Lewis Clyburn, Scott Sanders, Eun Yoon
 Segi Simmons, Pinar Wilbanks, Adriel Shaw,
 Clarke ?
–4–
CSCE 492 Summer 2006
Working in Teams
 Be conscientious about due dates
 Meet regularly with your team
 Always create an agenda for every team meeting
 Rotate responsibility for chairing team meetings
Authors’ slide modified
–5–
CSCE 492 Summer 2006
Holding Effective Team Meetings
 Create a clear agenda addressing the essential tasks
that must be accomplished in order to complete the
necessary deliverables
 Stick to the agenda during the meeting
 Ensure that each team member understands his or
her tasks before the meeting is adjourned
 Ensure that tasks are equitably distributed
Authors’ slide modified
–6–
CSCE 492 Summer 2006
Class Project Deliverables
 The deliverables associated with the class project
are essential to successfully completing the
project
 The class project is not merely a programming
assignment
 The deliverables result from completing tasks
associated with analysis, design, implementation,
and testing the class project
Authors’ slide modified
–7–
CSCE 492 Summer 2006
Should we fix this bug or not?
Four questions when a bug is discovered
1. (Severity) When this bug happens, how bad is the
impact?
2. (Frequency) How often does this bug happen?
3. (Cost) How much effort would be required to fix this
bug?
4. (Risk) What is the risk of fixing this bug?
–8–
http://software.ericsink.com/articles/Four_Questions.html
CSCE 492 Summer 2006
Severity and Frequency
The vertical axis is Severity.

The top of the graph represents a bug with extremely severe impact:
"This bug causes the user's computer to burst into flame."

The bottom of the graph represents a bug with extremely low impact:
"One of the pixels on the splash screen is the wrong shade of gray."
The horizontal axis is Frequency.


–9–
The right side represents a bug which happens extremely often:
"Every user sees this bug every day."
The left side represents a bug which happens extremely seldom:
"This bug only affects people who live in eastern Washington state
and who have both Visual Studio 2003 and Visual Studio 2005 installed
and it only happens during leap years on the day that daylight savings
time goes into effect and only if the first day of that month was a
Tuesday."
http://software.ericsink.com/articles/Four_Questions.html
CSCE 492 Summer 2006
Mythical Man-Month
Main Ideas in “Mythical Man-Month” collection of essays
 Mythical Man-Month
 Second-system effect

IBM 7094360, the second system an engineer designs will be
too ambitious, including way too much
 Progress Tracking

Question: How does a large software project get to be one year
late? Answer: One day at a time!
 Conceptual Integrity
 The Pilot System
 Communication

– 10 –
http://en.wikipedia.org/wiki/The_Mythical_Man-Month
CSCE 492 Summer 2006
Software Crisis
"[The major cause of the software crisis is] that the
machines have become several orders of magnitude
more powerful! To put it quite bluntly: as long as
there were no machines, programming was no
problem at all; when we had a few weak computers,
programming became a mild problem, and now we
have gigantic computers, programming has become
an equally gigantic problem."

– 11 –
Edsger Dijkstra: The Humble Programmer (PDF, 473Kb)
CSCE 492 Summer 2006
Waterfall Model
of Software Life
Cycle
Not the first iterative
method
But the first paper to
explain why to use
the iterative method
– 12 –
Figure from Barry Boehm88
CSCE 492 Summer 2006
Water Fall Model
 Requirements analysis
 Design
 Implementation
 Testing (validation)
 Integration
 maintenance
Reference
 http://en.wikipedia.org/wiki/Waterfall_process
– 13 –
CSCE 492 Summer 2006
Requirements Analysis
Software requirements analysis is the activity of
eliciting, analyzing, and recording requirements for
software systems.
1 Eliciting Requirements
2 Analyzing Requirements
3 Recording Requirements
– 14 –
CSCE 492 Summer 2006
Software testing
Software testing is the process used to help identify the
correctness, completeness, security and quality of
developed computer software.
 testing can never completely establish the
correctness of arbitrary computer software.
 computability theory, a field of computer science, an
elegant mathematical proof concludes that it is
impossible to solve the halting problem
 Categories of Testing Techniques


– 15 –
Black box vs white or clear box
Functional vs Structural (refinement of the black vs white)
CSCE 492 Summer 2006
Capability Maturity Model Integration
Capability Maturity Model (CMM now CMMI) is a
collection of instructions an organization can follow
with the purpose to gain better control over its
software development process.
The CMM ranks software development organizations in
a hierarchy of five levels, each with a progressively
greater capability of producing quality software.
1. Chaos 75% fall organizations here.
2. .
3. .
4. .
5. .
http://www.sei.cmu.edu/cmmi/general/general.html
– 16 –
CSCE 492 Summer 2006
Current trends in software engineering
 Aspects
 Agile
 Software architectures
 Software Product lines
– 17 –
CSCE 492 Summer 2006
Agile Software Development
We follow these principles:
 Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
 Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
 …
 Reference: http://agilemanifesto.org/principles.html
– 18 –
CSCE 492 Summer 2006
Requirements Analysis
 A requirement is a feature of the system
 Requirements analysis seeks to assess and specify
the behavior of the final system
 Requirements analysis can be iteratively carried out
or done in a top-down fashion
 It is desirable to establish the breadth of behavior of
a system to determine the primary classes that will
comprise the system
Reference:

– 19 –
Most requirements analysis slides are from authors
CSCE 492 Summer 2006
The Importance of Requirements
Analysis
Frederick Brooks: “The hardest single part of
building a software system is deciding precisely
what to build”
Barry Boehm: by investing more up-front effort in
verifying and validating the software
requirements, software developers will see
reduced integration and test costs, as well as
higher software reliability and maintainability
– 20 –
CSCE 492 Summer 2006
Examples of Good Requirements
Analysis
Participatory analysis

Involves staff members of all levels from the domain area
interacting directly with the development team
Negotiation-based technique


– 21 –
Developed by USC Center for Software Engineering
Collaborative analysis approach involving end-users
CSCE 492 Summer 2006
Requirements Specification
Requirements analysis results in a complete,
consistent, correct, and unambiguous requirements
specification
The initial specification may be created by the end
users or by the technical staff
Independent of the source of the initial specification it
must be refined and verified to be correct and
complete
– 22 –
CSCE 492 Summer 2006
Possible Elements of Requirements
Specification
 Supported activity list
 Human-computer interface description
 solved problem list
 Information source list
 Information requesting organization list
 Checks and balances
 Security and fault-tolerant requirements
– 23 –
CSCE 492 Summer 2006
More: Possible Elements of
Requirements Specification
 Inter-operating systems list
 Estimates of present information capacity and
projected growth
 Project time frame
 Prioritization of requirements
 Ethical concerns list
– 24 –
CSCE 492 Summer 2006
Case Study: Library Management
System
Independent of who creates the requirements
specification (end users or technical staff), it is
the responsibility of the system developers to
ensure the user requirements are adequately
fleshed out
The first step of requirements analysis is to
establish and refine the problem statement which
takes the form of the requirements specification
– 25 –
CSCE 492 Summer 2006
LMS Case Study: Clarifying the
Requirements Specification
 What sort of human-computer interface is envisioned?
 What sort of search facility is necessary for library
patrons?
 Will patrons be assigned a unique ID number?
 Should the system support inter-library loan requests?
– 26 –
CSCE 492 Summer 2006
LMS Case Study: More Clarifying the
Requirements Specification
 Are there any limits on patrons’ use of research databases?
 How are books retired from the library collection?
 How long are requested books held for patrons?
 Are overdue fees the same for all type of library resources?
 Which online databases will the system interact with?
– 27 –
CSCE 492 Summer 2006
Creating Quality Requirements
Specifications
 The key is to keep in close communication with the
end users throughout the development process, but
especially during requirements analysis
 Ideally, a whole array of different end users should
be involved with the development team to gain
sufficient breadth of input
– 28 –
CSCE 492 Summer 2006
LMS Case Study: Supported Activity
List
 Support Library staff activities like checking out
resources to patrons
 Validating patrons



Current membership
No resources more than two weeks overdue
Not over maximum of checked resources
 Assigning library numbers to patrons
– 29 –
CSCE 492 Summer 2006
LMS Case Study: More
Supported Activity List
 Deleting expired library numbers and associated patron records
 Checking out library resources: books,CDs, etc
 Checking in library resources
 Changing the status of a library resource
 Allowing materials to be placed on reserve
 Allowing the searching of the library’s holdings on line
 Additional activities listed in text
– 30 –
CSCE 492 Summer 2006
Other Elements of the LMS
Requirements Specification
 Human-computer interface
 Solved problems list
 Information source list
 Information requesting organizations
 Automated checks and balances
 Security and fault-tolerant requirements
 Present information capacity and projected growth
– 31 –
CSCE 492 Summer 2006
More Elements of the LMS
Requirements Specification
Projected time frame
Prioritization of requirements
Ethical concerns
– 32 –

Who has access of borrowing history of patrons?

How are children protected from questionable
materials found on the Internet?
CSCE 492 Summer 2006
Verifying Requirements
 A structured walkthrough with the end users is a
good technique for ensuring that the user needs are
being addressed
 To ensure that the resulting software supports the
requirements specification, items on the supported
activity list are numbered and propagated through
the software models and source code
– 33 –
CSCE 492 Summer 2006
The Process of Requirements
Analysis
 Create verified requirements specification
 Create list of primary classes
 Create informal scenarios
 Create use cases
 Create scenarios
 Create class diagrams
 Create use case diagrams
– 34 –
CSCE 492 Summer 2006
Identifying Use Cases
 A use case is a description of a scenario (or closely
related set of scenarios) in which the system
interacts with users of the system
 The behavior of the system is expressed without
specifying how the behavior is implemented
 Use cases are initially described narratively, and
then modeled graphically by class diagrams and
interaction diagrams (to be discuss later)
 Informal scenarios are a good starting point for use
cases
– 35 –
CSCE 492 Summer 2006
Characteristics of Use Cases
 Use cases are more abstract than informal
scenarios
 A single use case may encompass multiple
scenarios
 Use cases avoid redundancy
 Use cases are more formally structured than
scenarios
 Use cases seek to capture complete breadth of
system behavior
– 36 –
CSCE 492 Summer 2006
Use Case Layout
 Precondition

What conditions must be true at the beginning of the use case?
 Main flow of events

Describe the essential behavior associated with the use case
 Post condition

What occurs as a result of the use case executing
 Exceptional flow of events ( zero to many)

– 37 –
Enumerate possible erroneous flow of events
CSCE 492 Summer 2006
LMS Case Study: Use Cases
 Validate patron
 Check out resource
 Check in resource
 Request resource
 Reserve resource
 Manage Resource
 Manage Patron
 Generate from letter
– 38 –
CSCE 492 Summer 2006
LMS Case Study: Check out
Resource Use Case
Precondition


Library staff and patron validated to LMS
Library DB initialized
Main flow of events


Enter resource
Determine due date
Exceptional flow of events



– 39 –
Patron ID not valid
Patron has over due resources or too many checked
Resource number not valid
CSCE 492 Summer 2006
More LMS Case Study: Check out
Resource Use Case
Postcondition



– 40 –
Patron DB entry updated to reflect new resource
Resource DB entry updated to reflect changed status:
checked out
Due date assigned to the resource DB entry
CSCE 492 Summer 2006
Scenario Development
Scenarios are derived from use cases
Scenarios are like informal scenarios, but are more formally
structured
Informal scenarios may be modified to produce scenarios
Use cases are abstract because they do not reference specific
values
Scenarios are concrete because they do reference specific values
Multiple scenarios may be required for a single use case
– 41 –
CSCE 492 Summer 2006
UML Use Case Diagrams
 Use case diagrams depict use cases interacting with
external actors
 External actors are entities that interact with the
software system, like system users, databases, or
books
 Use cases represent system requirements and show
a functional partitioning of the system
 Functional partitioning is useful for a dividing a
system into smaller pieces
– 42 –
CSCE 492 Summer 2006
Notational Elements of Use Case
Diagrams
Actor
Use case
Use case
name
Relationships:
Dependency
– 43 –
Association
Generalization
CSCE 492 Summer 2006
LMS Case Study: Use Case Diagram
Browse
Resource
Request
Resource
Patron
– 44 –
Reserve
Resource
Resource
CSCE 492 Summer 2006
Steps in UCCD Analysis Process
Create/refine requirements specification
Create informal scenarios
Create list of primary classes
Create use cases
Create scenarios from use cases
Create class diagrams showing basic inter-class relationships
Model key class collaborations
Create use case diagrams
– 45 –
CSCE 492 Summer 2006