Lecture 2 Software Process Models / Requirements Analysis

1
Lecture 2 Software Process Models /
Requirements Analysis
CSCE 492 Software Engineering

• Topics
• Mythical Man Month
• Waterfall model
• Spiral Method
• Requirements Analysis
• Readings Chapter 3

May 31, 2006
2
Overview

• Last Time
• Overview
• Quality Software
• Todays 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

3
UML Unified Modeling Language

• UML reference
• http//www.holub.com/goodies/uml/
• Website of Quickreference Cards
• http//www.digilife.be/quickreferences/quickrefs.h
  tm

4
Teams

• Hal Hubbard, Jeremy Lane, Yoni Rayburn, Marvin
  Million
• Lewis Clyburn, Scott Sanders, Eun Yoon
• Segi Simmons, Pinar Wilbanks, Adriel Shaw,
• Clarke ?

5
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
6
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
7
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
8
Should we fix this bug or not?

• Four questions when a bug is discovered
• (Severity) When this bug happens, how bad is the
  impact?
• (Frequency) How often does this bug happen?
• (Cost) How much effort would be required to fix
  this bug?
• (Risk) What is the risk of fixing this bug?

http//software.ericsink.com/articles/Four_Questio
ns.html
9
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. 
• 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_Questio
ns.html
10
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
• http//en.wikipedia.org/wiki/The_Mythical_Man-Mont
  h

11
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."
• Edsger Dijkstra The Humble Programmer (PDF,
  473Kb)

12
Waterfall Model of Software Life Cycle

• Not the first iterative method
• But the first paper to explain why to use the
  iterative method

Figure from Barry Boehm88
13
Water Fall Model

• Requirements analysis
• Design
• Implementation
• Testing (validation)
• Integration
• maintenance
• Reference
• http//en.wikipedia.org/wiki/Waterfall_process

14
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

15
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
• Black box vs white or clear box
• Functional vs Structural (refinement of the black
  vs white)

16
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.
• Chaos 75 fall organizations here.
• .
• .
• .
• .

http//www.sei.cmu.edu/cmmi/general/general.html
17
Current trends in software engineering

• Aspects
• Agile
• Software architectures
• Software Product lines

18
Agile Software Development

• We follow these principles
• Our highest priority is to satisfy the
  customerthrough early and continuous deliveryof
  valuable software.
• Welcome changing requirements, even late in
  development. Agile processes harness change for
  the customer's competitive advantage.
• Reference http//agilemanifesto.org/principles.ht
  ml

19
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
• Most requirements analysis slides are from authors

20
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

21
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
• Developed by USC Center for Software Engineering
• Collaborative analysis approach involving
  end-users

22
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

23
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

24
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

25
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

26
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?

27
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?

28
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

29
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

30
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 librarys holdings
  on line
• Additional activities listed in text

31
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

32
More Elements of the LMS Requirements
Specification

• Projected time frame
• Prioritization of requirements
• Ethical concerns
• Who has access of borrowing history of patrons?
• How are children protected from questionable
  materials found on the Internet?

33
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

34
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

35
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

36
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

37
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)
• Enumerate possible erroneous flow of events

38
LMS Case Study Use Cases

• Validate patron
• Check out resource
• Check in resource
• Request resource
• Reserve resource
• Manage Resource
• Manage Patron
• Generate from letter

39
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
• Patron ID not valid
• Patron has over due resources or too many checked
  
• Resource number not valid

40
More LMS Case Study Check out Resource Use Case

• Postcondition
• 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

41
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

42
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

43
Notational Elements of Use Case Diagrams
Actor
Use case
Use casename
Relationships
Association
Generalization
Dependency
44
LMS Case Study Use Case Diagram
BrowseResource
RequestResource
ReserveResource
Patron
Resource
45
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