© 2000 franz kurfess requirements management 1 csc 205: software engineering i dr. franz j. kurfess...

© 2000 Franz Kurfess Requirements Management 1

CSC 205: Software Engineering ICSC 205: Software Engineering I

Dr. Franz J. Kurfess

Computer Science Department

Cal Poly


Course OverviewCourse Overview Introduction Requirements Engineering

Requirements Elicitation Requirements Management

Project Management System Design Methods

and Notations

Design Models and Object-Oriented Design

Design Analysis and Formal Specification

Design Analysis and Verification

Conclusions


Chapter OverviewRequirements Management

Chapter OverviewRequirements Management

Motivation Objectives Evaluation Criteria Information Flow Models Data Dictionary

Data Flow Diagrams Important Concepts and

Terms Chapter Summary


LogisticsLogistics

Introductions Course Materials

textbook handouts Web page CourseInfo/Blackboard System

Term Project Lab and Homework Assignments Exams Grading


Bridge-InBridge-In


Pre-TestPre-Test


MotivationMotivation

after requirements are elicited, it is important to document them carefully

natural language is usually not sufficient for a good documentation and organization of requirements

graphical notations and other more formal methods are frequently very helpful for the organization of requirements in a systematic manner


ObjectivesObjectives

understand the importance of documenting requirements

become familiar with methods and tools for the documentation and management of requirements

consider external factors that may influence the management of requirements


Documenting RequirementsDocumenting Requirements

on some projects minimal specifications may be appropriate for our CSC 205 project a thorough specification is

requireddetailed specifications provide a thorough basis for

planning and tracking a project they provide developers with a secure foundation for their

design and code for more fluid projects they have disadvantages

[Kearns 00]


Minimal Specification Minimal Specification

contains the minimal amount to specify a product pros

developers gain control and ownership shorter requirements phase opportunistic specification - fewer constraints

cons omission of key requirements unclear goals gold plating lack of support for parallel activities

[Kearns 00]


Requirements AnalysisRequirements Analysis

[Kearns 00]


Concise & UnderstandableConcise & Understandable

summarizeuse standard, structured templatesuse a uniform voice (active)use a uniform vocabularyuse information-structuring mechanisms

figures, diagrams, tables, math, …

use referencesnever, ever deliver incorectly spelt or text with

improperly grammar

[Kearns 00]


quantify requirements whenever possiblesupplement natural language with formal

specifications mathematics or other formalisms with a well-defined

semantics, as appropriate

be redundant to avoid misunderstandings redundant repetitive

UnambiguousUnambiguous

[Kearns 00]


AnalyzeAnalyze

classify requirementsidentify system boundariesuse checklistsidentify interactionsassess risksprioritize

[Kearns 00]


The Elements of the Analysis ModelThe Elements of the Analysis Model

core: data dictionary data object description

entity relationship diagram

process specification data flow diagram

control specification state transition diagram

[Kearns 00]


Data DictionaryData Dictionary

an organized approach for representing the characteristics of each data object and control item

data dictionary definition (Yourdan) an organized listing of of all data elements that are

pertinent to the system, with precise, rigorous definitions so that both user and system analyst will have a common understanding of inputs, outputs, components of stores and (even) intermediate calculations

[Kearns 00]


Data Dictionary ContentsData Dictionary Contents

name alias

what other names are used to refer to this element

where-used/how-used what external agents, processes use this data

format and content description what are the syntax and semantics of this element

supplementary information what else is relevant for the correct use and storage of this

data element

[Kearns 00]


Data Construct Notation Meaningdescription = is composed ofsequence + andselection { | } either-orrepetition { } n n repetitions ofoptional ( ) optional datacomments * * comment delimiters

Content Description Content Description

similar to BNF notation

[Kearns 00]


Functional ModelingFunctional Modeling

represent system as an information transforming system

concerned with modeling an information system in terms of processes (activities) and information flow among them

Data Flow Diagram (DFD), data flow graph, or bubble chart external entity process data objects data store (Data Dictionary)

[Kearns 00]


Information FlowInformation Flow

processing specification specifies the processing details implied by a bubble in the

data flow diagram includes any restrictions, performance, design constraints

that affect how the process will be implemented

refinement into a hierarchical sequence of diagrams depicts more detail information flow continuity or balancing

[Kearns 00]


Data Flow DiagramsData Flow Diagrams

made popular by DeMarco (1978), Gane and Sarson (1979)

used in Object-Modeling Technology (OMT) [Rumbaugh et. al., 1991]

intended as tool for functional analysisused in database design

generating data requirements verifying database design complement to ER diagrams by adding dynamic content

[Kearns 00]


Process Modeling Process Modeling

SW engineering viewtechnique for organizing and documenting a system’s

processes, inputs, outputs, and data storessoftware engineering technique

but the usefulness of process models extends far beyond describing software processes

note: SW engineering emphasis input-process-output model “documentation” focus

e.g., justify our system...

[Kearns 00]


Why Were DFDs Developed?

controlling complexityisolate flows and processinguncover structure of information flowcommunication/summarization toolnot tied to existing processorganizational separation of skills

[Kearns 00]


DFD ElementsDFD Elements

ExternalAgent

External User or Interface with other system(s).Used as a data source or sink. Sends and/orreceives data to/from processes.

Data StoreA repository of information. It can be any type ofpermanent storage: files, databases, paper/electronic forms, etc.In database design, the data store is a collection ofdata ite ms (possibly organized as an entity or an ERsub-model).

[Kearns 00]

Process

Represents an activity/process/function that: - receives data from other processes or agents - retrieves/updates data from/in data store(s) - transforms input data and passes it to another process, to an agent, or stores it in a data store - creates/deletes data items in/from data store(s)

LogicalData Flow Carries with it a set of data items.

Signifies a transfer of information between: - an agent and a process, - a process and a data store, and - between processes.Data flows do not change the data items. When used between data stores and processes, it represents a read/update/delete operation performed by a process. Default is update.Physical Flow deals with flow of ph ysical items (e.g, materials, parts, etc.)

[Kearns 00]

Data CreationFlow

Used between a process and a data store.Signifies the creation of a new object in thedata store (equivalent to a database insert).

ControlFlow

One process may control the start of another.A process cannot begin unless is signalledby another. This is not very useful fordatabase modeling.

Data items are directed on separate flows (toother processes, etc.)Total Branching: all items on main flow aredirected on all secondary flows.Partial Branching: secondary flows containsubsets of items on the main flow.

Data FlowSplit

Data items on secondary flows aremerged into one main flow.Total vs. Partial Branching, similar to adata flow split.

Data FlowMerge

[Kearns 00]


DFD AnalysisDFD Analysis

abstracting from the “process” to “processing”

summarization one-stop picture of the process, overview & details

test for completeness know all the code you’ll need to write all the data is accounted for eyeball the picture for discrepancies data stores assist identifying entities and relationships

[Kearns 00]


DFDs Are Not Flowcharts

DFD processes can operate in parallel but would not include conditional branching

data flow, not looping or branching no explicit decision-making

timing factors looking for flows not time scale

[Kearns 00]


Data Flow Detailsonly “essential” processing

processing that changes data

decoupling processing steps from each other controlling complexity

processing steps are verb/objectarrow names are nouns & noun phrases

“composite” vs. “primitive” flows

[Kearns 00]


Root or Context DFDRoot or Context DFD

shows the context of the systemtop level of DFD modelconsists of:

any number of agents only one process any number of data flows no data stores

[Kearns 00]


Sample DFD

Freeze

Account #

2

Employee

Membership

accounts

Create New

Member

Account

1

Employees

Accounts

Receivable

Department

Generate

Employee Bank

Statements

3Membership

Application

Modified account

status

Existing account

Frozen account

notification

Employee status Employee ID

& address

Bank Statement

Miracle

BlackHole

GrayHole

[Kearns 00]

A Sample DFD...not finished

black hole: data disappear miracle: data appear out of nowhere gray hole: unclear what happens to data

[Kearns 00]

Freeze

Account #

2

Employee

Membership

accounts

Create New

Member

Account

1

Employees

Accounts

Receivable

Department

Generate

Employee Bank

Statements

3Membership

Application

Modified account

status

Existing account

Frozen account

notification

Employee status Employee ID

& address

Bank Statement

Miracle

BlackHole

GrayHole


In practicemanage the detail(s)input, output, module codegeneralizing from examplessign off on this now...do it better?fits functional hierarchy

In theorycontrolling complexityisolate flows and processinguncover structure of information flowcommunication/summarization toolnot tied to existing processorganizational separation of skills

DFDs in Practice

[Kearns 00]


An Order Processing System: Context DFD

An Order Processing System: Context DFD

Payment

Invoice

Order Confirmation

Customer and Product Info

Customer

0

Order Processing

+

Process Model

Project : CSc 366 Demo Spring 99

Model : Order Process ing

Author : lmc Vers ion 1.0 4/3/99

[Kearns 00]


Customer and Order Info Order ConfirmationCustomer Name Customer IdCustomer Address Customer NameCustomer Phone Customer AddressShipping Address Billing AddressBilling Address Shipping AddressProduct Name* Customer PhoneQuantity* Order No

Order DateProduct No*Product Name*Unit Price*Quantity*Backorder*Order AmountPayment TermsEstimated Ship Date

Data Items for Data Flows 1Data Items for Data Flows 1

[Kearns 00]


Data Items for Data Flows 2Data Items for Data Flows 2

Invoice PaymentInvoice No Customer IdInvoice Date Customer NameCustomer Id Customer AddressCustomer Name Customer PhoneCustomer Address Invoice NoCustomer Phone Amount PaidShipping Address Payment DateBilling Address Check NumberOrder No Bank NameOrder DateProduct No*Product Name*Unit Price*Quantity*Backorder*Order AmountShip DateShipping ChargesTotal AmountPayment Terms

* - Repeating Group

[Kearns 00]


Root Process Decomposition Root Process Decomposition

Customer and Product Info

Order Confirmation

Invoice

Payment

Customer

Customer

Customer

Customer

1

Process Order

2Process Payment

[Kearns 00]


[Invoice]

Amount PaidBalance Due

Product InfoOld Customer New Order

New Customer

[Order Confirmation]

[Payment]

[Customer and Product Info]

Customer

Customer

1

Process Order

+

2Process Payment

Cus tomers Orders Inventory

Add Data StoresAdd Data Stores

[Kearns 00]


Decompose Process Order Decompose Process Order

[Invoice]


[New Order] [Product Info]

[Old Customer][New Customer]


Customer

Customers Orders Inventory

[Kearns 00]


Order to be Shipped

Order to be Verified

[Invoice]


[New Order] [Product Info][Old Customer][New Customer]


Customer


1.1

Take Order

1.2

Verify Order

1.3

Make Shipment

Process Order RefinementProcess Order RefinementTake order, Verify order, Make shipment

New flows: Order to be Verified (Order No); Order to be Shipped (Order No)

[Kearns 00]


Add Synonyms for ReadabilityAdd Synonyms for Readability

[Invoice]


[Product Info][New Order]

[New Customer]

[Old Customer]


Order to be Shipped


Customer


1.1

Take Order

1.2Verify Order

1.3Make

Shipment

Customer

Customer

[Kearns 00]


Verify order, Make shipmentVerify order, Make shipmentVerify Order

validates the order approves or rejects it based on customer credit rating and order amount

checks and updates the inventory sends the order confirmation to customer

including an estimated ship date

Make Shipment prepares the invoice computes shipping charges updates the order total and the customer balance ships the merchandise

[Kearns 00]

Shipped Product Info

New Balance Customer

Shipping Info

[Invoice]

Customer Id Updated Order

Info

Order InfoCustomer Info

Product in Stock

[New Order][Product Info]

[Old Customer]

[New Customer]



Order to be Shipped


Customer


1.1

Take Order

1.2

Verify Order

1.3

Make Shipment

Customer

[Kearns 00]


Another Example: Loan ApplicationAnother Example: Loan Application

Reply

Employement Data

Employment Verification

Request

Credit Repot

Credit Report Request

Loan Application

Applicant

0Process

Loan Application

+

Credit Agency

Employer

[Kearns 00]

Approved Loan Data

Decision

Recommendation

[Reply]

Additional Data Rejected Loan

Incomplete Application

[Credit Repot]

Completed Application

[Employement Data]

[Employment Verification

Request]

[Credit Report Request]

Applicant Additional Data

Additional Data Request

Rejection Letter

Updated Application

Preliminary Loan

Application Data

[Loan Application]

Applicant

Credit Agency

Employer

Applicant

1Record

Application

Pending Applications

2

Screening

3

Loan ApprovalLoan

Committee

Rejected Applications

Applicant

Approved Loans

DecompositionDecomposition

[Kearns 00]


ExerciseExercise

Model two additional systems and integrate them with the above example. Make Loan

After a loan is approved, the lender must actually make the loan. This includes, drafting the loan documents, signing them and opening the loan account.

Process Loan Payments This system receives and processes loan payments from the

borrower. It must properly credit principal, and interest, to the loan account. Must process late payments, "short payments" (payment amounts that are less than the amount due)

[Kearns 00]


DecompositionDecompositionnumbering of processes

process tree

data flow balancing data flows entering or exiting a process must be the same as those

entering or leaving the decomposed DFD (migration of data flow)

data stores localityexternal agents

you should not introduce new agents in process decomposition (but see example above)

number of levels seven plus or minus two

[Kearns 00]


Social and Organisational Factors

software systems are used in a social and organisational context this can influence or even dominate the system

requirements

social and organisational factors are not a single viewpoint have influences on all viewpoints

good analysts must be sensitive to these factors currently no systematic way to tackle their analysis

[Sommerville 01]


Example

consider a system which allows senior management to access information without going through middle managers managerial status

senior managers may feel too important to use a keyboard this may limit the type of system interface used

managerial responsibilities managers may have no uninterrupted time to learn the system

organisational resistance middle managers who will be made redundant may deliberately

provide misleading or incomplete information so that the system will fail

[Sommerville 01]


Ethnography

a social scientists spends a considerable time observing and analysing how people actually work

people do not have to explain or articulate their worksocial and organisational factors of importance may

be observedethnographic studies have shown that work is

usually richer and more complex than suggested by simple system models

[Sommerville 01]


Focused Ethnography

developed in a project studying the air traffic control process

combines ethnography with prototypingprototype development results in unanswered

questions which focus the ethnographic analysisa problem with ethnography is that it studies existing

practices may have some historical basis which is no longer relevant

[Sommerville 01]


Ethnography and PrototypingEthnographicanalysisDebriefingmeetingsFocusedethnographyPrototypeevaluationGeneric systemdevelopment Systemprotoyping[Sommerville 01]


Scope of EthnographyScope of Ethnography

requirements that are derived from the way that people actually work rather than the way i which process definitions suggest that they ought to work

requirements that are derived from cooperation and awareness of other people’s activities

[Sommerville 01]

Requirements ReadersClient managersSystem end-usersClient engineersContractor managersSystem architectsSystem end-usersClient engineersSystem architectsSoftware developersClient engineers (perhaps)System architectsSoftware developersRequirementsdefinitionRequirementsspecificationSoftwarespecification

[Kearns 00]

Requirements Engineering ProcessFeasibilitystudyRequirementsanalysisRequirementsdefinitionRequirementsspecificationFeasibilityreport SystemmodelsDefinition ofrequirementsSpecification ofrequirementsRequirementsdocument[Kearns 00]


Requirements Document Structure

typical structure may vary for different purposes or organizations

[Kearns 00]

Introductiondescribe need for the system and how it fits with business objectives

Glossarydefine technical terms used

System Modelsdefine models showing system components and relationships

Function-oriented Requirements Definition

describe the services to be provided

Non-function-oriented Requirements Definition

Define constraints on the system and the development process

System EvolutionDefine fundamental assumptions on which the system is based and anticipated changes

Requirements SpecificationDetailed specification of functional requirements

AppendicesIndex


Requirements Validation

Concerned with demonstrating that the requirements define the system that the customer really wants

Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to

100 times the cost of fixing an implementation error

[Sommerville 01]


Requirements Checkingvalidity

does the system provide the functions which best support the customer’s needs?

consistency are there any requirements conflicts?

completeness are all functions required by the customer included?

realism can the requirements be implemented given available budget and

technologyverifiability

can the requirements be checked?

[Sommerville 01]


Requirements Validation TechniquesRequirements Validation Techniquesrequirements reviews

systematic manual analysis of the requirements

prototyping using an executable model of the system to check

requirements

test-case generation developing tests for requirements to check testability

automated consistency analysis checking the consistency of a structured requirements

description

[Sommerville 01]


Requirements Reviews

regular reviews should be held while the requirements definition is being formulated

both client and contractor staff should be involved in reviews

reviews may be formal (with completed documents) or informal good communications between developers, customers and

users can resolve problems at an early stage

[Sommerville 01]


Review Checks

verifiability is the requirement realistically testable?

comprehensibility is the requirement properly understood?

traceability is the origin of the requirement clearly stated?

adaptability can the requirement be changed without a large impact on

other requirements?

[Sommerville 01]


Automated Consistency CheckingAutomated Consistency Checking

RequirementsdatabaseRequirementsanalyserRequirementsproblem reportRequirementsprocessorRequirementsin a formal language[Sommerville 01]


Requirements ManagementRequirements Management

process of managing changing requirements during the requirements engineering process and system development

requirements are inevitably incomplete and inconsistent new requirements emerge during the process

business needs change a better understanding of the system is developed

different viewpoints have different requirements these are often contradictory

[Sommerville 01]


Requirements ChangeRequirements Change

the priority of requirements from different viewpoints changes during the development process

system customers may specify requirements from a business perspective that conflict with end-user requirements

the business and technical environment of the system changes during its development

[Sommerville 01]


Requirements EvolutionChangedunderstandingof problemInitialunderstandingof problem ChangedrequirementsInitialrequirements Time[Sommerville 01]


Enduring and Volatile Requirements

enduring requirements stable requirements derived from the core activity of the

customer organisation e.g. a hospital will always have doctors, nurses, etc. may be derived from domain models

volatile requirements requirements which change during development or when

the system is in use in a hospital, requirements derived from health-care policy

[Sommerville 01]


Classification of Requirementsmutable requirements

requirements that change due to the system’s environmentemergent requirements

requirements that emerge as understanding of the system develops

consequential requirements requirements that result from the introduction of the

computer systemcompatibility requirements

requirements that depend on other systems or organisational processes

[Sommerville 01]


Requirements Management PlanningRequirements Management Planning

during the requirements engineering process, you have to plan: requirements identification

how requirements are individually identified

a change management process the process followed when analysing a requirements change

traceability policies the amount of information about requirements relationships that is

maintained

CASE tool support the tool support required to help manage requirements change

[Sommerville 01]


TraceabilityTraceability

relationships between requirements, their sources and the system design

source traceability links from requirements to stakeholders who proposed

these requirements

requirements traceability links between dependent requirements

design traceability links from the requirements to the design

[Sommerville 01]


A Traceability MatrixA Traceability Matrix

[Sommerville 01]

U: [row] utilizes [column] requirementR: other relationship


CASE Tool SupportCASE Tool Support

requirements storage requirements should be managed in a secure, managed

data store

change management the process of change management is a workflow process

whose stages can be defined and information flow between these stages partially automated

traceability management automated retrieval of the links between requirements

[Sommerville 01]


Requirements Change ManagementRequirements Change Management

should apply to all proposed changes to the requirements

principal stages problem analysis

discuss requirements problem and propose change

change analysis and costing assess effects of change on other requirements

change implementation modify requirements document and other documents to reflect

change

[Sommerville 01]


Requirements Change ManagementRequirements Change Management

ChangeimplementationChange analysisand costingProblem analysis andchange specificationIdentifiedproblem Revisedrequirements[Sommerville 01]


Important Concepts and TermsImportant Concepts and Terms natural language product process process modeling project refinement requirements checking requirements documentation requirements management requirements reviews requirements validation specification system model traceability

change management consistency checking control flow data creation flow data dictionary data flow diagram (DFD) data store decomposition ethnography external agent formal specification functional modeling glossary graphical notations logical data flow


Chapter Summarythe documentation of requirements relies on natural

language descriptions and on more formal methodssocial and organisation factors influence system

requirementsrequirements validation is concerned with checks for

validity, consistency, completeness, realism and verifiability

business changes inevitably lead to changing requirements

requirements management includes planning and change management

[Sommerville 01]

© 2000 franz kurfess requirements management 1 csc 205: software engineering i dr. franz j. kurfess...

Documents