Lecture 3 Software Process Models /

Requirements Analysis

Lecture 3 Software Process Models /

Requirements Analysis

Topics Topics Mythical Man Month Waterfall model Spiral Method Requirements Analysis

Readings: Chapter 3Readings: Chapter 3January 15, 2009

CSCE 492 Software Engineering

– 2 – CSCE 492 Spring 2009

OverviewOverviewLast TimeLast Time

Overview Quality Software

Today’s Lecture Today’s Lecture Pragmatics

UML references, Teams

Models for the process of software developmentWaterfall model, Spiral model, Agile,

Requirements

References: References: Chapters 2 and 3 of the text Boehm paper “Spiral Model”

Next Time: Next Time:

– 3 – CSCE 492 Spring 2009

UML – Unified Modeling LanguageUML – Unified Modeling Language

UML referenceUML reference http://www.holub.com/goodies/uml/

Website of Quickreference CardsWebsite of Quickreference Cards http://www.digilife.be/quickreferences/quickrefs.htm

– 4 – CSCE 492 Spring 2009

TeamsTeams

Team 1: BENDER SAMUEL, BENNETT RONALD, Team 1: BENDER SAMUEL, BENNETT RONALD, BUSH BRANDON, SCHANDLER J M, CHILDERS BUSH BRANDON, SCHANDLER J M, CHILDERS WESLEYWESLEY

Team 2: CROCKETT MATTHEW, DINKINS CHANCE, Team 2: CROCKETT MATTHEW, DINKINS CHANCE, ELLIOTT MICHAEL, GALLOWAY SCOTT, HITE EELLIOTT MICHAEL, GALLOWAY SCOTT, HITE E

Team 3: MICHALSKI JASEN, RABON TONI ANN, Team 3: MICHALSKI JASEN, RABON TONI ANN, SHANNON MARION, SIMMONS KATIA, STIFFLER NSHANNON MARION, SIMMONS KATIA, STIFFLER N

Team 4: STOICHITA RAZVAN, TAYLOR KAREEM, Team 4: STOICHITA RAZVAN, TAYLOR KAREEM, THAPA BIJAYA, VAN O'LINDA MTHAPA BIJAYA, VAN O'LINDA M

– 5 – CSCE 492 Spring 2009

Working in TeamsWorking in Teams

Be conscientious about due datesBe conscientious about due dates

Meet regularly with your teamMeet regularly with your team

Always create an agenda for every team meetingAlways create an agenda for every team meeting

Rotate responsibility for chairing team meetingsRotate responsibility for chairing team meetings

Authors’ slide modified

– 6 – CSCE 492 Spring 2009

Holding Effective Team MeetingsHolding Effective Team Meetings

Create a clear agenda addressing the essential tasks Create a clear agenda addressing the essential tasks that must be accomplished in order to complete the that must be accomplished in order to complete the necessary deliverablesnecessary deliverables

Stick to the agenda during the meetingStick to the agenda during the meeting

Ensure that each team member understands his or Ensure that each team member understands his or her tasks before the meeting is adjournedher tasks before the meeting is adjourned

Ensure that tasks are equitably distributedEnsure that tasks are equitably distributed

Authors’ slide modified

– 7 – CSCE 492 Spring 2009

Class Project DeliverablesClass Project Deliverables

The deliverables associated with the class project The deliverables associated with the class project are essential to successfully completing the are essential to successfully completing the projectproject

The class project is not merely a programming The class project is not merely a programming assignmentassignment

The deliverables result from completing tasks The deliverables result from completing tasks associated with analysis, design, implementation, associated with analysis, design, implementation, and testing the class projectand testing the class project

Authors’ slide modified

– 8 – CSCE 492 Spring 2009

General Project ParametersGeneral Project Parameters

Type 1 Projects: Web-enabled System Type 1 Projects: Web-enabled System Web interface Database backend Publically accessible Security/permissions issues Examples: appointment calendar, scheduling system

Type 2 Projects: Stand-alone SystemsType 2 Projects: Stand-alone Systems More elaborate graphics May require a database Examples: games, mobile data collection tool

Suggestions from the floor?Suggestions from the floor?

– 9 – CSCE 492 Spring 2009

Should we fix this bug or not?Should we fix this bug or not?

Four questions when a bug is discoveredFour questions when a bug is discovered

1.1. (Severity) When this bug happens, how bad is the (Severity) When this bug happens, how bad is the impact?impact?

2.2. (Frequency) How often does this bug happen? (Frequency) How often does this bug happen?

3.3. (Cost) How much effort would be required to fix this (Cost) How much effort would be required to fix this bug? bug?

4.4. (Risk) What is the risk of fixing this bug? (Risk) What is the risk of fixing this bug?

http://software.ericsink.com/articles/Four_Questions.html

– 10 – CSCE 492 Spring 2009

Severity and FrequencySeverity and Frequency

The vertical axis is Severity.  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 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_Questions.html

– 11 – CSCE 492 Spring 2009

Mythical Man-MonthMythical Man-Month

Main Ideas in “Mythical Man-Month” collection of essaysMain Ideas in “Mythical Man-Month” collection of essays

Mythical Man-Month Mythical Man-Month

Second-system effectSecond-system effect IBM 7094360, the second system an engineer designs will be

too ambitious, including way too much

Progress Tracking Progress Tracking  Question: How does a large software project get to be one year Question: How does a large software project get to be one year

late? Answer: One day at a time!late? Answer: One day at a time!

Conceptual Integrity  Conceptual Integrity 

The Pilot System The Pilot System

Communication Communication http://en.wikipedia.org/wiki/The_Mythical_Man-Month

– 12 – CSCE 492 Spring 2009

Waterfall Model of Software Life Cycle

Waterfall Model of Software Life Cycle

Not the first iterative Not the first iterative methodmethod

But the first paper to But the first paper to explain why to use explain why to use the iterative methodthe iterative method

Figure from Barry Boehm88

– 13 – CSCE 492 Spring 2009

Water Fall ModelWater Fall Model

Requirements analysis Requirements analysis

DesignDesign

ImplementationImplementation

Testing (validation)Testing (validation)

IntegrationIntegration

maintenancemaintenance

ReferenceReference

http://en.wikipedia.org/wiki/Waterfall_processhttp://en.wikipedia.org/wiki/Waterfall_process

– 14 – CSCE 492 Spring 2009

The Spiral ModelThe Spiral Model

Note iterative Note iterative repetition of repetition of the cycle!the cycle!

– 15 – CSCE 492 Spring 2009

Requirements AnalysisRequirements Analysis

Software requirements analysis is the activity of Software requirements analysis is the activity of eliciting, analyzing, and recording eliciting, analyzing, and recording requirementsrequirements for for software systems. software systems.

1 Eliciting Requirements1 Eliciting Requirements

2 Analyzing Requirements2 Analyzing Requirements

3 Recording Requirements3 Recording Requirements

– 16 – CSCE 492 Spring 2009

Requirements AnalysisRequirements Analysis A requirement is a feature of the system A requirement is a feature of the system

Requirements analysis seeks to assess and specify Requirements analysis seeks to assess and specify the behavior of the final system the behavior of the final system

Requirements analysis can be iteratively carried out Requirements analysis can be iteratively carried out or done in a top-down fashionor done in a top-down fashion

It is desirable to establish the breadth of behavior of It is desirable to establish the breadth of behavior of a system to determine the primary classes that will a system to determine the primary classes that will comprise the systemcomprise the system

Reference:Reference: Most requirements analysis slides are from authors

– 17 – CSCE 492 Spring 2009

The Importance of Requirements AnalysisThe Importance of Requirements Analysis

Frederick Brooks: “The hardest single part of Frederick Brooks: “The hardest single part of building a software system is deciding precisely building a software system is deciding precisely what to build”what to build”

Barry Boehm: by investing more up-front effort in Barry Boehm: by investing more up-front effort in verifying and validating the software verifying and validating the software requirements, software developers will see requirements, software developers will see reduced integration and test costs, as well as reduced integration and test costs, as well as higher software reliability and maintainabilityhigher software reliability and maintainability

– 18 – CSCE 492 Spring 2009

Examples of Good Requirements AnalysisExamples of Good Requirements Analysis

Participatory analysisParticipatory analysis Involves staff members of all levels from the domain

area interacting directly with the development team

Negotiation-based techniqueNegotiation-based technique Developed by USC Center for Software Engineering Collaborative analysis approach involving end-users

– 19 – CSCE 492 Spring 2009

Requirements SpecificationRequirements Specification

Requirements analysis results in a complete, Requirements analysis results in a complete, consistent, correct, and unambiguous requirements consistent, correct, and unambiguous requirements specificationspecification

The initial specification may be created by the end The initial specification may be created by the end users or by the technical staffusers or by the technical staff

Independent of the source of the initial specification it Independent of the source of the initial specification it must be refined and verified to be correct and must be refined and verified to be correct and completecomplete

– 20 – CSCE 492 Spring 2009

Possible Elements of Requirements SpecificationPossible Elements of Requirements Specification

Supported activity listSupported activity list

Human-computer interface descriptionHuman-computer interface description

solved problem listsolved problem list

Information source listInformation source list

Information requesting organization listInformation requesting organization list

Checks and balancesChecks and balances

Security and fault-tolerant requirementsSecurity and fault-tolerant requirements

– 21 – CSCE 492 Spring 2009

More: Possible Elements of Requirements SpecificationMore: Possible Elements of Requirements Specification

Inter-operating systems listInter-operating systems list

Estimates of present information capacity and Estimates of present information capacity and projected growthprojected growth

Project time frameProject time frame

Prioritization of requirementsPrioritization of requirements

Ethical concerns listEthical concerns list

– 22 – CSCE 492 Spring 2009

Case Study: Library Management SystemCase Study: Library Management System

Independent of who creates the requirements Independent of who creates the requirements specification (end users or technical staff), it is specification (end users or technical staff), it is the responsibility of the system developers to the responsibility of the system developers to ensure the user requirements are adequately ensure the user requirements are adequately fleshed outfleshed out

The first step of requirements analysis is to The first step of requirements analysis is to establish and refine the problem statement which establish and refine the problem statement which takes the form of the requirements specificationtakes the form of the requirements specification

– 23 – CSCE 492 Spring 2009

LMS Case Study: Clarifying the Requirements SpecificationLMS Case Study: Clarifying the Requirements Specification

What sort of human-computer interface is envisioned?What sort of human-computer interface is envisioned?

What sort of search facility is necessary for library What sort of search facility is necessary for library patrons?patrons?

Will patrons be assigned a unique ID number?Will patrons be assigned a unique ID number?

Should the system support inter-library loan requests?Should the system support inter-library loan requests?

– 24 – CSCE 492 Spring 2009

LMS Case Study: More Clarifying the Requirements SpecificationLMS Case Study: More Clarifying the Requirements Specification

Are there any limits on patrons’ use of research databases?Are there any limits on patrons’ use of research databases?

How are books retired from the library collection?How are books retired from the library collection?

How long are requested books held for patrons?How long are requested books held for patrons?

Are overdue fees the same for all type of library resources?Are overdue fees the same for all type of library resources?

Which online databases will the system interact with?Which online databases will the system interact with?

– 25 – CSCE 492 Spring 2009

Creating Quality Requirements SpecificationsCreating Quality Requirements Specifications

The key is to keep in close communication with the The key is to keep in close communication with the end users throughout the development process, but end users throughout the development process, but especially during requirements analysisespecially during requirements analysis

Ideally, a whole array of different end users should Ideally, a whole array of different end users should be involved with the development team to gain be involved with the development team to gain sufficient breadth of inputsufficient breadth of input

– 26 – CSCE 492 Spring 2009

LMS Case Study: Supported Activity ListLMS Case Study: Supported Activity List

Support Library staff activities like checking out Support Library staff activities like checking out resources to patronsresources to patrons

Validating patronsValidating patrons Current membership No resources more than two weeks overdue Not over maximum of checked resources

Assigning library numbers to patronsAssigning library numbers to patrons

– 27 – CSCE 492 Spring 2009

LMS Case Study: More Supported Activity ListLMS Case Study: More Supported Activity List

Deleting expired library numbers and associated patron Deleting expired library numbers and associated patron recordsrecords

Checking out library resources: books,CDs, etcChecking out library resources: books,CDs, etc

Checking in library resourcesChecking in library resources

Changing the status of a library resourceChanging the status of a library resource

Allowing materials to be placed on reserveAllowing materials to be placed on reserve

Allowing the searching of the library’s holdings on lineAllowing the searching of the library’s holdings on line

Additional activities listed in textAdditional activities listed in text

– 28 – CSCE 492 Spring 2009

Other Elements of the LMS Requirements SpecificationOther Elements of the LMS Requirements Specification

Human-computer interfaceHuman-computer interface

Solved problems listSolved problems list

Information source listInformation source list

Information requesting organizationsInformation requesting organizations

Automated checks and balancesAutomated checks and balances

Security and fault-tolerant requirementsSecurity and fault-tolerant requirements

Present information capacity and projected growthPresent information capacity and projected growth

– 29 – CSCE 492 Spring 2009

More Elements of the LMS Requirements SpecificationMore Elements of the LMS Requirements Specification

Projected time frameProjected time frame

Prioritization of requirementsPrioritization of requirements

Ethical concernsEthical concerns Who has access of borrowing history of patrons? How are children protected from questionable

materials found on the Internet?

– 30 – CSCE 492 Spring 2009

Verifying RequirementsVerifying Requirements

A structured walkthrough with the end users is a A structured walkthrough with the end users is a good technique for ensuring that the user needs are good technique for ensuring that the user needs are being addressedbeing addressed

To ensure that the resulting software supports the To ensure that the resulting software supports the requirements specification, items on the supported requirements specification, items on the supported activity list are numbered and propagated through activity list are numbered and propagated through the software models and source codethe software models and source code

– 31 – CSCE 492 Spring 2009

The Process of Requirements AnalysisThe Process of Requirements Analysis Create verified requirements specificationCreate verified requirements specification

Create list of primary classesCreate list of primary classes

Create informal scenariosCreate informal scenarios

Create use casesCreate use cases

Create scenariosCreate scenarios

Create class diagramsCreate class diagrams

Create use case diagramsCreate use case diagrams

– 32 – CSCE 492 Spring 2009

Identifying Use CasesIdentifying Use Cases

A use case is a description of a scenario (or closely A use case is a description of a scenario (or closely related set of scenarios) in which the system related set of scenarios) in which the system interacts with users of the systeminteracts with users of the system

The behavior of the system is expressed without The behavior of the system is expressed without specifying how the behavior is implementedspecifying how the behavior is implemented

Use cases are initially described narratively, and Use cases are initially described narratively, and then modeled graphically by then modeled graphically by class diagramsclass diagrams and and interaction diagramsinteraction diagrams (to be discuss later) (to be discuss later)

Informal scenarios are a good starting point for use Informal scenarios are a good starting point for use casescases

– 33 – CSCE 492 Spring 2009

Characteristics of Use CasesCharacteristics of Use Cases

Use cases are more abstract than informal Use cases are more abstract than informal scenariosscenarios

A single use case may encompass multiple A single use case may encompass multiple scenariosscenarios

Use cases avoid redundancyUse cases avoid redundancy

Use cases are more formally structured than Use cases are more formally structured than scenariosscenarios

Use cases seek to capture complete breadth of Use cases seek to capture complete breadth of system behaviorsystem behavior

– 34 – CSCE 492 Spring 2009

Use Case LayoutUse Case Layout PreconditionPrecondition

What conditions must be true at the beginning of the use case?

Main flow of eventsMain flow of events Describe the essential behavior associated with the use case

Post conditionPost condition What occurs as a result of the use case executing

Exceptional flow of events ( zero to many)Exceptional flow of events ( zero to many) Enumerate possible erroneous flow of events

– 35 – CSCE 492 Spring 2009

LMS Case Study: Use CasesLMS Case Study: Use Cases

Validate patronValidate patron

Check out resourceCheck out resource

Check in resourceCheck in resource

Request resourceRequest resource

Reserve resourceReserve resource

Manage ResourceManage Resource

Manage PatronManage Patron

Generate from letterGenerate from letter

– 36 – CSCE 492 Spring 2009

LMS Case Study: Check out Resource Use CaseLMS Case Study: Check out Resource Use CasePreconditionPrecondition

Library staff and patron validated to LMS Library DB initialized

Main flow of eventsMain flow of events Enter resource Determine due date

Exceptional flow of eventsExceptional flow of events Patron ID not valid Patron has over due resources or too many checked Resource number not valid

– 37 – CSCE 492 Spring 2009

More LMS Case Study: Check out Resource Use CaseMore LMS Case Study: Check out Resource Use Case

PostconditionPostcondition 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

– 38 – CSCE 492 Spring 2009

Scenario DevelopmentScenario Development

Scenarios are derived from use casesScenarios are derived from use cases

Scenarios are like informal scenarios, but are more formally Scenarios are like informal scenarios, but are more formally structuredstructured

Informal scenarios may be modified to produce scenariosInformal scenarios may be modified to produce scenarios

Use cases are abstract because they do Use cases are abstract because they do notnot reference specific reference specific valuesvalues

Scenarios are concrete because they Scenarios are concrete because they do do referencereference specific valuesspecific values

Multiple scenarios may be required for a single use caseMultiple scenarios may be required for a single use case

– 39 – CSCE 492 Spring 2009

UML Use Case DiagramsUML Use Case Diagrams

Use case diagrams depict use cases interacting with Use case diagrams depict use cases interacting with external actorsexternal actors

External actors are entities that interact with the External actors are entities that interact with the software system, like system users, databases, or software system, like system users, databases, or books books

Use cases represent system requirements and show Use cases represent system requirements and show a functional partitioning of the systema functional partitioning of the system

Functional partitioning is useful for a dividing a Functional partitioning is useful for a dividing a system into smaller piecessystem into smaller pieces

– 40 – CSCE 492 Spring 2009

Notational Elements of Use Case DiagramsNotational Elements of Use Case Diagrams

Use casename

Actor Use case

Relationships:Dependency Association Generalization

– 41 – CSCE 492 Spring 2009

LMS Case Study: Use Case DiagramLMS Case Study: Use Case Diagram

BrowseResource

RequestResource

ReserveResourcePatron Resource

– 42 – CSCE 492 Spring 2009

Steps in UCCD Analysis ProcessSteps in UCCD Analysis Process

Create/refine requirements specificationCreate/refine requirements specification

Create informal scenariosCreate informal scenarios

Create list of primary classesCreate list of primary classes

Create use casesCreate use cases

Create scenarios from use casesCreate scenarios from use cases

Create class diagrams showing basic inter-class relationshipsCreate class diagrams showing basic inter-class relationships

Model key class collaborationsModel key class collaborations

Create use case diagramsCreate use case diagrams